%META:TOPICPARENT{name="SupportedArchitectures"}%

---++ Understanding Key Concepts in Architectural Planning

%NAVY%This section defines Architectural Planning and key concepts associated with such planning.%ENDCOLOR%

Architectural Planning is a multi-faceted and multi-step process that enables system architects to identify software solutions that are sound and deployable by enterprise staff. Enterprises should engage in the architectural process whenever the solution they require is mission critical, broad in scope, and likely to have a significant impact on some aspect of the enterprise. Failure to adopt this discipline can result in unwieldy solutions or solutions that fail to meet the requirements of the enterprise strategy.

Architectural Planning is a detailed and step-by-step process. Architects gather enterprise requirements, evaluate legacy holdings, and consider future growth opportunities and needs. Architects then design a solution that is expressed in multiple design documents and diagrams that grow in complexity, as the solution becomes better conceived. The end result is often a diagram or model that local technical staff can use to deploy the solution.  

---+++ Diagrams Produced during Architectural Planning

| *Conceptual Diagram* &mdash; High-level diagrams that convey generic and fundamental information about a proposed solution. Conceptual diagrams are usually the first set of diagrams that an architect will create in the planning process. The target audience is often non-technical stakeholders. The example to the right shows the general [[UDAConceptualArchitectures][OpenLink Universal Data Access Conceptual Architecture]]. | <a href="UDAConceptualArchitectures"><img src="%ATTACHURLPATH%/../UDAConceptualArchitectures/ConceptualArchitecture.png" alt="OpenLink Conceptual Architecture" height="150" /></a> |
| *Logical Diagram* &mdash; Logical Diagrams evolve from Conceptual Diagrams. Logical Diagrams contain annotations that specify Architectural Component requirements, capabilities, and interactions. These diagrams are not suitable for deployment purposes. The example to the right is a [[ODBCLogicalDiagrams][Logical Diagram of OpenLink Express Edition ODBC Driver deployment]]. |  <a href="ODBCLogicalDiagrams"><img src="%ATTACHURLPATH%/../ODBCLogicalDiagrams/ExpressLogical.png" alt="Express Drivers Logical Diagram" height="150"  /></a> |
| *Deployment Diagram* &mdash; Low-level and highly specific diagrams that allow local technical staff to deploy a solution. These are the last in a series of diagrams created by architects. The example to the right shows two aspects of an [[MTODBCDiagrams][OpenLink Multi-Tier Data Access Deployment with DBMS Server, Gateway, and Distinct Client Hosts]].  | <a href="MTODBCDiagrams"><img src="%ATTACHURLPATH%/../MTODBCDiagrams/MTODBCArch2.png" alt="Multi-Tier Deployment with DBMS Server, Gateway, and Distinct Client Hosts" height="150"  /></a> |

---+++Some Terms Used in Architectural Planning

*Architectural Component* &mdash; Individual, technological "building blocks"  that combine together to form the overall solution.

*Composition* &mdash; The act of combining Architectural elements to create a workable solution.

*Decomposition* &mdash; The act of breaking down existing architectures or proposed solutions into Architectural Components.

*Legacy Solution* &mdash; Deployed solution that is being deprecated or augmented by the solution under design.

*Legacy System* &mdash; Deployed system that factors into an architect's design process. Legacy systems may need to be reused, updated, or abandoned due to the needs of both the enterprise and the solution desired by the enterprise.