Enterprise Architecture - Revision history

Cwalrad at 00:43, 4 July 2019

2019-07-04T00:43:31Z

Invicta at 02:25, 23 December 2017

2017-12-23T02:25:41Z

Invicta at 00:02, 23 December 2017

2017-12-23T00:02:37Z

Show changes

Invicta at 22:54, 19 December 2017

2017-12-19T22:54:40Z

Invicta at 02:29, 19 December 2017

2017-12-19T02:29:30Z

Invicta at 01:10, 19 December 2017

2017-12-19T01:10:23Z

Invicta at 01:07, 19 December 2017

2017-12-19T01:07:41Z

Show changes

Invicta at 20:54, 15 December 2017

2017-12-15T20:54:00Z

Show changes

Invicta at 23:08, 11 December 2017

2017-12-11T23:08:09Z

Invicta at 23:05, 11 December 2017

2017-12-11T23:05:46Z

@@ Line 14: / Line 14: @@
 <p>Like many other disciplines, EA is evolving.&nbsp;[[#One|[1]]] The EA concept dates back to the late 1980s as a response to the increased complexity associated with the introduction of distributed computing. For the first time, the unmanaged and uncontrolled replication of systems providing similar capabilities, as well as the same or very similar data sets, were springing up around the enterprise. The result was increased difficulty in integrating and evolving systems to address changing business needs. The initial EA concept was to adopt an ''enterprise-wide'' view of an organization's computing resources. By developing and applying standards and governance throughout the organization, unnecessary complexity and redundancy could be avoided.</p>
 <p>EA provides this enterprise-wide view. Although it was initially motivated by the need to control EIT expense, EA is now also driven by the need for improved EIT innovation, effectiveness, and efficiency in a rapidly changing business and technology environment. If done well, an organization's enterprise architecture provides context for all the enterprise's IT activities.</p>
-<p>The results of the EA process provide inputs to the enterprise's strategy at the highest level. EA also takes the enterprise's strategy and determines how to manifest it throughout the organization, both high and low.
+<p>The results of the EA process provide inputs to the enterprise's strategy at the highest level. EA also takes the enterprise's strategy and determines how to manifest it throughout the organization, both high and low. </p>
 <p>While there are a number of frameworks, practices, and approaches for EA, there is a generally accepted body of conventional wisdom on the subject. This chapter introduces the basic concepts and the most common practices. </p>
 <h2>Goals and Principles</h2>

@@ Line 249: / Line 249: @@
 <li>The implementation and migration plan takes all of the previous components and provides a schedule of the projects that will realize the desired architecture. </li>
 </ul>
-<p>When the implementation and migration plan is relatively complete, management and stakeholders need to clearly understand both the cost and the benefits (realized valve) of each step (or work package) of the migration. </p>
+<p>When the implementation and migration plan is relatively complete, management and stakeholders need to clearly understand both the cost and the benefits (realized value) of each step (or work package) of the migration. </p>
 <p>When the migration plan reaches consensus among all the relevant parties, the implementation and migration plan is integrated with the enterprise's other change initiatives.</p>
 <p>At this point, the architecture development cycle should be completed. All artifacts of the process should be updated and added to the architectural repository. In addition, lessons learned during the process should be documented to enable the enterprise's continuous improvement process.</p>

@@ Line 247: / Line 247: @@
 <li>The ''Architecture Roadmap'' is an execution timeline of multiple work packages that will result in the desired architecture. This timeline can cover a few months or multiple years, especially if the gap between the future and desired state is large.</li>
 <li>The ''Transition Architecture'' document describes the enterprise at architecturally significant and stable states between the "as is" and "to be" architectures. Transition architectures provide interim states at which all organizations of the enterprise can converge and ensure stability.</li>
-<li>The Implementation and Migration Plan takes all of the previous components and provides a schedule of the projects that will realize the desired architecture. </li>
+<li>The Implementation and Migration Plan takes all the previous components and provides a schedule of the projects that will realize the desired architecture. </li>
 </ul>
 <p>Once the Implementation and Migration Plan is relatively complete, management and stakeholders need to clearly understand both the cost and the benefits (realized valve) of each step (or work package) of the migration. </p>

@@ Line 431: / Line 431: @@
 </tr>
 </table>
 <h2>Key Roles</h2>
 <p>Both SFIA and the e-CF have described profiles (similar to roles) for providing examples of skill sets (skill combinations) for various roles. The iCD has described tasks performed in EIT and associated those with skills in the IPA database.</p>

← Older revision		Revision as of 01:10, 19 December 2017
Line 472:		Line 472:
	<p>Schekkerman, "How to Survive in the Jungle of Enterprise Architecture Frameworks," Trafford</p>		<p>Schekkerman, "How to Survive in the Jungle of Enterprise Architecture Frameworks," Trafford</p>
	<p>Ross Weill and Robertson, "Enterprise Architecture as Strategy," Harvard Business School Press.</p>		<p>Ross Weill and Robertson, "Enterprise Architecture as Strategy," Harvard Business School Press.</p>
		+	<p>Fine, Charles, "Clockspeed : Winning Industry Control in the Age of Temporary Advantage," Perseus Books, 1998.</p>

@@ Line 189: / Line 189: @@
 <p>The ''business architecture'' describes the enterprise's product or service strategy, as well as the organizational, functional, informational, and geographic aspects of the enterprise's current business environment. The goal is to create a refined baseline or ("As Is") description, which is usually an enhancement of what was created in preliminary efforts. The effort then develops a business architecture of the desired state. </p>
 <p>Once the "As Is" and "To Be" business architectural states are described, the EA team then performs a detailed "gap analysis" between the current and desired states. This effort will likely create artifacts such as use case models, activity models, and information exchange matrixes. It will also likely define candidate roadmaps for achieving the desired state.</p>
-<p>These artifacts draw from the abstract representations of a business shown in [#Figure_BizBOK Figure 8]. In the figure, the center circle represents concepts and includes capability, value, organization, and information. These concepts are considered core, because they are very stable business perspectives that remain relatively constant. Changes occur as required to accommodate business and EIT as they evolve. EIT inherits some of these blueprints from the business and transforms them into aligned, EIT-focused forms.</p>
+<p>These artifacts draw from the abstract representations of a business shown in [[#Figure_BizBOK|Figure&nbsp;8]]. In the figure, the center circle represents concepts and includes capability, value, organization, and information. These concepts are considered core, because they are very stable business perspectives that remain relatively constant. Changes occur as required to accommodate business and EIT as they evolve. EIT inherits some of these blueprints from the business and transforms them into aligned, EIT-focused forms.</p>
 <p>The outer orange circle in the figure shows influencing perspectives. For example, strategies continue to evolve in real time while new business and EIT products and services are introduced routinely. These examples show how the outer circle of business abstractions are more dynamic than the stable core. Collectively, when mapped and presented appropriately, the core and extended views provide a complete planning view.</p>
 <p>If you look carefully, you can likely see the correspondence between this business ecosystem view and some of the architecture frameworks that have been developed (and described in Section xx).</p>

@@ Line 48: / Line 48: @@
 <p>Analogies between EA and urban planning have been made, because both define common guidelines, standards, and frameworks with which solution architects and building architects, respectively, must comply (see&nbsp;[[#Figure_Urban|Figure&nbsp;2]]). </p>
-[[File:Urban_Planner.jpg||700px]]<br /><div id="Figure_Urban"></div>'''Figure 2. Urban Planner and Enterprise Architect vs. Building Architect and Solution Architect&nbsp;[[#Three|[3]]]'''
+<p>[[File:Urban_Planner.jpg||700px]]<br /><div id="Figure_Urban"></div>'''Figure 2. Urban Planner and Enterprise Architect vs. Building Architect and Solution Architect&nbsp;[[#Three|[3]]]'''</p>
 <h3>The Evolution of Enterprise Architecture</h3>
@@ Line 66: / Line 66: @@
 </ol>
 <p>The differences between these categories is depicted graphically in [[#Figure_EA_schools|Figure&nbsp;3]].</p>
-<p>[[File:EA_schools.png]]<br /><div id="Figure_EA_schools"></div><p>'''Figure 3. EA Schools of Thought'''&nbsp;[[#Six|[6]]]</p>
+<p>[[File:EA_schools.png]]<br /><div id="Figure_EA_schools"></div>'''Figure 3. EA Schools of Thought'''&nbsp;[[#Six|[6]]]</p>
 <p>EA can serve a number of different goals (the vertical axis of [[#Figure_EA_schools|Figure&nbsp;3]]) and can provide direction and support for a range of time horizons and enterprise value (the horizontal axis). It is important to distinguish the type of EA that an organization needs and wants to establish. By doing so, the boundaries and handoffs between EA and business executives in the execution of their business strategy become clear. Without that clarity, ongoing confusion and issues with collaboration and alignment will likely be created.</p>
 <p>EA practitioners have three base-level assumptions:</p>
@@ Line 77: / Line 77: @@
 <p>In the 1980s, a four-layer division of system architecture came into use by system designers. The architecture was split into technology, applications, information, and business domains. The domains higher in the stack were built on top of and depended upon the lower layers. The BIAT model helped system architects organize information and the structure of the systems, and also helped them understand requirements that flow between these layers.</p>
 <p>In the early 1990s, this four-layer division, called the BIAT model [http://eitbokwiki.org/Glossary#biat]) was adapted for EA and relatively soon was modified to a five-layer model: the technology layer was divided into software and hardware infrastructure layers. It also changed the focus of EA practice to that of business processes. (see [[#Figure_BIAT|Figure&nbsp;4]]). </p>
-<p>[[File:BIAT-Models.jpg]]<br /><div id="Figure_BIAT"></div><p>'''Figure 4. Conventional BIAT Diagram and the 5-Layer BIAT Diagram''' </p>
+<p>[[File:BIAT-Models.jpg]]<br /><div id="Figure_BIAT"></div>'''Figure 4. Conventional BIAT Diagram and the 5-Layer BIAT Diagram''' </p>
 <p>The meanings of the layers are described below.</p>
 <h4>Business Layer</h4>
@@ Line 100: / Line 100: @@
 <p>EA is an ongoing activity. It is always in process. It never stops. The architecture team must perennially keep up with the current state of the ever-evolving organization and its business. Just as important, EA is working with management to understand what they want the future to be. The path to get to the future is constantly being refined.</p>
 <p>The Open Group describes an approach that it calls the Architecture Development Model (ADM) that consists of a number of iterative phases, as shown in [[#Figure_TOGAF|Figure&nbsp;5]].&nbsp;[[#Fourteen|[14]]]</p>
-<p>[[File:TOGAF.png]]<br /><div id="Figure_TOGAF"></div><p>'''Figure 5. TOGAF 9.1 ADM Steps'''&nbsp;[[#Fourteen|[14]]]</p>
+<p>[[File:TOGAF.png]]<br /><div id="Figure_TOGAF"></div>'''Figure 5. TOGAF 9.1 ADM Steps'''&nbsp;[[#Fourteen|[14]]]</p>
 <p>Although there are differing opinions about the way to create an EA, the TOGAF ADM steps provide an excellent outline to discuss the different activities that are part of the process, and that is why we include it here. Note that all these steps collect and drive the refinement of business requirements that are used for business solution design. These requirements need to be carefully managed and kept in a database (often called a ''repository'').</p>
 <h3>The Preliminary Phase: Preparing and Planning the EA Effort</h3>
@@ Line 141: / Line 141: @@
 <p>One of the most important preparation activities for the EA effort is selecting the architectural framework that drives the process and organizes the collection of information. In the 1980s, people discovered that the simple BIAT layer architectural model was not complete or complex enough to effectively organize most EA efforts.
 Since then, different groups have developed ever more complex frameworks that connect the architectural aspects of BIAT with the specifics of when and how to create and use the architecture. </p>
-<p>Figure 5 depicts Capgemini's early Integrated Architecture Framework (IAF).&nbsp;[[#Twelve|[12]]] In this diagram, the BIAT aspects are shown vertically and the horizontal layers depict varying degrees of abstraction. The layers extend from the enterprise perspective down to the technical implementations through requirements management and construction:</p>
+<p>Figure 6 depicts Capgemini's early Integrated Architecture Framework (IAF).&nbsp;[[#Twelve|[12]]] In this diagram, the BIAT aspects are shown vertically and the horizontal layers depict varying degrees of abstraction. The layers extend from the enterprise perspective down to the technical implementations through requirements management and construction:</p>
 <ul>
 <li>Contextual—''Why'': the connection to the business strategy and principles</li>
@@ Line 150: / Line 150: @@
 </ul>
 <p>With these additional layers, different perspectives and dimensions of detail become more apparent than when using the simple BIAT model.</p>
-<p>[[File:IAF.jpg|600px]]<br /><div id="Figure_IAF"></div><p>'''Figure 5. Integrated Architecture Framework'''&nbsp;[[#Thirteen|[13]]]</p>
+<p>[[File:IAF.jpg|600px]]<br /><div id="Figure_IAF"></div>'''Figure 6. Integrated Architecture Framework'''&nbsp;[[#Thirteen|[13]]]</p>
-<p>Figure 6 shows the Zachman Framework in which artifacts are organized by the audience perspective and the focus of the artifact.&nbsp;[[#Eleven|[11]]] The concept was derived through observation of design artifacts of various physical objects like airplanes, buildings, ships, and computers. Zachman observed that design documents (descriptive representations, product descriptions, and engineering documentation) of complex products can be classified by the audience (the person's perspective when looking at the information) for which the artifact is constructed and by the content or subject focus (abstraction) of the artifact. </p>
+<p>Figure 7 shows the Zachman Framework in which artifacts are organized by the audience perspective and the focus of the artifact.&nbsp;[[#Eleven|[11]]] The concept was derived through observation of design artifacts of various physical objects like airplanes, buildings, ships, and computers. Zachman observed that design documents (descriptive representations, product descriptions, and engineering documentation) of complex products can be classified by the audience (the person's perspective when looking at the information) for which the artifact is constructed and by the content or subject focus (abstraction) of the artifact. </p>
 <p>Basically, the Zachman Framework is a generic classification scheme (referred to as an ''ontology'') for design artifacts. This ontology enables an EA team to focus on specific aspects of an artifact without losing the context or perspective from which it comes. In designing and building complex objects, there are simply too many details and relationships to consider simultaneously, and this structure helps decrease the complexity without losing information. </p>
-<p>[[File:Zachman_Framework.jpg|700px]]<br /><div id="Figure_Zachman"></div><p>'''Figure 6. A Populated Version of Zachman Framework for Enterprise Architecture'''&nbsp;[[#Eleven|[11]]]</p>
+<p>[[File:Zachman_Framework.jpg|700px]]<br /><div id="Figure_Zachman"></div>'''Figure 7. A Populated Version of Zachman Framework for Enterprise Architecture'''&nbsp;[[#Eleven|[11]]]</p>
 <p>The Open Group's TOGAF Enterprise Architecture Framework (http://pubs.opengroup.org/architecture/togaf8-doc/arch/) is a more generic architecture that contends that there are four architectures that make up the EA (BIAT) and all of them need to be modeled individually, but kept consistent in the process.</p>
 <p>This framework and the associate Architectural Development Method (ADM) uses concepts from the Zachman Framework, but covers each level of architecture with tools and artifacts that are most appropriate for that level. It doesn't, however, dictate any particular method for creating the architecture. The ADM even has room for integrating in other frameworks that are needed due to the domain or business drivers.</p>
@@ Line 193: / Line 193: @@
 <p>If you look carefully, you can likely see the correspondence between this business ecosystem view and some of the architecture frameworks that have been developed (and described in Section xx).</p>
 <p>Even simple concepts, like value stream or capability cross-mapping, serve as a basis for business-driven roadmaps and plans. Collectively, all of these perspectives answer important questions such as why take action, what is impacted, or how to accomplish a particular task.</p>
-<p>[[File:Figure2.2_BusinessArchitectureEcosystem.JPG]]<br /><div id="Figure_BizBOK"></div><p>'''Figure 8. The BIZBOK Business Architecture Ecosystem&nbsp;[[#Eight|[8]]]'''</p>
+<p>[[File:Figure2.2_BusinessArchitectureEcosystem.JPG]]<br /><div id="Figure_BizBOK"></div>'''Figure 8. The BIZBOK Business Architecture Ecosystem&nbsp;[[#Eight|[8]]]'''</p>
 <p>Throughout the process, the artifacts are reviewed by the stakeholders to ensure that the architecture is on track. In addition, it provides the EA team with information about the potential impact of early business architecture decisions.</p>
 <p>Once the business architecture has been reviewed and approved, all artifacts need to be added to the architectural repository.</p>