Difference between revisions of "Enterprise Architecture"

From EITBOK
Jump to: navigation, search
 
(142 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<p style="color: red">'''Note: This wiki is a work in progress, and may contain missing content, errors, or duplication.'''</p>
+
<table border="3">
----
+
<tr><td>
<div id="intro"></div><h2>Introduction</h2>
+
    <table>
<p>'''[http://eitbokwiki.org/Glossary#ea Enterprise architecture (EA)]''' is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization’s strategies.</p>
+
    <tr>
<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>
+
    <td width="60%"><font color="#246196">'''Welcome to the initial version of the EITBOK wiki.  Like all wikis, it is a work in progress and may contain errors.  We welcome feedback, edits, and real-world examples. [[Main_Page#How to Make Comments and Suggestions|Click here]] for instructions about how to send us feedback.''' </font></td>
<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 IT 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>
+
    <td width="20%">[[File:Ieee logo 1.png|100px|center]]</td>
<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, and this chapter introduces the basic concepts. </p><h2>Goals and Principles</h2>
+
    <td width="20%"> [[File:Acm_logo_3.png|175px|center]]</td>
 +
    </tr></table>
 +
</td></tr></table>
 +
<p>&nbsp;</p>
 +
 
 +
<h2>Introduction</h2>
 +
<p>'''[http://eitbokwiki.org/Glossary#ea Enterprise architecture (EA)]''' is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies.</p>
 +
<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>
 +
<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>
 +
<p>The goals of the EA effort in an organization should be:</p>
 +
<ul>
 +
<li>'''Help the enterprise understand its current operations.'''<br />A major function of EA is revealing and documenting the relationships between business elements, information elements, and the underlying information technology and technology infrastructure. By demonstrating these interrelationships from a systems level down to the most detailed element or artifact level, EA provides the information needed to connect an organization's conceptual business strategy to the execution of that strategy.</li>
 +
<li>'''Guide the organization to the desired future ("to be") state.'''<br />Carefully understand the enterprise's long-term goals and future desired state. Provide holistic information and insights to help executives and EIT make better decisions and to identify opportunities to implement solutions that enable the organization to reach the future desired state.</li>
 +
<li>'''Align EIT with the enterprise's business. ''' <br />In the best of all worlds, EA can create a bridge between the needs of the organization and the support provided by EIT. EIT/business alignment has become an increasingly widespread goal for EA, and has become the dominant value proposition for EA. Alignment activities, such as the mapping of business roles and processes to information data flows and the underlying EIT systems and technology that support them, creates this alignment.</li>
 +
<li>'''Help manage the complexity of the business, of EIT, and the relationship between the two.'''<br />The elimination of unnecessary complexity was the earliest justification for EA. Eliminating complexity makes EIT solutions easier to understand, easier to control, and, therefore, less expensive to develop, operate, and maintain. An EA-based framework and roadmap provide a means to eliminate redundancy as well as the integration of systems and data.</li>
 +
<li>'''Facilitate organizational change, transformation, and agility.'''<br />In a business and technology environment of continuous and rapid change, organizations that can anticipate and respond appropriately and quickly are more likely to survive. Robust EA processes, such as providing artifacts (requirements, specifications, guiding principles, and conceptual models) that describe the desired future state of enterprise and the path to get there can enable rapid change.</li>
 +
</ul>
 +
<p>The principles of EA include:</p>
 
<ul>
 
<ul>
<li>To assure that models of the enterprise are accurate and kept current</li>
+
<li>Architectural decisions seek to simplify operations.</li>
<li>To provide artifacts such as requirements, specifications, guiding principles, and conceptual modes that describe the next stage of evolution of an organization, often called the ''future state'' or ''to be state''.</li>
+
<li>Decisions are based on a long-term strategy, even at the expense of short-term profitability.</li>
<li>To provide the holistic information and insights to identify opportunities to execute on the enterprise strategy and make better informed decisions.</li>
+
<li>Think globally, act locally. Architectural decisions for solutions consider the impact on the entire enterprise.</li>
<li>To create a collaborative bridge between the needs of the organization and the support provided by EIT, rather than dictating to either side.</li>
+
<li>Business goals are specific, measurable, attainable, relevant, and timely.</li>
 +
<li>The definition of the desired future state and the path to get there are re-evaluated often.</li>
 +
<li>Processes and changes promote collaboration between the business and EIT.</li>
 +
<li>The effectiveness of the architecture and the adherence to the architecture must be demonstrable and measurable.</li>
 +
<li>Models are only useful when they are accurate and kept current.</li>
 
</ul>
 
</ul>
 
<h2>Context Diagram</h2>
 
<h2>Context Diagram</h2>
[[File:ContextDiagram_EnterpriseArchitecture.jpg|700px]]
+
<p>[[File:01 Enterprise Architecture v2016-05-2.png|700px]]<br />'''Figure 1. Context Diagram for Enterprise Architecture'''</p>
<p>'''Figure 1. Context Diagram for Enterprise Architecture'''</p>
+
 
<h2>What is Enterprise Architecture?</h2>
 
<h2>What is Enterprise Architecture?</h2>
<h3>The Concept of Enterprise</h3>
+
<p>The first definition listed in a dictionary for ''enterprise'' is generally some variation on the concept of an ambitious endeavor or undertaking. Subsequent definitions define it as the entity (typically an organization) that carries out such an undertaking. This latter definition is the common understanding of the meaning of enterprise within the EA community. More specifically, the term ''enterprise'' was adopted to label not just commercial undertakings, but also such organizations as governments and nonprofits within its compass.</p>
<p>The first definition listed in a dictionary for ''enterprise'' is generally some variation on the concept of an ambitious endeavor or undertaking. Subsequent definitions define it as the entity (typically an organization) that carries out such an undertaking. This latter definition is the common understanding of the meaning of enterprise within the EA community. More specifically, it is an entity that can be reasonably well modeled as comprising ''the business'' and ''EIT'', including such organizations as governments and nonprofits within its compass.</p>
+
<h3>The Concept of Architecture</h3>
+
 
<p>The formal definition of architecture cited most frequently by the EA community is the definition from ISO/IEC/IEEE 42010:2011: </p>
 
<p>The formal definition of architecture cited most frequently by the EA community is the definition from ISO/IEC/IEEE 42010:2011: </p>
<div style="margin-left: 5em;"><p>''... “architecture” means whatever the framework being used (explicitly or implicitly) implies it is by the various architectural representations it recommends for use. ''&nbsp;[[#Two|[2]]]</p></div>
+
<div style="margin-left: 5em;"><p>''"... "architecture" means whatever the EA framework being used (explicitly or implicitly) implies it is by the various architectural representations it recommends for use. "''&nbsp;[[#Two|[2]]]</p></div>
<h3>A Definition of Enterprise Architecture</h3>
+
<p>The Federation for Enterprise Architecture Professional Organizations (FEAPO) defines enterprise architecture as follows:</p>
<p>The Federation for Enterprise Architecture Professional Organizations (FEAPO) defines EA as follows:</p>
+
<div style="margin-left: 5em;"><p>''"Enterprise architecture is a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."''&nbsp;[[#Three|[3]]]</p></div>
<div style="margin-left: 5em;"><p>''“Enterprise architecture is a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes.''&nbsp;[[#Three|[3]]]</p></div>
+
<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>
<p>Analogies between enterprise architecture 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>
+
<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]]
+
<h3>Evolution of Enterprise Architecture</h3>
<div id="Figure_Urban"></div><p>'''Figure 2. Urban Planner and Enterprise Architect versus Building Architect and Solution Architect&nbsp;[[#Three|[3]]]'''</p>
+
<p>The need for EA arose for two reasons. The first reason was driven by technology. The arrival of distributed computing in the 1980s resulted in increased EIT complexity due to additional scale, diversity, and connectivity in the computing environment. This additional complexity lead to significantly higher EIT development, support, and operational costs. With rising costs came pressure from management to slow the growth of EIT budgets and increase the business effectiveness of EIT support. Directives to "do more with less" and unrelenting pressure to increase efficiency and effectiveness required new approaches to EIT strategy. To some extent, consolidation, standardization, and commoditization worked as EIT expense reduction strategies; however, there were limits to their effectiveness, because they still lacked a holistic and systematic understanding of the connectedness between business roles and processes, information data elements and flows, supporting application systems, and underlying technology infrastructure. </p>
<h2>A Brief History of Enterprise Architecture</h2>
+
<p>The need for enterprise architecture arose for two separate reasons. The first reason was driven by technology. The arrival of distributed computing in the 1980s resulted in increased IT complexity due to additional scale, diversity, and connectivity in the computing environment. The additional complexity lead to significantly higher EIT development, support, and operational costs. With rising costs came pressure from management to slow the growth of EIT budgets and increase the business effectiveness of EIT support. Directives to “do more with less” and unrelenting pressure to increase efficiency and effectiveness required new approaches to EIT strategy. To some extent, consolidation, standardization, and commoditization worked as EIT expense reduction strategies; however, there were limits to their effectiveness, because they still lacked a holistic and systematic understanding of the connectedness between business roles and processes, information data elements and flows, supporting application systems, and underlying technology infrastructure. </p>
+
 
<p>The second motivation for EA was business-driven, due to the ever-increasing pace of external change combined with the difficulty for many organizations to successfully execute their business strategies. Michael Porter estimates that more than 80 percent of organizations fail to execute their business strategies, and ineffective execution was the reason for failure for more than 70 percent of them.&nbsp;[[#Four|[4]]] The principles and practices in EA help enterprise managers move their organizations from where they are to where they want them to be. </p>
 
<p>The second motivation for EA was business-driven, due to the ever-increasing pace of external change combined with the difficulty for many organizations to successfully execute their business strategies. Michael Porter estimates that more than 80 percent of organizations fail to execute their business strategies, and ineffective execution was the reason for failure for more than 70 percent of them.&nbsp;[[#Four|[4]]] The principles and practices in EA help enterprise managers move their organizations from where they are to where they want them to be. </p>
<p>Based on whether one views EA solely for technology-based or business strategy-based reasons, the scope of EA, including its concerns, assumptions, and limitations varies. One of the most cogent analyses of the range of EA definitions was presented by James Lapalme, who describes three schools of thoughts on EA:&nbsp;[[#Five|[5]]]</p>
+
<p>Based on whether one views EA solely for technology-based or business strategy-based reasons, the scope of EA varies, including its concerns, assumptions, and limitations. One of the most cogent analyses of the range of EA definitions was presented by James Lapalme, who describes three schools of thoughts on EA:&nbsp;[[#Five|[5]]]</p>
<ol>
+
<ul>
<li>Enterprise-wide IT platform (effective enterprise strategy execution and operation through EIT-business alignment)</li>
+
<li>Enterprise-wide IT platform—Effective enterprise strategy execution and operation through EIT-business alignment)</li>
<li>Enterprise (effective enterprise strategy implementation through execution coherency)</li>
+
<li>Enterprise—Effective enterprise strategy implementation through execution coherency</li>
<li>Enterprise-in-environment (innovation and adaptation through organizational learning)</li>
+
<li>Enterprise-in-environment—Innovation and adaptation through organizational learning</li>
</ol>
+
</ul>
<p>Nick Malik builds on Lapalme’s three schools, and describes three categories of EA application:&nbsp;[[#Six|[6]]]</p>
+
<p>Nick Malik builds on Lapalme's three schools, and describes three categories of EA application:&nbsp;[[#Six|[6]]]</p>
 
<ol>
 
<ol>
<li>Enterprise IT architecting</li>
+
<li>Enterprise IT architecting—Designing EIT services and creating EIT systems that address the enterprise's needs</li>
<li>Enterprise integrating</li>
+
<li>Enterprise integrating—Aligning the business with all of its capabilities, including EIT; using capability analysis to understand the impacts of strategy on the business processes and systems, and helping to frame the initiatives that should be created, and insures that investments are made in the right place</li>
<li>Enterprise ecological adaptation</li>
+
<li>Enterprise ecological adaptation—Analyzing the movements of the market, and working closely with business leaders to develop strategies based on the capabilities and positioning of the company that are likely to generate new revenue, improve market position, improve customer loyalty, and reduce costs</li>
 
</ol>
 
</ol>
<p>These differences between these categories vis depicted graphically in [[#Figure_EA_schools|Figure&nbsp;3]].</p>  
+
<p>The differences between these categories is depicted graphically in [[#Figure_EA_schools|Figure&nbsp;3]].</p>  
[[File:EA_schools.png]]
+
<p>[[File:EA_schools.png]]<br /><div id="Figure_EA_schools"></div>'''Figure 3. EA Schools of Thought'''&nbsp;[[#Six|[6]]]</p>
<div id="Figure_EA_schools"></div><p>'''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 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, as well as between EA and EIT governance and strategy, are 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>
<p>Regardless of the school of thought, a framework for EA is needed to describe the interconnectedness of the business, information, systems, and technology elements (often called ''artifacts''). In 1987, John Zachman published what is commonly viewed as the first framework describing a classification scheme for artifacts at several levels of abstraction.&nbsp;[[#Seven|[7]]] In the 1990s, a reference model was developed for EA by and for the US Department of Defense (DoD) called the Technical Architecture Framework for Information Management (TAFIM).</p>
+
<p>In 1995, based on TAFIM, The Open Group Architecture Framework (TOGAF) had its first release. Since then, TOGAF has evolved and released TOGAF 9.1 in 2011. It maintains that “a complete EA description should contain all four architecture domains (business, data, application, technology), but the realities of resource and time constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive architecture description encompassing all four architecture domains, even if the enterprise scope is ... less than the full extent of the overall enterprise.”&nbsp;[[#Nine|[9]]] </p>
+
<p>While TOGAF may be the most popular EA framework (based on published certification numbers), there are many different frameworks available. Generally, they fall into these types: consortia-developed (e.g., TOGAF), defense industry (e.g., DODAF (U.S.)), government (e.g., E-overheid NORA (Dutch), open-source (e.g., MEGAF), and proprietary (e.g., Capgemini’s IAF).&nbsp;[[#Ten|[10]]]</p>
+
 
+
<h2>The Purpose and Value of Enterprise Architecture</h2>
+
<p>As noted in the [[#intro|Introduction]], the driving force behind enterprise architecture has changed since its initial appearance. Four purposes or value propositions for EA are frequently given:</p>
+
 
<ul>
 
<ul>
<li>Manage, if not master complexity</li>
+
<li>The alignment of the business and EIT is achieved by aligning EIT with the business.</li>
<li>Ensure business/EIT alignment</li>
+
<li>The agility of the enterprise is a consequence of the agility of the EIT function.</li>
<li>Facilitate successful organizational change, transformation, and agility</li>
+
<li>The transformative value of EA is typically delivered by transforming the application and technology architectures. The amount of change engendered by an EA initiative might be small at the business layer, but it typically increases as the design progresses closer to the details of the applications and systems.</li>
<li>Bridge strategy and execution</li>
+
 
</ul>
 
</ul>
<p>A common comparison is with city planning, where EA maintains the “master plan” for the enterprise’s  business/technology integration.</p>
+
<h3>Layers or Aspects of Enterprise Architecture</h3>
<h3>Manage Complexity</h3>
+
<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>The elimination of unnecessary complexity was the earliest justification for EA. Eliminating complexity makes systems easier to understand, easier to control, and, therefore, less expensive to develop, operate, and maintain. In a large organization with multiple units, different systems and business processes often start at different times or in different geographies. For example, an organization might have multiple human resource (HR) systems, overlapping sales forecasting systems, or disconnected procurement systems. An EA-based framework and roadmap supports the elimination of redundancy as well as the integration of systems and data.</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>
<h3>Business and IT Alignment</h3>
+
<p>[[File:BIAT-Models.jpg]]<br /><div id="Figure_BIAT"></div>'''Figure 4. Conventional BIAT Diagram and the 5-Layer BIAT Diagram''' </p>
<p>In an effort to speak the language of the enterprise's business, the complexity reduction rationale fell into disuse as the EA community shifted its focus of the value proposition for EA to ''business and IT alignment''. The alignment rationale has become increasingly widespread, and remains the dominant value proposition for EA. One important alignment activity is the mapping of business roles and processes to information data flows and the underlying EIT systems and technology that support them.</p>
+
<p>The meanings of the layers are described below.</p>
<h3>Change, Transformation, and Agility</h3>
+
<p>Another justification for EA has been the support of change and transformation via organizational agility. In a business and technology environment of continuous and rapid change, organizations that can anticipate and respond appropriately and quickly are more likely to survive. Robust EA processes can support rapid change. </p>
+
<p>The belief is that changes in the business environment can require “disruptive” changes in the EIT environment, and therefore, a strategically agile EIT function enables agility in the entire organization. The motivation for disruptive change can come from new competition, a merger or acquisition, or a new technology that the business wants to adopt.  The push for change can come from either the business or IT; but because of this important symbiotic relationship between the enterprise and EIT, it is important for both to be agile and able to adapt quickly to change.</p>
+
<h3>Strategy and Execution</h3>
+
<p>A major function of EA is revealing and documenting the relationships between business elements, information elements, and the underlying information technology and technology infrastructure. By demonstrating these interrelationships from a systems level down to the most detailed element or artifact level, EA provides the information needed to connect an organization’s conceptual business strategy to the execution of that strategy.</p>
+
 
+
<p>Over the last several decades, enterprises of all types, whether in manufacturing, finance, HR, or systems integration, have moved from vertically integrated entities to horizontally interdependent supply chains.&nbsp;[[#Fifteen|[15]]] The ways that enterprises compete and what they create internally versus what they source externally has moved from physical elements and on-site infrastructure to applications and off-site data centers. This change started with hardware infrastructure, moved into software infrastructure, and continued into applications, information, and even specialized business functions. EA methodologies help EIT and enterprise management see the connection between business processes and the EIT services those processes depend on, thereby enabling the transformation. </p>
+
<h2>The Conventional Wisdom</h2>
+
<p>There are three almost universally adopted concepts that characterize the current state of the art of enterprise architecture: </p>
+
<ul>
+
<li>The four layer stack model (the four aspects) of an enterprise</li>
+
<li>The delineation of ''as is'' and ''to be'' states</li>
+
<li>The use of frameworks</li>
+
</ul>
+
<h3>The Umbrella Nature of Enterprise Architecture: Layers or Aspects</h3>
+
<p>The conventional model (called the BIAT model [http://eitbokwiki.org/Glossary#biat]) of an organization’s EA is sometimes represented as a four layer horizontal ''stack'' (see [[#Figure_BIAT|Figure&nbsp;4]]). </p>
+
 
+
[[File:BIAT_diagram.jpg]]
+
<div id="Figure_BIAT"></div><p>'''Figure 4. Conventional BIAT Diagram''' (Note: In some diagrams, the ''layers'' are shown vertically and might be called ''domains'' or ''aspects''.) </p>
+
 
<h4>Business Layer</h4>
 
<h4>Business Layer</h4>
<p>Within the EITBOK, the term ''business'' is used synonymous with ''enterprise''. While it may seem odd, it appears that there is no universally excepted definition of ''business'' within the EA community. Instead, the EA community simply knows what business means; however, some sense of what business is, can be inferred from the stack metaphor &mdash; it is whatever is ultimately supported by the technology layer.</p>
+
<p>Within the EITBOK, the term ''business'' is used synonymous with ''enterprise''. While it may seem odd, it appears that there is no universally excepted definition of ''business'' within the EA community. This layer usually contains business rules and requirements, organizational structure, business processes and models, the mission and vision of the enterprise, and critical success factors.</p>
 
<h4>Data or Information Layer</h4>
 
<h4>Data or Information Layer</h4>
<p>In the BAIT model, ''information'' is associated with business information and other valuable stored data. Every enterprise runs on information, and therefore, the patterns of information used by the business largely determine the data technology required to support the information needs. </p>
+
<p>In the BIAT model, ''information'' is associated with business information and other valuable stored data. Every enterprise runs on information, and therefore, the patterns of information used by the business largely determine the data technology required to support the information needs. This layer contains data information and architecture, data management, data delivery, data modeling, data quality, data security, and content management, as well as enterprise reporting and business intelligence. </p>
 
<h4>Applications Layer</h4>
 
<h4>Applications Layer</h4>
<p> Software applications consume, transform, and produce data or information needed by the enterprise's technology users. Often, the heaviest information "consumers" are in HR and finance units, although software increasingly supports facilities management, inventory control, customers, and vendors.</p>
+
<p>Software applications consume, transform, and produce data or information needed by the enterprise's technology users. Often, the heaviest information "consumers" are in HR and finance units, although software increasingly supports facilities management, inventory control, customers, and vendors. This layer contains application integration components, application development models, the definition of services, and service and event architectures.</p>
 
<h4>Technology Layer</h4>
 
<h4>Technology Layer</h4>
<p>The technology domain includes processors, storage and network connectivity, and the middleware that provide the basic computing and communications capabilities for the enterprise. They enable the flow of information that is the lifeblood of the organization. Note that the EIT technology domain thus does not typically include physical process technology such as industrial or manufacturing automation technologies. </p>
+
<p>The technology domain includes processors, storage and network connectivity, and the middleware that provide the basic computing and communications capabilities for the enterprise. They enable the flow of information that is the lifeblood of the organization. Note that the EIT technology domain thus does not typically include physical process technology such as industrial or manufacturing automation equipment. Often this layer is split into a software and hardware component.</p>
<h4>Where the Action Is</h4>
+
<h4>Relationship Between Layers</h4>
<p>Three unstated presumptions of the BIAT model are that
+
<p>The business and information layers serve primarily as inputs to the technology design process. However, if the process is rigidly viewed this way, the EA team may run the risk of not putting enough effort into the collaboration and partnership with the enterprise's "business" partners. Such collaboration ensures that the changes in the business processes and information flows support the changes made to the applications and technology layers. </p>
 +
<p>It is common within the EA community to recognize that each of these layers has its own architecture, and that the enterprise architecture is in some sense the sum or union of all these architectures. At the same time, it is also commonly stated within the EA community that the enterprise consists of ''businesses + EIT'', and therefore, that the enterprise architecture is comprised of ''business architecture + EIT architecture''. Digging deeper, EIT architecture is comprised of ''data/information architecture'', ''applications architecture'', and ''technology architecture'', although it is often agreed that the data/information architecture can straddle the boundary between the business and EIT domains).</p>
 +
<p>There are several different models in use for how the integration across the layers or aspects is best achieved. One of the most common is the service model, in which each layer delivers services to the layers above it. Not surprisingly, the question of what exactly makes something a service remains a subject of considerable discussion. Other models focus on the enterprise's value chain, also known as enterprise capabilities.</p>
 +
<h3>Role of Architecture in Strategy Planning</h3>
 +
<p>[http://eitbokwiki.org/Glossary#ea Enterprise architecture (EA)] informs strategic planning in several ways. EA supplies "a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands."&nbsp;[[#Seven|[7]]] The blueprint comes in the form of a variety of architectural or design artifacts, such as strategy maps, capability maps, information maps, value maps, and organization maps. These maps provide a variety of perspectives, such as data and processes the enterprise uses to carry out its operations, how processes interact to create value streams, and where technology support is in place. EA provides input to the strategy function at the highest level.</p>
 +
<p>Typically, few artifacts exist when the initial EA program is started. They must be developed with input from all the business stakeholders. </p>
 +
<p>Given the amount of information required to produce the enterprise blueprint, a framework is needed to describe the interconnectedness of the business, information, systems, and technology elements (often called artifacts). In 1987, John Zachman published what is commonly viewed as the first framework describing a classification scheme for artifacts at several levels of abstraction.&nbsp;[[#Eight|[8]]] In the 1990s, a reference model was developed for EA by and for the US Department of Defense (DoD) called the Technical Architecture Framework for Information Management (TAFIM).</p>
 +
<p>In 1995, based on TAFIM, The Open Group Architecture Framework (TOGAF) was first released. TOGAF 9.1 was release in 2011 and it is considered a proven EA methodology. It states that "a complete EA description should contain all four architecture domains (business, data, application, technology), but the realities of resource and time constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive architecture description encompassing all four architecture domains, even if the enterprise scope is ... less than the full extent of the overall enterprise."&nbsp;[[#Nine|[9]]] </p>
 +
<p>While TOGAF may be the most popular EA framework (based on published certification numbers), there are many different frameworks available. Generally, they fall into several categories: consortia developed (e.g., TOGAF), defense industry focused (e.g., DODAF (U.S.)), government-based (e.g., E-overheid NORA (Dutch), open-source (e.g., MEGAF), and proprietary (e.g., Capgemini's IAF).&nbsp;[[#Ten|[10]]]</p>
 +
<h2>EA Activities</h2>
 +
<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>'''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>Preliminary Phase: Preparing and Planning the EA Effort</h3>
 +
<p>During the planning phase, members of senior management (usually members of the strategy team) define the purpose and focus of the EA program, create the EA team, and define the roles of the team members. Once that is accomplished, the EA team selects the EA framework that will be used by the effort and makes sure that there is an EA information repository in place.</p>
 +
<p>The EA team begins its work by collecting information about the workings of the enterprise. More than anything else, the EA effort results in an actionable plan to achieve the enterprise's strategic objectives. The plan needs to consider laws, mandates, and policies that drive the business. The plan typically builds on the organization's strengths and leverages opportunities, while considering both internal and external impediments and barriers. The EA plan provides the bridge between strategy and execution. Thus, the EA can drive organizational change, enabling the enterprise to achieve important mission outcomes and enhance business success.</p>
 +
<h4>Specify the EA Team's Priorities, Scope, and Budget</h4>
 +
<p>Once an EA effort has been agreed upon, the enterprise's management needs to give the effort a charter. This charter could be well defined or not; however, the effort is most successful if management can provide information such as:</p>
 
<ul>
 
<ul>
<li>The transformative value of EA is typically delivered by transforming the application and technology layers,</li>
+
<li>What the team should work on and what the priorities are; this include at least some idea of what the desire state of the organization is</li>
<li>The agility of the enterprise is a consequence of agility of the EIT function, and</li>
+
<li>What the team needs to accomplish and by when </li>
<li>The alignment of the business and EIT is achieved by "aligning EIT" with the business.</li> </ul>  
+
<li>Who the team reports to, how often they should report, and what they should report</li>
<p> In the best case, the amount of change engendered by an EA initiative should be minimal at the business layer and should increase downward in the BAIT layers, forces most of the changes to the technology layer.  In essence, the business and information domains primarily serve as inputs to the technology design process. However, if the process is rigidly viewed this way, EA may run the risk of not putting enough effort into the collaboration and partnership with the enterprise’s “business” partners. Such collaboration assures that the changes in the business processes and information flows are accurately reflected in the changes made to the applications and technology layers.</p>
+
<li>How the process is going to be governed</li>
 
+
<li>The budget for the EA project</li>
<p>It is common within the EA community to recognize that each of these layers has its own architecture, and that the enterprise architecture is in some sense the sum or union of all these architectures. At the same time, it is also commonly stated within the EA community that the enterprise consists of ''businesses + IT'', and therefore, that the enterprise architecture is comprised of ''business architecture + IT architecture''.  Digging deeper IT architecture is comprised of ''data/information architecture'', ''applications architecture'', and ''technology architecture'', although it is often agreed that the data/information architecture can straddle the boundary between the business and EIT domains).</p>
+
</ul>
 
+
<p>With this in place, the team can be identified.</p>
<p>The stack metaphor is derived from the idea that the technology architecture is ultimately driven by the needs of the business domain/architecture (an expression of the business/EIT alignment rationale), with the data/information and applications architectures as key waypoints.</p>
+
<h4>Determine EA Team Members</h4>
<p>There are several different models in use for how this integration across the layers or aspects is best achieved. One of the most common is the ''service model'', in which each layer delivers services to the layers above it. Not surprisingly, the question of what exactly makes something a ''service'' remains a subject of considerable discussion. Other models focus on the enterprise’s value chain, also known as enterprise capabilities.</p>
+
<p>Selecting the EA team members is often a difficult process. One needs to have a chief architect who understands the business and communicates well with people at all levels in the organization. This person must be technically savvy, have EA experience, be good at working with diverse groups with diverse agendas, and be excellent at project management in difficult situations. Few organizations start out with this kind of talent, so it is common for organizations to hire EA consulting firms to get them started, and to help them build and train their own internal team.</p>
<p>[[#Figure_Modified_BIAT|Figure&nbsp;5]] depicts a variation of the conventional BIAT diagram. It shows that the focus of EA practice is on business processes. It also divides the technology domain into software and hardware infrastructure, because they are qualitatively different in nature. This diagram is used later to illustrate the relationship between EA and other enterprise-related architectures.</p>
+
<p>You can have an EA team of one, the Lead Enterprise Architect. However, usually the job requires information from several business experts and EIT experts. The number of roles and their duties depends on the scope of the EA effort. Common roles that are often consulted are: </p>
[[File:BIAT_diagram_modified.jpg]]
+
<div id="Figure_Modified_BIAT"></div><p>'''Figure 5. Modified BIAT Diagram'''</p>
+
<h3>The As Is and To Be States</h3>
+
<p>As noted earlier, EA serves a key role in organizational transformation by bridging strategy to execution. (You can’t get where you want to go unless you know where you are.) Essentially, one needs to understand the current ''as is'' state relative to the desired ''to be'' state, identify the gaps, and chart a plan or roadmap to get from today’s state to the future. 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;6]].&nbsp;[[#Fourteen|[14]]]</p>
+
[[File:TOGAF.png]]
+
<div id="Figure_TOGAF"></div><p>'''Figure 6. TOGAF 9.1 ADM Steps'''&nbsp;[[#Fourteen|[14]]]</p>
+
<h3>Evolving Frameworks </h3>
+
<p>Instead of using the different layers of the BIAT model, several frameworks add a second (vertical) dimension that connects the architectural aspects of BIAT with the specifics of when and how to create and use the architecture. Two examples are provided: the [http://eitbokwiki.org/Glossary#zachman Zachman Framework], which is one of the first frameworks for EA, and a simpler version, the [http://eitbokwiki.org/Glossary#iaf Integrated Architecture Framework (IAF)]. In both frameworks, the layers ultimately extend from the enterprise perspective down to the technical implementations through requirements management and construction:</p>
+
 
<ul>
 
<ul>
<li>Contextual &mdash; the ''why''; the connection to the business strategy and principles</li>
+
<li>Business Architect</li>
<li>Conceptual &mdash; the ''what''; the service level</li>
+
<li>Information Architect</li>
<li>Logical &mdash; the ''how''; the logical flows</li>
+
<li>Security Architect</li>
<li>Physical &mdash; the ''with what''; the specific elements</li>
+
<li>Solution Architect</li>
 +
<li>Domain Architect</li>
 +
<li>Project Architect</li>
 +
<li>Application Architect</li>
 +
<li>Business Unit Manager</li>
 +
<li>Subject Matter Expert</li>
 +
<li>Process Owner</li>
 +
<li>Compliance Manager</li>
 +
<li>HR Manager</li>
 +
<li>Finance Manager</li>
 
</ul>
 
</ul>
<p>[[#Figure_Zachman|Figure&nbsp;7]] shows a more detailed and complex framework, in which the business, information, applications, and technology are vertical "domains" rather than layers. This is the [http://eitbokwiki.org/Glossary#zachman Zachman Framework], and it was groundbreaking when it was introduced.&nbsp;[[#Eleven|[11]]] </p>
+
<p>Note that the team often starts small and increases in size as the EA effort progresses. Many of the future EA activities require a specialist for that particular activity, such as the application architect.</p>
[[File:Zachman_Framework.jpg|700px]]
+
<h4>Identify Business Drivers, Impediments, and Barriers</h4>
<div id="Figure_Zachman"></div><p>'''Figure 7. Zachman Framework for Enterprise Architecture'''&nbsp;[[#Eleven|[11]]]</p>
+
<p>The team needs to identify the internal and external forces that push the enterprise in specific directions. Drivers can come from governmental legislation, policy, business competition, technology changes, cost changes, organizational restructuring and consolidation, or facility changes. These drivers often result in the definition of key business requirements and strongly affect the architecture at many levels.</p>
<p>[[#Figure_IAF|Figure&nbsp;8]] depicts the [http://eitbokwiki.org/Glossary#iaf Integrated Architecture Framework (IAF)] in less detail than the Zachman Framework figure.&nbsp;[[#Twelve|[12]]] In this diagram, the BIAT aspects are shown vertically and the horizontal layers depict varying degrees of abstraction: contextual (the ''why''), conceptual (the ''what'' or service layer), logical (the ''how'' including processes), and, finally, the physical (the ''with what'' layer). Adding the transformational (the ''when''), it includes the dynamic dimension, from the current or existing state to the future state.</p>
+
<p>Barriers and impediments obstruct or delay the progress of developing or maintaining a useful EA. Barriers hinder development of the EA to accommodate a need or constraint in contrast to drivers, which direct or push the architecture in particular ways. </p>
[[File:IAF.jpg|600px]]
+
<p>This activity starts in the preliminary phase, but is fleshed out extensively in future phases of the EA project.</p>
<div id="Figure_IAF"></div><p>'''Figure 8. Integrated Architecture Framework'''&nbsp;[[#Thirteen|[13]]]</p>
+
<h4>Select Architectural Framework, Methods, and Processes</h4><div id="archframework"></div>
<p> With these additional layers, different perspectives and dimensions of detail become more apparent than in the simple BIAT model.</p>
+
<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>
<h2>The Geography of Enterprise IT Architecture and Links to Other Disciplines</h2>
+
<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>
<p>Enterprise architecture is valuable and useful if it influences and integrates the inputs and outputs of other architecture disciplines into the enterprise, as well as bridges between the enterprise strategy and the IS/EIT projects. </p>
+
<h3>The Relationship between EA and Other Architectures</h3>
+
<p>A recent survey conducted by the Journal of Enterprise Architecture asked survey respondents for their titles. Among the respondents who had ''architect'' in their title, there were 21 different non-level-related modifiers. Labels that architects use rather than enterprise architect include business process architect, information architect, applications architect, solution architect, software architect, middleware architect, infrastructure architect, network architect, network storage architect, and hardware architect.</p>
+
<p>[[#Figure_Enterprise|Figure&nbsp;9]] shows that the simple view of enterprise architecture (first introduced in [[#Figure_Modified_BIAT|Figure&nbsp;5]]) also describes other typical architecture types. All of them must consider solution, information, application, software, middleware, infrastructure, and network storage.</p>
+
[[File:Architectures.jpg|700px]]
+
<div id="Figure_Enterprise"></div><p>'''Figure 9. Enterprise and Other Enterprise-related Architectures'''</p>
+
<h3>The Relationship between Enterprise Architecture and Enterprise IT</h3>
+
<p>EA serves as a bridge between the enterprise’s vision and strategy and how the underlying layers of business elements (including business processes and people) are organized, as well as the flow of information and data elements. Business processes and information are not necessarily ''automated'' with IS/IT. For example, without IS/IT ''automation'', workers can manually take measurements, create reports, and deliver data and information in those reports. On the other hand, where business process and information flows are ''automated'' with IS/EIT, EA describes the interdependencies and linkages between the business (organization), information, applications, and technology infrastructure. </p>
+
<p>In contrast, enterprise IT (EIT) consists of the applications and technology infrastructure that supports the applications, so today EIT is increasingly seen as a subset of EA. </p>
+
<p>Distinguishing between EA and EIT is important, and by doing so, an organization should clearly recognize that there is a choice to either support business roles, business processes, and information flows with automation (i.e., IS/EIT) or keep them manual. Likewise, the governance and influence of EA is different than the governance and influence of EIT.</p>
+
<p>Artifacts (i.e., outputs or deliverables) from EA are found as inputs to strategy and governance as well as requirements (and subsequently, construction). Here are some examples:</p>
+
 
<ul>
 
<ul>
<li>Strategy maps</li>
+
<li>Contextual—''Why'': the connection to the business strategy and principles</li>
<li>Capability maps</li>
+
<li>Conceptual—''What'': the service level</li>
<li>Information maps</li>
+
<li>Logical—''How'': the logical flows</li>
<li>Value maps</li>
+
<li>Physical—''With what'': the specific elements</li>
<li>Heat maps</li>
+
<li>Transformational—''When'': the dynamic dimension that specifies when the organization will change to the desired state</li>
<li>Organization maps</li>
+
<li>Operating models</li>
+
<li>Product maps</li>
+
<li>Stakeholder maps</li>
+
<li>Process models</li>
+
<li>Dynamic rules based routing maps</li>
+
<li>Data models</li>
+
<li>Network models</li>
+
<li>Systems models</li>
+
<li>Vitality and renewal plans</li>
+
<li>A wide range of hybrid blueprints and models with specialty uses based on the challenge at hand</li>
+
 
</ul>
 
</ul>
<h3>Solutions and Their Relationship to EA</h3>
+
<p>With these additional layers, different perspectives and dimensions of detail become more apparent than when using the simple BIAT model.</p>
<p>There are different ways to view the landscape of the enterprise’s IT architecture. At the fundamental level, EA physical and logical artifacts describe the elements that support the organization’s operations. At a more conceptual level, there are the business, information, information technology, and infrastructure services. These can be related to an organization’s capabilities. Relatively speaking, these can be characterized in a colored heat map that uses color to represent different attributes or identify focus areas in a data set. Depending on the organization’s strategy, the capabilities that are most in need of improvement might be the first priority. Improvement/replacement costs, interdependencies with other capabilities and systems, risks of not improving, and so on are inputs to the prioritization process. The funding and governance of the improvement work (in the form of projects and programs) are strongly influenced by EA and typically overseen by a program management office (see the [http://eitbokwiki.org/Strategy_and_Governance Change Strategy and Governance chapter]). The projects and programs develop solution architectures and these solution architectures need to be compliant to and synergistic with the evolving enterprise architecture.</p>
+
<p>[[File:IAF.jpg|600px]]<br /><div id="Figure_IAF"></div>'''Figure 6. Integrated Architecture Framework'''&nbsp;[[#Thirteen|[13]]]</p>
<h3>EA and Nonfunctional Requirements or Cross-layer Concerns</h3>
+
<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>The [http://eitbokwiki.org/Requirements Requirements chapter] discusses the two types of requirements, functional and '''[http://eitbokwiki.org/Glossary#non-functional_requirements non-functional]'''. While EA influences both types, its impact on functional requirements is more obvious. However, EA also influences nonfunctional requirements and can do so through the overriding EA principles as well as in what are called ''collaboration contracts'' between EA artifacts. Here are some examples.</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>'''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>
 +
<p>There are many other frameworks and some are defined for specific domains or technologies. Some of these frameworks are proprietary and others are available for anyone to use. To see a list of both EAs and solution architectures, visit http://www.iso-architecture.org/42010/afs/frameworks-table.html.</p>
 +
<p>In general, the EA team selects the framework or frameworks that best match the enterprise's needs, the maturity of the organization, and the team's comfort and experience with the framework.</p>
 +
<h3>Developing an Enterprise Architecture</h3>
 +
<p>Developing an EA includes all the activities associated with creating and maintaining the enterprise architecture for a specific purpose. The EA plan provides the blueprint for transforming the enterprise from the current state to the desired end state that can execute the desire outcomes. That desired state will likely need to address organizational change, business process transformations, data integration, systems reengineering, and technology modernization.</p>
 +
<p>EA serves as a bridge between the enterprise's vision and strategy and how the underlying layers of business elements (including business processes and people) are organized, as well as the flow of information and data elements. Business processes and information are not necessarily automated by EIT. For example, without EIT automation, workers can manually take measurements, create reports, and deliver data and information in those reports. Nonetheless, a complete EA includes those un-automated business elements. On the other hand, where business process and information flows are automated with EIT, EA describes the interdependencies and linkages between different parts of the enterprise, information, applications, and technology infrastructure. </p>
 +
<p>Distinguishing between EA and EIT is important, and by doing so, an organization should clearly recognize that there is a choice to either support business roles, business processes, and information flows with automation or keep them manual.</p>
 +
<h4>Develop the Architectural Vision</h4>
 +
<p>Once senior management has approved the start of the architectural work, the first task is to create the architectural vision. The ''architecture vision'' is a high-level description of the current and desired architectures, most likely an enhanced vision from the outputs from senior management's strategic planning sessions (see [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance]). </p>
 +
<p>The vision describes what will be delivered and its desired impact on the organization, including the business, data, application, and technology layers. These high-level descriptions are further developed in subsequent phases. The architectural vision also typically outlines a program to develop and deploy the vision. </p>
 +
<p>The artifact of this effort is often called the ''Statement of Architecture Work''. This document is circulated among management and all the stakeholders to build a consensus. This consensus building process is critical and can make or break the entire EA effort. And, one of the most important aspects of this document is the definition of the scope of the effort.</p>
 +
<h5>Define the '''As Is''' and '''To Be''' States</h5>
 +
<p>Whether developing a long-term enterprise strategy or understanding your current and desired technical architectural capacity, you can't get to where you want to go unless you know where you are. The EA planning process needs to clearly understand the enterprise's and EIT's current (a.k.a. "as is") states as well as the direction the enterprise wants to head, in other words, the desired (a.k.a. "to be") states. This is a careful analysis process and it is critical to the success of the endeavor. </p>
 +
<p>Along with definition of these states, this process should be able to define the purpose of the upcoming EA effort. What does the business want to accomplish with the project? What elements of the business are not well aligned and must be corrected in the future? The team identifies the investment decisions or technical directions that need guidance.</p>
 +
<p>The strategy is most often a long-range plan for achieving organizational goals to meet mission priorities while effectively using available resources. A strategy is often formulated to help an organization achieve an economic, competitive, or positional advantage.</p>
 +
<p>It is important to note that there is significant disagreement as to exactly how to define the "as is" and "to be" states. Some AE teams believe that you should describe the current state first and then create the vision of the future state. Others AE teams believe that you should define the future state before understanding the current state. This second group believes that if you know the current state well, it will influence your vision of the future state too much. They believe that people have a tendency of "editing" their vision of the future based upon what they already know about the present. It is true that the future state definition might need to be "scaled back" when it is determined to be unfeasible; however, during this phase, the vision of the future should be relatively unbridled.</p>
 +
<h5>Define the Scope of the EA Effort</h5>
 +
<p>The scope of the EA establishes many aspects of this current EA project. In essence, the team defines what part of the "to be" or desired state they want to focus on in this current cycle. Things that can be considered are:</p>
 
<ul>
 
<ul>
<li>'''Business service collaboration contracts:''' A business service, or a set of business processes like a financial operation and its expectations in receiving information data elements from a sales service (e.g., an order entry from a sales operation).</li>
+
<li>'''The organizations within the business that are in focus'''—Not only are the actual organizations identified, but a specific business process or data set may be selected. In the best of all worlds, the entire enterprise or organization is addressed; however, resources don't always allow that to happen.
<li>'''Technology infrastructure component collaboration contracts:''' Storage components and networking components. Collaboration contracts between the two might be the quality and reliability expectations in terms of up time, error-free processing, messaging, latency, and so on. </li>
+
<li>'''The areas of technology'''—At times, an EA planning cycle only covers selected areas or levels of technology. One year, an organization might focus on establishing the EA for communications of the organization (which could include telecom, intranet, internet, and other connectivity). The next year, they might focus on mobile support.
 +
<li>'''The level of detail that needs to be included in the EA'''—The EA should contain enough detail to:
 +
<ul>
 +
<li>Plan major investments, their lifecycles, and projected costs.</li>
 +
<li>Demonstrate that the enterprise strategy is supported by the EA in the timeframe needed. </li>
 +
<li>Ensure that needed interfaces between organizations and between EIT systems are adequately specified. </li>
 +
<li>Guide systems engineers who are developing designs and specifications for implementing specific investments. </li>
 
</ul>
 
</ul>
<p>In these contracts, expectations of various qualities are defined and documented in delivery projects as nonfunctional requirements. By keeping the close association between the collaboration contracts of all the artifacts in the EA repository with the nonfunctional requirements in the enterprise IT portfolio of projects, the quality requirements and expectations across the enterprise can be balanced.</p>
+
<p>On the other hand, the EA should not be so detailed that it over-constrains the enterprise. And, it should be sufficiently general to provide latitude in system design decisions and be responsive to technology changes.</p> </li>
<h3>EA and Business Architecture and BPM </h3>
+
<li>'''The planning time horizon'''—Large organizations often synchronize this scope with the three- to five-year major enterprise planning or budgeting cycle; however, other organizations believe that the planning timeframe needs to be either shorter or more flexible so that the organization can respond faster to unforeseen events and influences.</li>
<p>The discipline of EA has evolved in parallel to the discipline of [http://eitbokwiki.org/Glossary#bpm business process modeling (BPM)]. Clearly, the business architecture needs to be characterized and described in both EA and BPM “languages” and tools. Over the last decade, this relationship has been recognized and the companies who are developing and providing EA and BPM tools are helping to bridge the gap. Likewise, the respective expert communities recognize the need and are starting to address it.</p>
+
</ul>
<h3>EA and Scope</h3>
+
<h4>Develop the Business Architecture</h4>
<p>It is important to note that EA does not necessarily mean across an entire enterprise. EA can be narrowed to a particular “subject of concern” and a “scope” for that concern. Enterprise can be the scope (“enterprise-wide”) and, in a different way, it can be viewed as the subject. TOGAF goes into detail about the different ways of looking at EA. Overall, remember that the organization is the definer of scopes, whether it is an extended organization, specific organization, business unit, function, or department. EA is not necessarily enterprise-wide. And orthogonally, the scope can be narrow and needs to be defined in terms of domains to be considered, such as business, information, data, application, platforms, infrastructure (software and hardware), and technology (network and storage). It may depend on whether the EA team is EIT-centric or enterprise-centric. Also, there are sometimes several EA teams working simultaneously on small chunks that must be integrated.</p>
+
<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&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 [http://eitbokwiki.org/Enterprise_Architecture#archframework Architectural Framework, Methods, and Processes]).</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>'''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>
 +
<h4>Create the Information Systems Architectures</h4>
 +
<p>Once the business architecture effort is complete or nearly so, the EA team can start working with EIT on the information systems architecture. This effort usually involves a combination of data/information architecture and application architecture work. As with the business architectural effort, once the "as is" and "to be" states are defined, a gap analysis needs to be performed, which gives a detailed understanding of the scope of the implementation effort.</p>
 +
<p>Some EA specialists recommend a data-driven approach, while others recommend a functional or application-development approach. It appears that the effectiveness of the approach often depends upon the domain and the scope of the EA effort, and what is required to fill "the gap."</p>
 +
<p>This effort needs to not only define the architecture, but also needs to show how the new architecture will support the business architecture and the architecture vision. The connection needs to be clear to all the stakeholders. It also needs to show how the old elements of the infrastructure will connect to any new elements.</p>
 +
<p>The following artifacts are often created during this effort to describe the data architecture:</p>
 +
<ul>
 +
<li>Conceptual data diagram</li>
 +
<li>Logical data diagram</li>
 +
<li>Data dissemination diagram</li>
 +
<li>Data lifecycle diagram</li>
 +
<li>Data security diagram</li>
 +
<li>Data migration diagram</li>
 +
<li>Data entity/data component catalog</li>
 +
<li>Data entity/business function matrix</li>
 +
<li>Application/data matrix</li>
 +
</ul>
 +
<p>There are also typically many application architecture artifacts that are created during this effort. Among them are: </p>
 +
<ul>
 +
<li>Application portfolio catalog</li>
 +
<li>Interface catalog</li>
 +
<li>Application/organization matrix</li>
 +
<li>Role/application matrix</li>
 +
<li>Application/function matrix</li>
 +
<li>Application interaction matrix</li>
 +
<li>Application communication diagram</li>
 +
<li>Application and user location diagram</li>
 +
<li>Application use case diagram</li>
 +
<li>Enterprise manageability diagram</li>
 +
<li>Process/application realization diagram</li>
 +
<li>Software engineering diagram</li>
 +
<li>Application migration diagram</li>
 +
<li>Software distribution diagram</li>
 +
</ul>
 +
<h4>Define the Technology or Infrastructure Architecture</h4>
 +
<p>The next set of activities are to understand the current technology architecture and to develop the target (future) technology architectures that will enable the application and data components of the EIT architecture and, of course, the ''architecture vision''. This effort includes both creating the hardware infrastructure (computers, networks, and devices) and the software infrastructure architectures (operating systems, software platforms, underlying applications, or tools).</p>
 +
<p>This effort requires understanding newly available technologies that might enhance what can be delivered to stakeholders and that might increase application performance. And, as before, the gap analysis between the current and desired states is critical.</p>
 +
<p>Common artifacts from this effort are:</p>
 +
<ul>
 +
<li>Technology standards catalog</li>
 +
<li>Technology portfolio catalog</li>
 +
<li>Application and technology matrix</li>
 +
<li>Environments and locations diagram</li>
 +
<li>Platform decomposition diagram</li>
 +
<li>Processing diagram</li>
 +
<li>Networked computing and hardware diagram</li>
 +
<li>Communications engineering diagram</li>
 +
</ul>
 +
<h4>Create an Implementation and Migration Plan</h4>
 +
<p>The next effort typically concentrates on how to deliver the architectures to the enterprise. It looks at the gap analysis and the recommendations, and creates an optimized roadmap for the implementation that is based upon business requirements, stakeholder requirements, the ability of the organization to change, and available budget.</p>
 +
<p>The EA team identifies opportunities and solutions to take advantage of quickly. It also identifies implementation constraints that should be avoided or solved quickly. The team usually looks at "filling the gap" incrementally, trying to ensure that the enterprise sees the most value for its investment as quickly as possible.</p>
 +
<p>The main output of this work provides the basis of a well-considered plan called an ''implementation and migration plan''. Components that are created in this effort are:</p>
 +
<ul>
 +
<li>A ''work package'' definition identifies a logical collection of changes that are necessary (as a whole) to realize a part of the target architecture. A work package does not necessarily have to result in the full "to be" or desired state. In fact, development frameworks, such as Agile, suggest that these work packages should contain the smallest possible number of changes that will provide significant value to the organization, thus ensuring fast return on investment.</li>
 +
<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>
 +
</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 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>
 +
<h3>Governing and Monitoring an Enterprise Architecture</h3>
 +
<h4>Govern the Enterprise Architecture Program</h4>
 +
<p>Architecture governance is the practice of managing and controlling enterprise architectures and other architectures at an enterprise-wide level. It includes the following:</p>
 +
<ul>
 +
<li>Implementing a system of controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization</li>
 +
<li>Implementing a system to ensure compliance with internal and external standards and regulatory obligations</li>
 +
<li>Establishing processes that support effective management of the above processes within agreed parameters</li>
 +
<li>Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization</li>
 +
</ul>
 +
<p>It is important to distinguish EA governance from general EIT governance, which is covered in detail in [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance]. In this section, we discuss only those aspects of governance that are concerned with the EA.</p>
 +
<p>EIT governance has recently become a board responsibility, because it is so closely linked to the overall business governance. The governance of an organization's architectures is a key factor in effective EIT-business linkage, and therefore, it is becoming a key board-level responsibility.</p>
 +
<p>Part of the AE team's selected framework needs to support the effective elucidation, communication, and management of the enterprise architecture. Some of the EA artifacts that support the governance process are:</p>
 +
<ul>
 +
<li>''Architecture contracts'' are agreements between developers (whether in-house resources, systems integrators, applications providers, or service providers) and sponsors on the deliverables, quality, and fitness of an architecture. The contracts typically insure that there is a system of continuous monitoring to check integrity, changes, decision-making, and audit of all architecture-related activities within the organization. The purpose is to ensure adherence to the principles, standards, and requirements of the existing or developing architectures. These contracts also typically contain a set of processes and practices that ensure accountability, responsibility, and discipline with regard to the development and usage of all architectural artifacts.
 +
<li>Populated and current ''architecture repository'' that includes:
 +
<ul>
 +
<li>Current (updated) architecture vision</li>
 +
<li>Current architecture definition documents</li>
 +
<li>Documented architecture compliance recommendations and dispensations</li>
 +
<li>Service delivery requirements and recommendations</li>
 +
<li>Performance metrics recommendations</li>
 +
</ul>
 +
<li>''Service level agreements'' (SLAs)</li>
 +
</ul>
 +
<h4>Track and Manage Organizational Change</h4>
 +
<p>When the governance process is defined and the supporting agreements, documents, and processes are in place, tracking and managing the implementation of the EA to affect change in the organization needs to occur. Ideally, there will be an organization responsible for overseeing change initiatives (see [http://eitbokwiki.org/Change_Initiatives Change Initiatives]). The EA team should coordinate with that group. </p>
 +
<p>The tracking and management effort should:</p>
 +
<ul>
 +
<li>Perform frequent compliance assessments</li>
 +
<li>Ensure that the defined architecture lifecycle is maintained</li>
 +
<li>Ensure that the EA governance program is executed </li>
 +
<li>Ensure that the architecture's capability meets the enterprise's requirements</li>
 +
<li>Handle the EIT change request process (see [http://eitbokwiki.org/Change_Initiatives Change Initiatives])</li>
 +
</ul>
 +
<p>Keeping an EA program on track to meet the organization's needs requires constant measurement, review, and adjustment. It is the tracking and management of the EA program that keeps it on track and makes it effective. Ineffective and unmonitored EA programs often produce artifacts that are never used. In such cases, the cost of the EA program is never recouped by the by the enterprise.</p>
 +
<h2>Other Enterprise Architecture Aspects</h2>
 +
<h3>EA and Non-functional Requirements or Cross-layer Concerns</h3>
 +
<p>The [http://eitbokwiki.org/Requirements Requirements chapter] discusses the two types of requirements, '''[http://eitbokwiki.org/Glossary#functional_requirements functional]''' and '''[http://eitbokwiki.org/Glossary#non-functional_requirements non-functional]'''. While EA influences both types, its impact on functional requirements is more obvious. However, EA also influences non-functional requirements and can do so through the overriding EA principles as well as in what are called ''collaboration contracts'' between EA artifacts. Here are some examples.</p>
 +
<ul>
 +
<li>'''Business service collaboration contracts'''—A business service, or a set of business processes like a financial operation and its expectations in receiving information data elements from a sales service (e.g., an order entry from a sales operation).</li>
 +
<li>'''Technology infrastructure component collaboration contracts'''—Storage components and networking components. Collaboration contracts between the two might be the quality and reliability expectations in terms of up time, error-free processing, messaging, latency, and so on. </li>
 +
</ul>
 +
<p>In these contracts, expectations of various qualities are defined and documented in delivery projects as non-functional requirements. By keeping the close association between the collaboration contracts of all the artifacts in the EA repository with the non-functional requirements in the Enterprise IT portfolio of projects, the quality requirements and expectations across the enterprise can be balanced.</p>
 +
<h3>EA Versus Business Process Modeling (BPM) </h3>
 +
<p>The discipline of EA has evolved in parallel to the discipline of [http://eitbokwiki.org/Glossary#bpm business process modeling (BPM)]. Clearly, the business architecture needs to be characterized and described in both EA and BPM "languages" and tools. Over the last decade, this relationship has been recognized and the companies who are developing and providing EA and BPM tools are helping to bridge the gap. Likewise, the respective expert communities recognize the need and are starting to address it.</p>
 
<h2>Summary</h2>
 
<h2>Summary</h2>
 
<p>There are three almost universally adopted concepts that characterize the current state of the art of enterprise architecture: </p>
 
<p>There are three almost universally adopted concepts that characterize the current state of the art of enterprise architecture: </p>
 
<ul>
 
<ul>
<li>The four-layer stack model &mdash; or the four aspects &mdash; of an enterprise</li>
+
<li>The four-layer stack model—or the four aspects—of an enterprise. EA includes business, solution, information, and technology architectures. Business architecture has a direct relationship to and reciprocal impact on the remaining aspects of EA, particularly the solution and information architectures. For example, information architecture leverages the information aspects of business architecture to craft a wide range of technology options for maximizing accessibility and usage to a various information categories. These range from "big data" to more traditional relational database architectures. Information architecture establishes the critical underpinnings for business automation solutions. </li>
<li>The ''as is'' and ''to be'' states</li>
+
<li>Capturing the "as is" and "to be" states and performing a gap analysis between the two is a critical activity that informs the process at all levels.
<li>The use of frameworks</li>
+
</li>
 +
<li>The use of EA frameworks is strongly advised even though there is no clear agreement as to what "the right" framework is. Frameworks need to be useful, practical, and modular in nature; at the same time, they must be able to show an integrated and interdependent view of all the elements of the architecture.
 +
</li>
 
</ul>
 
</ul>
<p>Enterprise architecture should clearly influence and be influenced by strategy and governance. Additionally, there is a strong connection to requirements. Likewise, an interdependency exists between the enterprise architecture and the solution architecture (SA) for a particular application (solution architecture is included in the [http://eitbokwiki.org/Construction Construction chapter]).</p>
+
<p>EA is both an input to the enterprise's strategy and a follow-on activity that interprets results, performs gap analysis, and supports execution of the strategic plan. It also adjusts the "to be" architectures when the plan or strategy needs to change direction. </p>
<p>Enterprise architecture can be defined by its scope and subject; it can be about an entire organization or can be narrowed down to a segment, unit, or function. So EA is scalable and can be small and incremental as well as enterprise-wide.</p>
+
<p>A brilliant business design can be too costly and take too long to satisfy executive demands, or it can be technologically infeasible. This is where enterprise architecture can help ensure that selected business designs and innovation options are not only desirable, but also cost-effective and implementable.
<p>EA can assist in both short- and long-term enterprise improvement and transformation planning.</p>
+
</p>
<p>Successful EA functions must be able to balance high-level strategic work with tactical governance and collaboration with solution architectures in the enterprise’s IT portfolio so that the portfolio provides ongoing and clear impact and value.</p>
+
<p>Enterprise architecture can be defined by its scope and subject; it can be about an entire organization or can be narrowed down to a segment, unit, or function. So, EA is scalable and can be small and incremental as well as enterprise-wide. It can assist in both short- and long-term enterprise improvement and transformation planning.</p>
<p>A useful, practical, and functioning EA framework should have independent and modular elements, and, at the same time, be able to show an integrated and interdependent view of all of the elements.</p>
+
<p>Successful EA functions must be able to balance high-level strategic work with tactical governance and collaboration with solution architectures in the enterprise's IT portfolio, so that the portfolio provides ongoing and clear impact and value.</p>
<h2> Key Skills</h2>
+
<h2> Key Maturity Frameworks</h2>
<p>While many large companies have defined their own sets of skills for purposes of talent management (to recruit, retain, and further develop the highest quality staff members that they can find, afford and hire), the advancement of EIT professionalism will require common definitions of EIT skills that can be used not just across enterprises, but also across countries. We have selected 3 major sources of skill definitions. While none of them is used universally, they provide a good cross-section of options. </p>
+
<p>Capability maturity for EIT refers to its ability to reliably perform. Maturity is a measured by an organization's readiness and capability expressed through its people, processes, data, and technologies and the consistent measurement practices that are in place. See [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessments Appendix F] for additional information about maturity frameworks.</p>
 +
<p>Many specialized frameworks have been developed since the original Capability Maturity Model (CMM) that was developed by the Software Engineering Institute in the late 1980s. This section describes how some of those apply to the activities described in this chapter. </p>
 +
<h3> IT-Capability Maturity Framework (IT-CMF) </h3>
 +
<p>The IT-CMF was developed by the Innovation Value Institute in Ireland. This framework helps organizations to measure, develop, and monitor their EIT capability maturity progression. It consists of 35 EIT management capabilities that are organized into four macro capabilities: </p>
 +
<ul>
 +
<li>Managing EIT like a business</li>
 +
<li>Managing the EIT budget</li>
 +
<li>Managing the EIT capability</li>
 +
<li>Managing EIT for business value</li>
 +
</ul>
 +
<p>Each has five different levels of maturity starting from ''initial' to ''optimizing''. The most relevant critical capability is enterprise architecture management (EAM). </p>
 +
<h4>Enterprise Architecture Management Maturity</h4>
 +
<p>The following statements provide a high-level overview of the enterprise architecture management (EAM) capability at successive levels of maturity.</p>
 +
<table>
 +
<tr valign="top"><td width="10%">Level 1</td><td>EA is conducted within the context of individual projects, by applying one-off principles and methods within those projects. </td></tr>
 +
<tr valign="top"><td>Level 2</td><td>A limited number of basic architecture artifacts and practices are emerging in certain EIT domains or key projects. </td></tr>
 +
<tr valign="top"><td>Level 3</td><td>A common suite of EA principles and methods are shared across the EIT function, allowing a unifying vision of EA to emerge. </td></tr>
 +
<tr valign="top"><td>Level 4</td><td>Planning by the EIT function and the rest of the business consistently leverages enterprise-wide architecture principles and methods to enable efficiency and agility across the organization. </td></tr>
 +
<tr valign="top"><td>Level 5</td><td>EA principles and methods are continually reviewed to maintain their ability to deliver business value. </td></tr>
 +
</table>
 +
<h2> Key Competence Frameworks</h2>
 +
<p>While many large companies have defined their own sets of skills for purposes of talent management (to recruit, retain, and further develop the highest quality staff members that they can find, afford and hire), the advancement of EIT professionalism will require common definitions of EIT skills that can be used not just across enterprises, but also across countries. We have selected three major sources of skill definitions. While none of them is used universally, they provide a good cross-section of options. </p>
 +
<p>Creating mappings between these frameworks and our chapters is challenging, because they come from different perspectives and have different goals. There is rarely a 100% correspondence between the frameworks and our chapters, and, despite careful consideration some subjectivity was used to create the mappings. Please take that in consideration as you review them.</p>
 +
<p>The framework skills mapping exercise for EA was one of significant controversy. Suggested mapping depended on a particular individual's personal definition of EA. Some individuals have a very narrow definition for EA, while other definitions are wide and greatly more encompassing. The EITBOK has adopted a rather wide scope for EA, and the framework mappings below reflect this wide scope.</p>
 
<h3>Skills Framework for the Information Age</h3>
 
<h3>Skills Framework for the Information Age</h3>
<p> The Skills Framework for the Information Age (SFIA) has defined nearly 100 skills. SFIA describes 7 levels of competency which can be applied to each skill. Not all skills, however, cover all seven levels. Some reach only partially up the seven step ladder. Others are based on mastering foundational skills, and start at the fourth or fifth level of competency. It is used in nearly 200 countries, from Britain to South Africa, South America, to the Pacific Rim, to the United States. (http://www.sfia-online.org)</p>
+
<p>The Skills Framework for the Information Age (SFIA) has defined nearly 100 skills. SFIA describes 7 levels of competency which can be applied to each skill. Not all skills, however, cover all 7 levels. Some reach only partially up the 7 step ladder. Others are based on mastering foundational skills, and start at the fourth or fifth level of competency. It is used in nearly 200 countries, from Britain to South Africa, South America, to the Pacific Rim, to the United States. (http://www.sfia-online.org)</p>
<p>SFIA skills have not yet been defined for the security chapter.</p>
+
<table cellpadding="5" border="1">
 +
<tr>
 +
<th style="background-color: #58ACFA;"><font color="white">Skill</font></th>
 +
<th style="background-color: #58ACFA;"><font color="white">Skill Description</font></th>
 +
<th width="10%" style="background-color: #58ACFA;"><font color="white">Competency Levels</font></th></tr>
 +
<tr><td valign="top">EIT governance</td><td>The establishment and oversight of an organization's approach to the use of information, digital services and associated technology. Includes responsibility for provision of digital services; levels of service, and service quality that meet current and future business requirements; policies and practices for conformance with mandatory legislation and regulations; strategic plans for technology to enable the organization's business strategy; transparent decision making, leading to justification for investment, with appropriate balance between stakeholder benefits, opportunities, costs, and risks.</td><td valign="top">5-7</td></tr>
 +
<tr><td valign="top">Information systems coordination</td><td>Typically within a large organization in which the information strategy function is devolved to autonomous units, or within a collaborative enterprise of otherwise independent organizations, the coordination of information strategy matters where the adoption of a common approach (such as shared services) would benefit the organization.</td><td valign="top">6-7</td></tr>
 +
<tr><td valign="top">Information security</td><td>The selection, design, justification, implementation, and operation of controls and management strategies to maintain the security, confidentiality, integrity, availability, accountability, and relevant compliance of information systems with legislation, regulation, and relevant standards.</td><td valign="top">5-7</td></tr>
 +
<tr><td valign="top">Technical specialism</td><td>The development and exploitation of expertise in any specific area of information or communications technology, technique, method, product, or application area.</td><td valign="top">5-6</td></tr>
 +
<tr><td valign="top">Innovation</td><td>The capability to recognize and exploit business opportunities provided by information and communication technology, accepted practices, methods and standards, to ensure more efficient and effective performance of organizations, to explore possibilities for new ways of conducting business and organizational processes, and to establish new services or businesses.</td><td valign="top">5-6</td></tr>
 +
<tr><td valign="top">Enterprise and business architecture</td><td>The creation, iteration, and maintenance of structures such as enterprise and business architectures embodying the key principles, methods, and models that describe the organization's future state, and that enable its evolution. This typically involves the interpretation of business goals and drivers; the translation of business strategy and objectives into an "operating model"; the strategic assessment of current capabilities; the identification of required changes in capabilities; and the description of inter-relationships between people, organization, service, process, data, information, technology, and the external environment.
 +
<p>The architecture development process supports the formation of the constraints, standards, and guiding principles necessary to define, ensure, and govern the required evolution; this facilitates change in the organization's structure, business processes, systems, and infrastructure in order to achieve predictable transition to the intended state.</p></td><td valign="top">5-7</td></tr>
 +
<tr><td valign="top">Emerging technology monitoring</td><td>The identification of new and emerging hardware, software and communication technologies and products, services, methods, and techniques and the assessment of their relevance and potential value as business enablers, improvements in cost/performance, or sustainability. The promotion of emerging technology awareness among staff and business management.</td><td valign="top">5-6</td></tr>
 +
<tr><td valign="top">Network planning</td><td>The creation and maintenance of overall network plans, encompassing the communication of data, voice, text, and image, in the support of an organization's business strategy. This includes participation in the creation of service level agreements and the planning of all aspects of infrastructure necessary to ensure provision of network services to meet such agreements. Physical implementation may include copper wire, fiber optic, wireless, or any other technology.</td><td valign="top">5-6</td></tr>
 +
<tr><td valign="top">Data management</td><td>The management of practices and processes to ensure the security, integrity, safety, and availability of all forms of data and data structures that make up the organization's information. The management of data and information in all its forms and the analysis of information structure (including logical analysis of taxonomies, data, and metadata). The development of innovative ways of managing the information assets of the organization.</td><td valign="top">5-6</td></tr>
 +
<tr><td valign="top">Methods and tools</td><td>Ensuring that appropriate methods and tools for the planning, development, testing, operation, management, and maintenance of systems are adopted and used effectively throughout the organization.</td><td valign="top">5-6</td></tr>
 +
<tr><td valign="top">Requirements definition and management</td><td>The definition and management of the business goals and scope of change initiatives. The specification of business requirements to a level that enables effective delivery of agreed changes.</td><td valign="top">5-6</td></tr>
 +
<tr><td valign="top">Network design</td><td>The production of network designs and design policies, strategies, architectures, and documentation, covering voice, data, text, email, facsimile, and image, to support strategy and business requirements for connectivity, capacity, interfacing, security, resilience, recovery, access, and remote access. This may incorporate all aspects of the communications infrastructure, internal and external, mobile, public and private, Internet, intranet, and call centers.</td><td valign="top">5-6</td></tr>
 +
<tr><td valign="top">Database design</td><td>The specification, design, and maintenance of mechanisms for storage and access to both structured and unstructured information, in support of business information needs.</td><td valign="top">5-6</td></tr>
 +
<tr><td valign="top">Information management</td><td>The overall governance of how all types of information, structured and unstructured, whether produced internally or externally, are used to support decision-making, business processes, and digital services. Encompasses development and promotion of the strategy and policies covering the design of information structures and taxonomies, the setting of policies for the sourcing and maintenance of the data content, and the development of policies, procedures, working practices, and training to promote compliance with legislation regulating all aspects of holding, use, and disclosure of data.</td><td valign="top">5-7</td></tr>
 +
<tr><td valign="top">EIT strategy and planning</td><td>The creation, iteration, and maintenance of a strategy in order to align EIT plans with business objectives and the development of plans to drive forward and execute that strategy. Working with stakeholders to communicate and embed strategic management via objectives, accountabilities, and monitoring of progress.</td><td valign="top">5-7</td></tr>
 +
<tr><td valign="top">Technical specialism</td><td>The development and exploitation of expertise in any specific area of information or communications technology, technique, method, product, or application area.</td><td valign="top">5-6</td></tr>
 +
<tr><td valign="top">Business modeling</td><td>The production of abstract or distilled representations of real world, business or gaming situations in traditional or trans-media applications, to aid the communication and understanding of existing, conceptual, or proposed scenarios. Predominantly focused around the representation of processes, roles, data, organization, and time. Models may be used to represent a subject at varying levels of detail and decomposition.</td><td valign="top">5-6</td></tr>
 +
<tr><td valign="top">User experience analysis</td><td>The identification, analysis, clarification and communication of the context of use in which applications will operate, and of the goals of products, systems, or services. Analysis and prioritization of stakeholders' "user experience" needs and definition of required system behavior and performance. Resolution of potential conflicts between user requirements and determination of usability objectives.</td><td valign="top">5</td></tr>
 +
<tr><td valign="top">User experience design</td><td>The iterative development of user tasks, interaction and interfaces to meet user requirements, considering the whole user experience. Refinement of design solutions in response to user-centered evaluation and feedback and communication of the design to those responsible for implementation.</td><td valign="top">5-6</td></tr>
 +
<tr><td valign="top">Analytics</td><td>The validation and analysis of significant volumes of data, including the ability to discover and quantify patterns and trends in numbers, symbols, text, sound, and image. Relevant techniques may include statistical and data mining algorithms and machine learning methods such as rule induction, artificial neural networks, genetic algorithms, and automated indexing systems.</td><td valign="top">6-7</td></tr>
 +
</table>
 
<h3>European Competency Framework</h3>
 
<h3>European Competency Framework</h3>
<p> The European Union's European Competency Framework (e-CF) has 40 “competencies” and is used in the EU. (http://www.ecompetences.eu/) It uses five levels of competency. As in SFIA, not all skills are subject to all 5 levels. The EU has also created a mapping between e-CF and SFIA.</p>
+
<p>The European Union's European e-Competence Framework (e-CF) has 40 competences and is used by a large number of companies, qualification providers, and others in public and private sectors across the EU. It uses five levels of competence proficiency (e-1 to e-5). No competence is subject to all five levels.</p>
<p>E-CF skills have not yet been defined for the security chapter.</p>
+
<p>The e-CF is published and legally owned by CEN, the European Committee for Standardization, and its National Member Bodies (http://www.cen.eu). Its creation and maintenance has been co-financed and politically supported by the European Commission, in particular, DG (Directorate General) Enterprise and Industry, with contributions from the EU ICT multi-stakeholder community, to support competitiveness, innovation, and job creation in European industry. The Commission works on a number of initiatives to boost ICT skills in the workforce. Version 1.0 to 3.0 were published as CEN Workshop Agreements (CWA). The e-CF 3.0 CWA 16234-1 was published as an official European Norm (EN), EN 16234-1. For complete information, see http://www.ecompetences.eu. </p>
<h3>i-Competency Dictionary </h3>
+
<table cellpadding="5" border="1">
<p>The Information Technology Promotion Agency in Japan has developed the i-CD, translated it into English, and describes it at https://www.ipa.go.jp/english/humandev/icd.html. .  It is an extensive skills and tasks database, used in Japan and southeast Asian countries. Like SFIA, it establishes seven levels of competencies for skills. An example showcasing the skills and tasks relevant to this chapter is given below. </p>
+
<tr><th width="85%" style="background-color: #58ACFA;"><font color="white">e-CF Dimension 2</font></th><th width="15%" style="background-color: #58ACFA;"><font color="white">e-CF Dimension 3</font></th></tr>
 
+
<tr><td valign="top"><strong>A.1. IS and business Strategy Alignment (PLAN)</strong><br />Anticipates long-term business requirements, and influences the improvement of organizational process efficiency and effectiveness. Determines the IS model and the EA in line with the organization's policy and ensures a secure environment. Makes strategic IS policy decisions for the enterprise, including sourcing strategies.</td><td valign="top">Level 4-5</td></tr>
<h2>Roles</h2>
+
<tr><td valign="top"><strong>A.3. Business Plan Development (PLAN)</strong><br />Addresses the design and structure of a business or product plan including the identification of alternative approaches as well as return on investment propositions. Considers the possible and applicable sourcing models. Presents cost benefit analysis and reasoned arguments in support of the selected strategy. Ensures compliance with business and technology strategies. Communicates and sells business plan to relevant stakeholders and addresses political, financial, and organizational interests.</td><td valign="top">Level 3-5</td></tr>
<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 associating those with skills in the IPA database.</p>
+
<tr><td valign="top"><strong>A.4. Product/Service Planning (PLAN)</strong><br />Analyzes and defines current and target status. Estimates cost effectiveness, points of risk, opportunities, strengths, and weaknesses, with a critical approach. Creates structured plans; establishes time scales and milestones, ensuring optimization of activities and resources. Manages change requests. Defines delivery quantity and provides an overview of additional documentation requirements. Specifies correct handling of products, including legal issues, in accordance with current regulations.</td><td valign="top">Level 2-4</td></tr>
<p>Because there is no common definition of roles per se, however, we have selected ITIL’s roles as our reference model. The relevant ITIL roles for the activities in this chapter are given below.</p>
+
<tr><td valign="top"><strong>A.5. Architectural Design (PLAN)</strong><br />Specifies, refines, updates, and makes available a formal approach to implement solutions necessary to develop and operate the IS architecture. Identifies change requirements and the components involved: hardware, software, applications, processes, information, and technology platform. Takes into account interoperability, scalability, usability, and security. Maintains alignment between business evolution and technology developments.</td><td valign="top">Level 3-5</td></tr>
<p> *** To Be Added</p>
+
<tr><td valign="top"><strong>A.7. Technology Trend Monitoring (PLAN)</strong><br />Investigates latest ICT technological developments to establish understanding of evolving technologies. Devises innovative solutions for integration of new technology into existing products, applications, or services or for the creation of new solutions.</td><td valign="top">Level 4-5</td></tr>
 +
<tr><td valign="top"><strong>D.10. Information and Knowledge Management (ENABLE)</strong><br />Identifies and manages structured and unstructured information and considers information distribution policies. Creates information structure to enable exploitation and optimization of information. Understands appropriate tools to be deployed to create, extract, maintain, renew, and propagate business knowledge in order to capitalize from the information asset. </td><td valign="top">Level 3-5</td></tr>
 +
<tr><td valign="top"><strong>D.11. Needs Identification (ENABLE)</strong><br />Actively listens to internal/external customers, articulates and clarifies their needs. Manages the relationship with all stakeholders to ensure that the solution is in line with business requirements. Proposes different solutions (e.g., make-or-buy) by performing contextual analysis in support of user centered system design. Advises the customer on appropriate solution choices. Acts as an advocate engaging in the implementation or configuration process of the chosen solution. </td><td valign="top">Level 3-5</td></tr>
 +
</table>
 +
<h3>i&nbsp;Competency Dictionary</h3>
 +
<p>The Information Technology Promotion Agency (IPA) of Japan has developed the i&nbsp;Competency Dictionary (iCD) and translated it into English, and describes it at https://www.ipa.go.jp/english/humandev/icd.html. The iCD is an extensive skills and tasks database, used in Japan and southeast Asian countries. It establishes a taxonomy of tasks and the skills required to perform the tasks. The IPA is also responsible for the Information Technology Engineers Examination (ITEE), which has grown into one of the largest scale national examinations in Japan, with approximately 600,000 applicants each year.</p>
 +
<p>The iCD consists of a Task Dictionary and a Skill Dictionary. Skills for a specific task are identified via a "Task x Skill" table. (See [http://eitbokwiki.org/Glossary Appendix A] for the task layer and skill layer structures.) EITBOK activities in each chapter require several tasks in the Task Dictionary. The complete iCD Task Dictionary (Layer 1-4) and Skill Dictionary (Layer 1-4) can be obtained by returning the request form provided at http://www.ipa.go.jp/english/humandev/icd.html.</p>
 +
<table cellpadding="5" border="1">
 +
<tr><th width="15%" style="background-color: #58ACFA;" font-size="14pt"><font color="white">Task Dictionary</font></th><th colspan="3" style="background-color: #58ACFA;" font-size="14pt"><font color="white">Skill Dictionary</font></th></tr>
 +
<tr><th width="30%" style="background-color: #58ACFA;"><font color="white">Task Layer 1 (Task Layer 2)</font></th><th width="15%" style="background-color: #58ACFA;"><font color="white">Skill Classification</font></th><th width="15%" style="background-color: #58ACFA;"><font color="white">Skill Item</font></th><th width="40%" style="background-color: #58ACFA;"><font color="white">Associated Knowledge Items</font></th></tr>
 +
<tr><td valign="top"><em><strong>Formulation of EIT adoption plan<br />(EIT strategy formulation and execution promotion)</strong></em></td>
 +
<td valign="top">System strategy planning methods</td>
 +
<td valign="top">Information system strategy</td>
 +
<td><ul>
 +
<li>Application service provider (ASP)</li>
 +
<li>Business process outsourcing (BPO)</li>
 +
<li>EIT portfolio model</li>
 +
<li>EIT industry trends (cases)</li>
 +
<li>EIT management capability index</li>
 +
<li>EIT investment management</li>
 +
<li>Enterprise architecture (EA)</li>
 +
<li>Knowledge related to cross license agreement</li>
 +
<li>Control framework</li>
 +
<li>System owner</li>
 +
<li>System lifecycle</li>
 +
<li>System structure</li>
 +
<li>System architecture knowledge (functional decomposition of hardware/software/manual work, hardware architecture, software architecture, application architecture, IS plan)</li>
 +
<li>Knowledge related to software agreement</li>
 +
<li>Data owner</li>
 +
<li>Balance score card</li>
 +
<li>Business process management (BPM)</li>
 +
<li>Business process re-engineering (BPR)</li>
 +
<li>Business process notation methods</li>
 +
<li>Business model</li>
 +
<li>Business environment analysis methods</li>
 +
<li>Process framework</li>
 +
<li>Benchmarking</li>
 +
<li>Knowledge related to license agreement</li>
 +
<li>Risk analysis techniques</li>
 +
<li>Act against delay in payment of subcontract proceeds, etc. to subcontractors</li>
 +
<li>Development return on development investment</li>
 +
<li>Business operations model</li>
 +
<li>Design of business operations</li>
 +
<li>Business analysis methods</li>
 +
<li>Information systems model</li>
 +
<li>Significance and purpose of information system strategy</li>
 +
<li>Information systems strategy implementation management</li>
 +
<li>Information systems strategy evaluation</li>
 +
<li>Computerization promotion system</li>
 +
<li>Computerization investment planning</li>
 +
<li>Product knowledge and trends (cases)</li>
 +
<li>Total optimization planning</li>
 +
<li>Quality control (quality control framework)</li>
 +
</ul>
 +
</td>
 +
</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>
 +
<p>The following roles are common to ITSM:</p>
 +
<ul>
 +
<li>Business Relationship Manager </li>
 +
<li>Enterprise Architect</li>
 +
<li>Service Catalog Manager </li>
 +
<li>Service Portfolio Manager</li>
 +
</ul>
 +
<p>Other key roles include:</p>
 +
<ul>
 +
<li>Business Architect </li>
 +
<li>Business Analyst</li>
 +
<li>Data Architect </li>
 +
<li>EIT Management Team</li>
 +
<li>Solution Architect</li>
 +
<li>Technology Architect</li>
 +
</ul>
 
<h2>Standards</h2>
 
<h2>Standards</h2>
<p>ISO/IEC/IEEE 42010</p>
+
<p>ISO 15704:2000, Industrial automation systems—Requirements for enterprise-reference architectures and methodologies</p>
<p>TOGAF 9.1</p>
+
<p>ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture description </p>
 +
<p>TOGAF® Version 9.1, available at http://www.opengroup.org/togaf/downloads</p>
 
<h2>References</h2>
 
<h2>References</h2>
<div id="One"></div><p>[1] L. Fehskens, “Why We Can’t Agree on What “Enterprise Architecture” Means, and Why That’s OK, At Least for Now,Enterprise Architecture Conference Europe, London June 2013. </p>
+
<div id="One"></div><p>[1] L. Fehskens, "Why We Can't Agree on What "Enterprise Architecture" Means, and Why That's OK, At Least for Now," Enterprise Architecture Conference Europe, London June 2013.</p>
<div id="Two"></div><p>[2] ISO/IEC/IEEE, “ISO/IEC/IEEE 42010:2011, Systems and software engineering &mdash; Architecture description,http://www.iso.org/iso/catalogue_detail.htm?csnumber=50508 </p>
+
<div id="Two"></div><p>[2] ISO/IEC/IEEE, "ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture description," http://www.iso.org/iso/catalogue_detail.htm?csnumber=50508</p>
<div id="Three"></div><p>[3] Federation of EA Professional Organizations (FEAPO), “Common Perspectives on Enterprise Architecture,Architecture and Governance Magazine, Issue 9-4, November 2013, pp.11-17. </p>
+
<div id="Three"></div><p>[3] Federation of EA Professional Organizations (FEAPO), "Common Perspectives on Enterprise Architecture," Architecture and Governance Magazine, Issue 9-4, November 2013, pp.11-17.</p>
<div id="Four"></div><p>[4] M. Porter, “The Five Competitive Forces that Shape Strategy,Harvard Business Review, January 2008, pp. 79-83.</p>
+
<div id="Four"></div><p>[4] M. Porter, "The Five Competitive Forces that Shape Strategy," Harvard Business Review, January 2008, pp. 79-83.</p>
<div id="Five"></div><p>[5] J. Lapalme, “Three Schools of Thought on Enterprise Architecture,IT Professional, vol.14, no. 6, pp. 37-43, Nov.-Dec. 2012, doi:10.1109/MITP.2011.109.</p>
+
<div id="Five"></div><p>[5] J. Lapalme, "Three Schools of Thought on Enterprise Architecture," IT Professional, vol.14, no. 6, pp. 37-43, Nov.-Dec. 2012, doi:10.1109/MITP.2011.109.</p>
<div id="Six"></div><p>[6] N. Malik, “Three Schools of Thought for Enterprise Architecture,blog, 28 May 2012; http://blogs.msdn.com/b/nickmalik/archive/2012/05/28/three-schools-of-thought-for-enterprise-architecture.aspx </p>
+
<div id="Six"></div><p>[6] N. Malik, "Three Schools of Thought for Enterprise Architecture," blog, 28 May 2012; http://blogs.msdn.com/b/nickmalik/archive/2012/05/28/three-schools-of-thought-for-enterprise-architecture.aspx</p>
<div id="Seven"></div><p>[7] J. Zachman, “A Framework for Information Systems Architecture,IBM Systems Journal, vol 26, no 3, 1987, IBM Publication G321-5298.</p>
+
<div id="Seven"></div><p>[7] J. Zachman, "A Framework for Information Systems Architecture," IBM Systems Journal, vol 26, no 3, 1987, IBM Publication G321-5298.</p>
<div id="Eight"></div><p>[8] The Open Group (January 23, 2015),“A Historical Look at Enterprise Architecture with John Zachman” http://blog.opengroup.org/2015/01/23/a-historical-look-at-enterprise-architecture-with-john-zachman/</p>
+
<div id="Eight"></div><p>[8] The Open Group (January 23, 2015),"A Historical Look at Enterprise Architecture with John Zachman" http://blog.opengroup.org/2015/01/23/a-historical-look-at-enterprise-architecture-with-john-zachman/</p>
<div id="Nine"></div><p>[9] The Open Group (2011),“TOGAF 9.1, Part 11: Architecture Development Method (ADM) &mdash; Preliminary Phase” http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html </p>
+
<div id="Nine"></div><p>[9] The Open Group (2011),"TOGAF 9.1, Part 11: Architecture Development Method (ADM)—Preliminary Phase" http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html</p>
<div id="Ten"></div><p>[10] Enterprise Architecture Framework, Wikipedia, http://en.wikipedia.org/wiki/Enterprise_architecture_framework </p>
+
<div id="Ten"></div><p>[10] Enterprise Architecture Framework, Wikipedia, http://en.wikipedia.org/wiki/Enterprise_architecture_framework</p>
<div id="Eleven"></div><p>[11] This image is copyright John A. Zachman and Zachman International&reg;, Inc. Published with the permission of John A. Zachman and Zachman International&reg;, Inc., www.zachman.com </p>
+
<div id="Eleven"></div><p>[11] This image is copyright John A. Zachman and Zachman International&reg;, Inc. Published with the permission of John A. Zachman and Zachman International&reg;, Inc., www.zachman.com</p>
<div id="Twelve"></div><p>[12] J. van’t Wout et al, “The Integrated Architecture Framework Explained,Springer-Verlag, 2010.</p>
+
<div id="Twelve"></div><p>[12] J. van't Wout et al, "The Integrated Architecture Framework Explained," Springer-Verlag, 2010.</p>
 
<div id="Thirteen"></div><p>[13] Dekker, Morsink & Partners, http://www.dekkermorsink.nl/raamwerken.htm </p>
 
<div id="Thirteen"></div><p>[13] Dekker, Morsink & Partners, http://www.dekkermorsink.nl/raamwerken.htm </p>
 
<div id="Fourteen"></div><p>[14] The Open Group, TOGAF9.1 ADM Steps Reference Card</p>
 
<div id="Fourteen"></div><p>[14] The Open Group, TOGAF9.1 ADM Steps Reference Card</p>
<div id="Fifteen"></div><p>[15] C. Fine, “Clockspeed,” Perseus Books, 1998.</p>
 
 
<h2>Additional Reading</h2>
 
<h2>Additional Reading</h2>
<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>

Latest revision as of 00:43, 4 July 2019

Welcome to the initial version of the EITBOK wiki. Like all wikis, it is a work in progress and may contain errors. We welcome feedback, edits, and real-world examples. Click here for instructions about how to send us feedback.
Ieee logo 1.png
Acm logo 3.png

 

1 Introduction

Enterprise architecture (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies.

Like many other disciplines, EA is evolving. [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.

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.

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.

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.

2 Goals and Principles

The goals of the EA effort in an organization should be:

  • Help the enterprise understand its current operations.
    A major function of EA is revealing and documenting the relationships between business elements, information elements, and the underlying information technology and technology infrastructure. By demonstrating these interrelationships from a systems level down to the most detailed element or artifact level, EA provides the information needed to connect an organization's conceptual business strategy to the execution of that strategy.
  • Guide the organization to the desired future ("to be") state.
    Carefully understand the enterprise's long-term goals and future desired state. Provide holistic information and insights to help executives and EIT make better decisions and to identify opportunities to implement solutions that enable the organization to reach the future desired state.
  • Align EIT with the enterprise's business.
    In the best of all worlds, EA can create a bridge between the needs of the organization and the support provided by EIT. EIT/business alignment has become an increasingly widespread goal for EA, and has become the dominant value proposition for EA. Alignment activities, such as the mapping of business roles and processes to information data flows and the underlying EIT systems and technology that support them, creates this alignment.
  • Help manage the complexity of the business, of EIT, and the relationship between the two.
    The elimination of unnecessary complexity was the earliest justification for EA. Eliminating complexity makes EIT solutions easier to understand, easier to control, and, therefore, less expensive to develop, operate, and maintain. An EA-based framework and roadmap provide a means to eliminate redundancy as well as the integration of systems and data.
  • Facilitate organizational change, transformation, and agility.
    In a business and technology environment of continuous and rapid change, organizations that can anticipate and respond appropriately and quickly are more likely to survive. Robust EA processes, such as providing artifacts (requirements, specifications, guiding principles, and conceptual models) that describe the desired future state of enterprise and the path to get there can enable rapid change.

The principles of EA include:

  • Architectural decisions seek to simplify operations.
  • Decisions are based on a long-term strategy, even at the expense of short-term profitability.
  • Think globally, act locally. Architectural decisions for solutions consider the impact on the entire enterprise.
  • Business goals are specific, measurable, attainable, relevant, and timely.
  • The definition of the desired future state and the path to get there are re-evaluated often.
  • Processes and changes promote collaboration between the business and EIT.
  • The effectiveness of the architecture and the adherence to the architecture must be demonstrable and measurable.
  • Models are only useful when they are accurate and kept current.

3 Context Diagram

01 Enterprise Architecture v2016-05-2.png
Figure 1. Context Diagram for Enterprise Architecture

4 What is Enterprise Architecture?

The first definition listed in a dictionary for enterprise is generally some variation on the concept of an ambitious endeavor or undertaking. Subsequent definitions define it as the entity (typically an organization) that carries out such an undertaking. This latter definition is the common understanding of the meaning of enterprise within the EA community. More specifically, the term enterprise was adopted to label not just commercial undertakings, but also such organizations as governments and nonprofits within its compass.

The formal definition of architecture cited most frequently by the EA community is the definition from ISO/IEC/IEEE 42010:2011:

"... "architecture" means whatever the EA framework being used (explicitly or implicitly) implies it is by the various architectural representations it recommends for use. " [2]

The Federation for Enterprise Architecture Professional Organizations (FEAPO) defines enterprise architecture as follows:

"Enterprise architecture is a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes." [3]

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 Figure 2).

Urban Planner.jpg

Figure 2. Urban Planner and Enterprise Architect vs. Building Architect and Solution Architect [3]

4.1 Evolution of Enterprise Architecture

The need for EA arose for two reasons. The first reason was driven by technology. The arrival of distributed computing in the 1980s resulted in increased EIT complexity due to additional scale, diversity, and connectivity in the computing environment. This additional complexity lead to significantly higher EIT development, support, and operational costs. With rising costs came pressure from management to slow the growth of EIT budgets and increase the business effectiveness of EIT support. Directives to "do more with less" and unrelenting pressure to increase efficiency and effectiveness required new approaches to EIT strategy. To some extent, consolidation, standardization, and commoditization worked as EIT expense reduction strategies; however, there were limits to their effectiveness, because they still lacked a holistic and systematic understanding of the connectedness between business roles and processes, information data elements and flows, supporting application systems, and underlying technology infrastructure.

The second motivation for EA was business-driven, due to the ever-increasing pace of external change combined with the difficulty for many organizations to successfully execute their business strategies. Michael Porter estimates that more than 80 percent of organizations fail to execute their business strategies, and ineffective execution was the reason for failure for more than 70 percent of them. [4] The principles and practices in EA help enterprise managers move their organizations from where they are to where they want them to be.

Based on whether one views EA solely for technology-based or business strategy-based reasons, the scope of EA varies, including its concerns, assumptions, and limitations. One of the most cogent analyses of the range of EA definitions was presented by James Lapalme, who describes three schools of thoughts on EA: [5]

  • Enterprise-wide IT platform—Effective enterprise strategy execution and operation through EIT-business alignment)
  • Enterprise—Effective enterprise strategy implementation through execution coherency
  • Enterprise-in-environment—Innovation and adaptation through organizational learning

Nick Malik builds on Lapalme's three schools, and describes three categories of EA application: [6]

  1. Enterprise IT architecting—Designing EIT services and creating EIT systems that address the enterprise's needs
  2. Enterprise integrating—Aligning the business with all of its capabilities, including EIT; using capability analysis to understand the impacts of strategy on the business processes and systems, and helping to frame the initiatives that should be created, and insures that investments are made in the right place
  3. Enterprise ecological adaptation—Analyzing the movements of the market, and working closely with business leaders to develop strategies based on the capabilities and positioning of the company that are likely to generate new revenue, improve market position, improve customer loyalty, and reduce costs

The differences between these categories is depicted graphically in Figure 3.

EA schools.png

Figure 3. EA Schools of Thought [6]

EA can serve a number of different goals (the vertical axis of Figure 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.

EA practitioners have three base-level assumptions:

  • The alignment of the business and EIT is achieved by aligning EIT with the business.
  • The agility of the enterprise is a consequence of the agility of the EIT function.
  • The transformative value of EA is typically delivered by transforming the application and technology architectures. The amount of change engendered by an EA initiative might be small at the business layer, but it typically increases as the design progresses closer to the details of the applications and systems.

4.2 Layers or Aspects of Enterprise Architecture

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.

In the early 1990s, this four-layer division, called the BIAT model [1]) 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 4).

BIAT-Models.jpg

Figure 4. Conventional BIAT Diagram and the 5-Layer BIAT Diagram

The meanings of the layers are described below.

4.2.1 Business Layer

Within the EITBOK, the term business is used synonymous with enterprise. While it may seem odd, it appears that there is no universally excepted definition of business within the EA community. This layer usually contains business rules and requirements, organizational structure, business processes and models, the mission and vision of the enterprise, and critical success factors.

4.2.2 Data or Information Layer

In the BIAT model, information is associated with business information and other valuable stored data. Every enterprise runs on information, and therefore, the patterns of information used by the business largely determine the data technology required to support the information needs. This layer contains data information and architecture, data management, data delivery, data modeling, data quality, data security, and content management, as well as enterprise reporting and business intelligence.

4.2.3 Applications Layer

Software applications consume, transform, and produce data or information needed by the enterprise's technology users. Often, the heaviest information "consumers" are in HR and finance units, although software increasingly supports facilities management, inventory control, customers, and vendors. This layer contains application integration components, application development models, the definition of services, and service and event architectures.

4.2.4 Technology Layer

The technology domain includes processors, storage and network connectivity, and the middleware that provide the basic computing and communications capabilities for the enterprise. They enable the flow of information that is the lifeblood of the organization. Note that the EIT technology domain thus does not typically include physical process technology such as industrial or manufacturing automation equipment. Often this layer is split into a software and hardware component.

4.2.5 Relationship Between Layers

The business and information layers serve primarily as inputs to the technology design process. However, if the process is rigidly viewed this way, the EA team may run the risk of not putting enough effort into the collaboration and partnership with the enterprise's "business" partners. Such collaboration ensures that the changes in the business processes and information flows support the changes made to the applications and technology layers.

It is common within the EA community to recognize that each of these layers has its own architecture, and that the enterprise architecture is in some sense the sum or union of all these architectures. At the same time, it is also commonly stated within the EA community that the enterprise consists of businesses + EIT, and therefore, that the enterprise architecture is comprised of business architecture + EIT architecture. Digging deeper, EIT architecture is comprised of data/information architecture, applications architecture, and technology architecture, although it is often agreed that the data/information architecture can straddle the boundary between the business and EIT domains).

There are several different models in use for how the integration across the layers or aspects is best achieved. One of the most common is the service model, in which each layer delivers services to the layers above it. Not surprisingly, the question of what exactly makes something a service remains a subject of considerable discussion. Other models focus on the enterprise's value chain, also known as enterprise capabilities.

4.3 Role of Architecture in Strategy Planning

Enterprise architecture (EA) informs strategic planning in several ways. EA supplies "a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands." [7] The blueprint comes in the form of a variety of architectural or design artifacts, such as strategy maps, capability maps, information maps, value maps, and organization maps. These maps provide a variety of perspectives, such as data and processes the enterprise uses to carry out its operations, how processes interact to create value streams, and where technology support is in place. EA provides input to the strategy function at the highest level.

Typically, few artifacts exist when the initial EA program is started. They must be developed with input from all the business stakeholders.

Given the amount of information required to produce the enterprise blueprint, a framework is needed to describe the interconnectedness of the business, information, systems, and technology elements (often called artifacts). In 1987, John Zachman published what is commonly viewed as the first framework describing a classification scheme for artifacts at several levels of abstraction. [8] In the 1990s, a reference model was developed for EA by and for the US Department of Defense (DoD) called the Technical Architecture Framework for Information Management (TAFIM).

In 1995, based on TAFIM, The Open Group Architecture Framework (TOGAF) was first released. TOGAF 9.1 was release in 2011 and it is considered a proven EA methodology. It states that "a complete EA description should contain all four architecture domains (business, data, application, technology), but the realities of resource and time constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive architecture description encompassing all four architecture domains, even if the enterprise scope is ... less than the full extent of the overall enterprise." [9]

While TOGAF may be the most popular EA framework (based on published certification numbers), there are many different frameworks available. Generally, they fall into several categories: consortia developed (e.g., TOGAF), defense industry focused (e.g., DODAF (U.S.)), government-based (e.g., E-overheid NORA (Dutch), open-source (e.g., MEGAF), and proprietary (e.g., Capgemini's IAF). [10]

5 EA Activities

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.

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 5[14]

TOGAF.png

Figure 5. TOGAF 9.1 ADM Steps [14]

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).

5.1 Preliminary Phase: Preparing and Planning the EA Effort

During the planning phase, members of senior management (usually members of the strategy team) define the purpose and focus of the EA program, create the EA team, and define the roles of the team members. Once that is accomplished, the EA team selects the EA framework that will be used by the effort and makes sure that there is an EA information repository in place.

The EA team begins its work by collecting information about the workings of the enterprise. More than anything else, the EA effort results in an actionable plan to achieve the enterprise's strategic objectives. The plan needs to consider laws, mandates, and policies that drive the business. The plan typically builds on the organization's strengths and leverages opportunities, while considering both internal and external impediments and barriers. The EA plan provides the bridge between strategy and execution. Thus, the EA can drive organizational change, enabling the enterprise to achieve important mission outcomes and enhance business success.

5.1.1 Specify the EA Team's Priorities, Scope, and Budget

Once an EA effort has been agreed upon, the enterprise's management needs to give the effort a charter. This charter could be well defined or not; however, the effort is most successful if management can provide information such as:

  • What the team should work on and what the priorities are; this include at least some idea of what the desire state of the organization is
  • What the team needs to accomplish and by when
  • Who the team reports to, how often they should report, and what they should report
  • How the process is going to be governed
  • The budget for the EA project

With this in place, the team can be identified.

5.1.2 Determine EA Team Members

Selecting the EA team members is often a difficult process. One needs to have a chief architect who understands the business and communicates well with people at all levels in the organization. This person must be technically savvy, have EA experience, be good at working with diverse groups with diverse agendas, and be excellent at project management in difficult situations. Few organizations start out with this kind of talent, so it is common for organizations to hire EA consulting firms to get them started, and to help them build and train their own internal team.

You can have an EA team of one, the Lead Enterprise Architect. However, usually the job requires information from several business experts and EIT experts. The number of roles and their duties depends on the scope of the EA effort. Common roles that are often consulted are:

  • Business Architect
  • Information Architect
  • Security Architect
  • Solution Architect
  • Domain Architect
  • Project Architect
  • Application Architect
  • Business Unit Manager
  • Subject Matter Expert
  • Process Owner
  • Compliance Manager
  • HR Manager
  • Finance Manager

Note that the team often starts small and increases in size as the EA effort progresses. Many of the future EA activities require a specialist for that particular activity, such as the application architect.

5.1.3 Identify Business Drivers, Impediments, and Barriers

The team needs to identify the internal and external forces that push the enterprise in specific directions. Drivers can come from governmental legislation, policy, business competition, technology changes, cost changes, organizational restructuring and consolidation, or facility changes. These drivers often result in the definition of key business requirements and strongly affect the architecture at many levels.

Barriers and impediments obstruct or delay the progress of developing or maintaining a useful EA. Barriers hinder development of the EA to accommodate a need or constraint in contrast to drivers, which direct or push the architecture in particular ways.

This activity starts in the preliminary phase, but is fleshed out extensively in future phases of the EA project.

5.1.4 Select Architectural Framework, Methods, and Processes

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.

Figure 6 depicts Capgemini's early Integrated Architecture Framework (IAF). [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:

  • Contextual—Why: the connection to the business strategy and principles
  • Conceptual—What: the service level
  • Logical—How: the logical flows
  • Physical—With what: the specific elements
  • Transformational—When: the dynamic dimension that specifies when the organization will change to the desired state

With these additional layers, different perspectives and dimensions of detail become more apparent than when using the simple BIAT model.

IAF.jpg

Figure 6. Integrated Architecture Framework [13]

Figure 7 shows the Zachman Framework in which artifacts are organized by the audience perspective and the focus of the artifact. [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.

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.

Zachman Framework.jpg

Figure 7. A Populated Version of Zachman Framework for Enterprise Architecture [11]

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.

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.

There are many other frameworks and some are defined for specific domains or technologies. Some of these frameworks are proprietary and others are available for anyone to use. To see a list of both EAs and solution architectures, visit http://www.iso-architecture.org/42010/afs/frameworks-table.html.

In general, the EA team selects the framework or frameworks that best match the enterprise's needs, the maturity of the organization, and the team's comfort and experience with the framework.

5.2 Developing an Enterprise Architecture

Developing an EA includes all the activities associated with creating and maintaining the enterprise architecture for a specific purpose. The EA plan provides the blueprint for transforming the enterprise from the current state to the desired end state that can execute the desire outcomes. That desired state will likely need to address organizational change, business process transformations, data integration, systems reengineering, and technology modernization.

EA serves as a bridge between the enterprise's vision and strategy and how the underlying layers of business elements (including business processes and people) are organized, as well as the flow of information and data elements. Business processes and information are not necessarily automated by EIT. For example, without EIT automation, workers can manually take measurements, create reports, and deliver data and information in those reports. Nonetheless, a complete EA includes those un-automated business elements. On the other hand, where business process and information flows are automated with EIT, EA describes the interdependencies and linkages between different parts of the enterprise, information, applications, and technology infrastructure.

Distinguishing between EA and EIT is important, and by doing so, an organization should clearly recognize that there is a choice to either support business roles, business processes, and information flows with automation or keep them manual.

5.2.1 Develop the Architectural Vision

Once senior management has approved the start of the architectural work, the first task is to create the architectural vision. The architecture vision is a high-level description of the current and desired architectures, most likely an enhanced vision from the outputs from senior management's strategic planning sessions (see Strategy and Governance).

The vision describes what will be delivered and its desired impact on the organization, including the business, data, application, and technology layers. These high-level descriptions are further developed in subsequent phases. The architectural vision also typically outlines a program to develop and deploy the vision.

The artifact of this effort is often called the Statement of Architecture Work. This document is circulated among management and all the stakeholders to build a consensus. This consensus building process is critical and can make or break the entire EA effort. And, one of the most important aspects of this document is the definition of the scope of the effort.

5.2.1.1 Define the As Is and To Be States

Whether developing a long-term enterprise strategy or understanding your current and desired technical architectural capacity, you can't get to where you want to go unless you know where you are. The EA planning process needs to clearly understand the enterprise's and EIT's current (a.k.a. "as is") states as well as the direction the enterprise wants to head, in other words, the desired (a.k.a. "to be") states. This is a careful analysis process and it is critical to the success of the endeavor.

Along with definition of these states, this process should be able to define the purpose of the upcoming EA effort. What does the business want to accomplish with the project? What elements of the business are not well aligned and must be corrected in the future? The team identifies the investment decisions or technical directions that need guidance.

The strategy is most often a long-range plan for achieving organizational goals to meet mission priorities while effectively using available resources. A strategy is often formulated to help an organization achieve an economic, competitive, or positional advantage.

It is important to note that there is significant disagreement as to exactly how to define the "as is" and "to be" states. Some AE teams believe that you should describe the current state first and then create the vision of the future state. Others AE teams believe that you should define the future state before understanding the current state. This second group believes that if you know the current state well, it will influence your vision of the future state too much. They believe that people have a tendency of "editing" their vision of the future based upon what they already know about the present. It is true that the future state definition might need to be "scaled back" when it is determined to be unfeasible; however, during this phase, the vision of the future should be relatively unbridled.

5.2.1.2 Define the Scope of the EA Effort

The scope of the EA establishes many aspects of this current EA project. In essence, the team defines what part of the "to be" or desired state they want to focus on in this current cycle. Things that can be considered are:

  • The organizations within the business that are in focus—Not only are the actual organizations identified, but a specific business process or data set may be selected. In the best of all worlds, the entire enterprise or organization is addressed; however, resources don't always allow that to happen.
  • The areas of technology—At times, an EA planning cycle only covers selected areas or levels of technology. One year, an organization might focus on establishing the EA for communications of the organization (which could include telecom, intranet, internet, and other connectivity). The next year, they might focus on mobile support.
  • The level of detail that needs to be included in the EA—The EA should contain enough detail to:
    • Plan major investments, their lifecycles, and projected costs.
    • Demonstrate that the enterprise strategy is supported by the EA in the timeframe needed.
    • Ensure that needed interfaces between organizations and between EIT systems are adequately specified.
    • Guide systems engineers who are developing designs and specifications for implementing specific investments.

    On the other hand, the EA should not be so detailed that it over-constrains the enterprise. And, it should be sufficiently general to provide latitude in system design decisions and be responsive to technology changes.

  • The planning time horizon—Large organizations often synchronize this scope with the three- to five-year major enterprise planning or budgeting cycle; however, other organizations believe that the planning timeframe needs to be either shorter or more flexible so that the organization can respond faster to unforeseen events and influences.

5.2.2 Develop the Business Architecture

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.

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.

These artifacts draw from the abstract representations of a business shown in 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.

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.

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 Architectural Framework, Methods, and Processes).

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.

Figure2.2 BusinessArchitectureEcosystem.JPG

Figure 8. The BIZBOK Business Architecture Ecosystem [8]

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.

Once the business architecture has been reviewed and approved, all artifacts need to be added to the architectural repository.

5.2.3 Create the Information Systems Architectures

Once the business architecture effort is complete or nearly so, the EA team can start working with EIT on the information systems architecture. This effort usually involves a combination of data/information architecture and application architecture work. As with the business architectural effort, once the "as is" and "to be" states are defined, a gap analysis needs to be performed, which gives a detailed understanding of the scope of the implementation effort.

Some EA specialists recommend a data-driven approach, while others recommend a functional or application-development approach. It appears that the effectiveness of the approach often depends upon the domain and the scope of the EA effort, and what is required to fill "the gap."

This effort needs to not only define the architecture, but also needs to show how the new architecture will support the business architecture and the architecture vision. The connection needs to be clear to all the stakeholders. It also needs to show how the old elements of the infrastructure will connect to any new elements.

The following artifacts are often created during this effort to describe the data architecture:

  • Conceptual data diagram
  • Logical data diagram
  • Data dissemination diagram
  • Data lifecycle diagram
  • Data security diagram
  • Data migration diagram
  • Data entity/data component catalog
  • Data entity/business function matrix
  • Application/data matrix

There are also typically many application architecture artifacts that are created during this effort. Among them are:

  • Application portfolio catalog
  • Interface catalog
  • Application/organization matrix
  • Role/application matrix
  • Application/function matrix
  • Application interaction matrix
  • Application communication diagram
  • Application and user location diagram
  • Application use case diagram
  • Enterprise manageability diagram
  • Process/application realization diagram
  • Software engineering diagram
  • Application migration diagram
  • Software distribution diagram

5.2.4 Define the Technology or Infrastructure Architecture

The next set of activities are to understand the current technology architecture and to develop the target (future) technology architectures that will enable the application and data components of the EIT architecture and, of course, the architecture vision. This effort includes both creating the hardware infrastructure (computers, networks, and devices) and the software infrastructure architectures (operating systems, software platforms, underlying applications, or tools).

This effort requires understanding newly available technologies that might enhance what can be delivered to stakeholders and that might increase application performance. And, as before, the gap analysis between the current and desired states is critical.

Common artifacts from this effort are:

  • Technology standards catalog
  • Technology portfolio catalog
  • Application and technology matrix
  • Environments and locations diagram
  • Platform decomposition diagram
  • Processing diagram
  • Networked computing and hardware diagram
  • Communications engineering diagram

5.2.5 Create an Implementation and Migration Plan

The next effort typically concentrates on how to deliver the architectures to the enterprise. It looks at the gap analysis and the recommendations, and creates an optimized roadmap for the implementation that is based upon business requirements, stakeholder requirements, the ability of the organization to change, and available budget.

The EA team identifies opportunities and solutions to take advantage of quickly. It also identifies implementation constraints that should be avoided or solved quickly. The team usually looks at "filling the gap" incrementally, trying to ensure that the enterprise sees the most value for its investment as quickly as possible.

The main output of this work provides the basis of a well-considered plan called an implementation and migration plan. Components that are created in this effort are:

  • A work package definition identifies a logical collection of changes that are necessary (as a whole) to realize a part of the target architecture. A work package does not necessarily have to result in the full "to be" or desired state. In fact, development frameworks, such as Agile, suggest that these work packages should contain the smallest possible number of changes that will provide significant value to the organization, thus ensuring fast return on investment.
  • 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.
  • 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.
  • The implementation and migration plan takes all of the previous components and provides a schedule of the projects that will realize the desired architecture.

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.

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.

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.

5.3 Governing and Monitoring an Enterprise Architecture

5.3.1 Govern the Enterprise Architecture Program

Architecture governance is the practice of managing and controlling enterprise architectures and other architectures at an enterprise-wide level. It includes the following:

  • Implementing a system of controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization
  • Implementing a system to ensure compliance with internal and external standards and regulatory obligations
  • Establishing processes that support effective management of the above processes within agreed parameters
  • Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization

It is important to distinguish EA governance from general EIT governance, which is covered in detail in Strategy and Governance. In this section, we discuss only those aspects of governance that are concerned with the EA.

EIT governance has recently become a board responsibility, because it is so closely linked to the overall business governance. The governance of an organization's architectures is a key factor in effective EIT-business linkage, and therefore, it is becoming a key board-level responsibility.

Part of the AE team's selected framework needs to support the effective elucidation, communication, and management of the enterprise architecture. Some of the EA artifacts that support the governance process are:

  • Architecture contracts are agreements between developers (whether in-house resources, systems integrators, applications providers, or service providers) and sponsors on the deliverables, quality, and fitness of an architecture. The contracts typically insure that there is a system of continuous monitoring to check integrity, changes, decision-making, and audit of all architecture-related activities within the organization. The purpose is to ensure adherence to the principles, standards, and requirements of the existing or developing architectures. These contracts also typically contain a set of processes and practices that ensure accountability, responsibility, and discipline with regard to the development and usage of all architectural artifacts.
  • Populated and current architecture repository that includes:
    • Current (updated) architecture vision
    • Current architecture definition documents
    • Documented architecture compliance recommendations and dispensations
    • Service delivery requirements and recommendations
    • Performance metrics recommendations
  • Service level agreements (SLAs)

5.3.2 Track and Manage Organizational Change

When the governance process is defined and the supporting agreements, documents, and processes are in place, tracking and managing the implementation of the EA to affect change in the organization needs to occur. Ideally, there will be an organization responsible for overseeing change initiatives (see Change Initiatives). The EA team should coordinate with that group.

The tracking and management effort should:

  • Perform frequent compliance assessments
  • Ensure that the defined architecture lifecycle is maintained
  • Ensure that the EA governance program is executed
  • Ensure that the architecture's capability meets the enterprise's requirements
  • Handle the EIT change request process (see Change Initiatives)

Keeping an EA program on track to meet the organization's needs requires constant measurement, review, and adjustment. It is the tracking and management of the EA program that keeps it on track and makes it effective. Ineffective and unmonitored EA programs often produce artifacts that are never used. In such cases, the cost of the EA program is never recouped by the by the enterprise.

6 Other Enterprise Architecture Aspects

6.1 EA and Non-functional Requirements or Cross-layer Concerns

The Requirements chapter discusses the two types of requirements, functional and non-functional. While EA influences both types, its impact on functional requirements is more obvious. However, EA also influences non-functional requirements and can do so through the overriding EA principles as well as in what are called collaboration contracts between EA artifacts. Here are some examples.

  • Business service collaboration contracts—A business service, or a set of business processes like a financial operation and its expectations in receiving information data elements from a sales service (e.g., an order entry from a sales operation).
  • Technology infrastructure component collaboration contracts—Storage components and networking components. Collaboration contracts between the two might be the quality and reliability expectations in terms of up time, error-free processing, messaging, latency, and so on.

In these contracts, expectations of various qualities are defined and documented in delivery projects as non-functional requirements. By keeping the close association between the collaboration contracts of all the artifacts in the EA repository with the non-functional requirements in the Enterprise IT portfolio of projects, the quality requirements and expectations across the enterprise can be balanced.

6.2 EA Versus Business Process Modeling (BPM)

The discipline of EA has evolved in parallel to the discipline of business process modeling (BPM). Clearly, the business architecture needs to be characterized and described in both EA and BPM "languages" and tools. Over the last decade, this relationship has been recognized and the companies who are developing and providing EA and BPM tools are helping to bridge the gap. Likewise, the respective expert communities recognize the need and are starting to address it.

7 Summary

There are three almost universally adopted concepts that characterize the current state of the art of enterprise architecture:

  • The four-layer stack model—or the four aspects—of an enterprise. EA includes business, solution, information, and technology architectures. Business architecture has a direct relationship to and reciprocal impact on the remaining aspects of EA, particularly the solution and information architectures. For example, information architecture leverages the information aspects of business architecture to craft a wide range of technology options for maximizing accessibility and usage to a various information categories. These range from "big data" to more traditional relational database architectures. Information architecture establishes the critical underpinnings for business automation solutions.
  • Capturing the "as is" and "to be" states and performing a gap analysis between the two is a critical activity that informs the process at all levels.
  • The use of EA frameworks is strongly advised even though there is no clear agreement as to what "the right" framework is. Frameworks need to be useful, practical, and modular in nature; at the same time, they must be able to show an integrated and interdependent view of all the elements of the architecture.

EA is both an input to the enterprise's strategy and a follow-on activity that interprets results, performs gap analysis, and supports execution of the strategic plan. It also adjusts the "to be" architectures when the plan or strategy needs to change direction.

A brilliant business design can be too costly and take too long to satisfy executive demands, or it can be technologically infeasible. This is where enterprise architecture can help ensure that selected business designs and innovation options are not only desirable, but also cost-effective and implementable.

Enterprise architecture can be defined by its scope and subject; it can be about an entire organization or can be narrowed down to a segment, unit, or function. So, EA is scalable and can be small and incremental as well as enterprise-wide. It can assist in both short- and long-term enterprise improvement and transformation planning.

Successful EA functions must be able to balance high-level strategic work with tactical governance and collaboration with solution architectures in the enterprise's IT portfolio, so that the portfolio provides ongoing and clear impact and value.

8 Key Maturity Frameworks

Capability maturity for EIT refers to its ability to reliably perform. Maturity is a measured by an organization's readiness and capability expressed through its people, processes, data, and technologies and the consistent measurement practices that are in place. See Appendix F for additional information about maturity frameworks.

Many specialized frameworks have been developed since the original Capability Maturity Model (CMM) that was developed by the Software Engineering Institute in the late 1980s. This section describes how some of those apply to the activities described in this chapter.

8.1 IT-Capability Maturity Framework (IT-CMF)

The IT-CMF was developed by the Innovation Value Institute in Ireland. This framework helps organizations to measure, develop, and monitor their EIT capability maturity progression. It consists of 35 EIT management capabilities that are organized into four macro capabilities:

  • Managing EIT like a business
  • Managing the EIT budget
  • Managing the EIT capability
  • Managing EIT for business value

Each has five different levels of maturity starting from initial' to optimizing. The most relevant critical capability is enterprise architecture management (EAM).

8.1.1 Enterprise Architecture Management Maturity

The following statements provide a high-level overview of the enterprise architecture management (EAM) capability at successive levels of maturity.

Level 1EA is conducted within the context of individual projects, by applying one-off principles and methods within those projects.
Level 2A limited number of basic architecture artifacts and practices are emerging in certain EIT domains or key projects.
Level 3A common suite of EA principles and methods are shared across the EIT function, allowing a unifying vision of EA to emerge.
Level 4Planning by the EIT function and the rest of the business consistently leverages enterprise-wide architecture principles and methods to enable efficiency and agility across the organization.
Level 5EA principles and methods are continually reviewed to maintain their ability to deliver business value.

9 Key Competence Frameworks

While many large companies have defined their own sets of skills for purposes of talent management (to recruit, retain, and further develop the highest quality staff members that they can find, afford and hire), the advancement of EIT professionalism will require common definitions of EIT skills that can be used not just across enterprises, but also across countries. We have selected three major sources of skill definitions. While none of them is used universally, they provide a good cross-section of options.

Creating mappings between these frameworks and our chapters is challenging, because they come from different perspectives and have different goals. There is rarely a 100% correspondence between the frameworks and our chapters, and, despite careful consideration some subjectivity was used to create the mappings. Please take that in consideration as you review them.

The framework skills mapping exercise for EA was one of significant controversy. Suggested mapping depended on a particular individual's personal definition of EA. Some individuals have a very narrow definition for EA, while other definitions are wide and greatly more encompassing. The EITBOK has adopted a rather wide scope for EA, and the framework mappings below reflect this wide scope.

9.1 Skills Framework for the Information Age

The Skills Framework for the Information Age (SFIA) has defined nearly 100 skills. SFIA describes 7 levels of competency which can be applied to each skill. Not all skills, however, cover all 7 levels. Some reach only partially up the 7 step ladder. Others are based on mastering foundational skills, and start at the fourth or fifth level of competency. It is used in nearly 200 countries, from Britain to South Africa, South America, to the Pacific Rim, to the United States. (http://www.sfia-online.org)

Skill Skill Description Competency Levels
EIT governanceThe establishment and oversight of an organization's approach to the use of information, digital services and associated technology. Includes responsibility for provision of digital services; levels of service, and service quality that meet current and future business requirements; policies and practices for conformance with mandatory legislation and regulations; strategic plans for technology to enable the organization's business strategy; transparent decision making, leading to justification for investment, with appropriate balance between stakeholder benefits, opportunities, costs, and risks.5-7
Information systems coordinationTypically within a large organization in which the information strategy function is devolved to autonomous units, or within a collaborative enterprise of otherwise independent organizations, the coordination of information strategy matters where the adoption of a common approach (such as shared services) would benefit the organization.6-7
Information securityThe selection, design, justification, implementation, and operation of controls and management strategies to maintain the security, confidentiality, integrity, availability, accountability, and relevant compliance of information systems with legislation, regulation, and relevant standards.5-7
Technical specialismThe development and exploitation of expertise in any specific area of information or communications technology, technique, method, product, or application area.5-6
InnovationThe capability to recognize and exploit business opportunities provided by information and communication technology, accepted practices, methods and standards, to ensure more efficient and effective performance of organizations, to explore possibilities for new ways of conducting business and organizational processes, and to establish new services or businesses.5-6
Enterprise and business architectureThe creation, iteration, and maintenance of structures such as enterprise and business architectures embodying the key principles, methods, and models that describe the organization's future state, and that enable its evolution. This typically involves the interpretation of business goals and drivers; the translation of business strategy and objectives into an "operating model"; the strategic assessment of current capabilities; the identification of required changes in capabilities; and the description of inter-relationships between people, organization, service, process, data, information, technology, and the external environment.

The architecture development process supports the formation of the constraints, standards, and guiding principles necessary to define, ensure, and govern the required evolution; this facilitates change in the organization's structure, business processes, systems, and infrastructure in order to achieve predictable transition to the intended state.

5-7
Emerging technology monitoringThe identification of new and emerging hardware, software and communication technologies and products, services, methods, and techniques and the assessment of their relevance and potential value as business enablers, improvements in cost/performance, or sustainability. The promotion of emerging technology awareness among staff and business management.5-6
Network planningThe creation and maintenance of overall network plans, encompassing the communication of data, voice, text, and image, in the support of an organization's business strategy. This includes participation in the creation of service level agreements and the planning of all aspects of infrastructure necessary to ensure provision of network services to meet such agreements. Physical implementation may include copper wire, fiber optic, wireless, or any other technology.5-6
Data managementThe management of practices and processes to ensure the security, integrity, safety, and availability of all forms of data and data structures that make up the organization's information. The management of data and information in all its forms and the analysis of information structure (including logical analysis of taxonomies, data, and metadata). The development of innovative ways of managing the information assets of the organization.5-6
Methods and toolsEnsuring that appropriate methods and tools for the planning, development, testing, operation, management, and maintenance of systems are adopted and used effectively throughout the organization.5-6
Requirements definition and managementThe definition and management of the business goals and scope of change initiatives. The specification of business requirements to a level that enables effective delivery of agreed changes.5-6
Network designThe production of network designs and design policies, strategies, architectures, and documentation, covering voice, data, text, email, facsimile, and image, to support strategy and business requirements for connectivity, capacity, interfacing, security, resilience, recovery, access, and remote access. This may incorporate all aspects of the communications infrastructure, internal and external, mobile, public and private, Internet, intranet, and call centers.5-6
Database designThe specification, design, and maintenance of mechanisms for storage and access to both structured and unstructured information, in support of business information needs.5-6
Information managementThe overall governance of how all types of information, structured and unstructured, whether produced internally or externally, are used to support decision-making, business processes, and digital services. Encompasses development and promotion of the strategy and policies covering the design of information structures and taxonomies, the setting of policies for the sourcing and maintenance of the data content, and the development of policies, procedures, working practices, and training to promote compliance with legislation regulating all aspects of holding, use, and disclosure of data.5-7
EIT strategy and planningThe creation, iteration, and maintenance of a strategy in order to align EIT plans with business objectives and the development of plans to drive forward and execute that strategy. Working with stakeholders to communicate and embed strategic management via objectives, accountabilities, and monitoring of progress.5-7
Technical specialismThe development and exploitation of expertise in any specific area of information or communications technology, technique, method, product, or application area.5-6
Business modelingThe production of abstract or distilled representations of real world, business or gaming situations in traditional or trans-media applications, to aid the communication and understanding of existing, conceptual, or proposed scenarios. Predominantly focused around the representation of processes, roles, data, organization, and time. Models may be used to represent a subject at varying levels of detail and decomposition.5-6
User experience analysisThe identification, analysis, clarification and communication of the context of use in which applications will operate, and of the goals of products, systems, or services. Analysis and prioritization of stakeholders' "user experience" needs and definition of required system behavior and performance. Resolution of potential conflicts between user requirements and determination of usability objectives.5
User experience designThe iterative development of user tasks, interaction and interfaces to meet user requirements, considering the whole user experience. Refinement of design solutions in response to user-centered evaluation and feedback and communication of the design to those responsible for implementation.5-6
AnalyticsThe validation and analysis of significant volumes of data, including the ability to discover and quantify patterns and trends in numbers, symbols, text, sound, and image. Relevant techniques may include statistical and data mining algorithms and machine learning methods such as rule induction, artificial neural networks, genetic algorithms, and automated indexing systems.6-7

9.2 European Competency Framework

The European Union's European e-Competence Framework (e-CF) has 40 competences and is used by a large number of companies, qualification providers, and others in public and private sectors across the EU. It uses five levels of competence proficiency (e-1 to e-5). No competence is subject to all five levels.

The e-CF is published and legally owned by CEN, the European Committee for Standardization, and its National Member Bodies (http://www.cen.eu). Its creation and maintenance has been co-financed and politically supported by the European Commission, in particular, DG (Directorate General) Enterprise and Industry, with contributions from the EU ICT multi-stakeholder community, to support competitiveness, innovation, and job creation in European industry. The Commission works on a number of initiatives to boost ICT skills in the workforce. Version 1.0 to 3.0 were published as CEN Workshop Agreements (CWA). The e-CF 3.0 CWA 16234-1 was published as an official European Norm (EN), EN 16234-1. For complete information, see http://www.ecompetences.eu.

e-CF Dimension 2e-CF Dimension 3
A.1. IS and business Strategy Alignment (PLAN)
Anticipates long-term business requirements, and influences the improvement of organizational process efficiency and effectiveness. Determines the IS model and the EA in line with the organization's policy and ensures a secure environment. Makes strategic IS policy decisions for the enterprise, including sourcing strategies.
Level 4-5
A.3. Business Plan Development (PLAN)
Addresses the design and structure of a business or product plan including the identification of alternative approaches as well as return on investment propositions. Considers the possible and applicable sourcing models. Presents cost benefit analysis and reasoned arguments in support of the selected strategy. Ensures compliance with business and technology strategies. Communicates and sells business plan to relevant stakeholders and addresses political, financial, and organizational interests.
Level 3-5
A.4. Product/Service Planning (PLAN)
Analyzes and defines current and target status. Estimates cost effectiveness, points of risk, opportunities, strengths, and weaknesses, with a critical approach. Creates structured plans; establishes time scales and milestones, ensuring optimization of activities and resources. Manages change requests. Defines delivery quantity and provides an overview of additional documentation requirements. Specifies correct handling of products, including legal issues, in accordance with current regulations.
Level 2-4
A.5. Architectural Design (PLAN)
Specifies, refines, updates, and makes available a formal approach to implement solutions necessary to develop and operate the IS architecture. Identifies change requirements and the components involved: hardware, software, applications, processes, information, and technology platform. Takes into account interoperability, scalability, usability, and security. Maintains alignment between business evolution and technology developments.
Level 3-5
A.7. Technology Trend Monitoring (PLAN)
Investigates latest ICT technological developments to establish understanding of evolving technologies. Devises innovative solutions for integration of new technology into existing products, applications, or services or for the creation of new solutions.
Level 4-5
D.10. Information and Knowledge Management (ENABLE)
Identifies and manages structured and unstructured information and considers information distribution policies. Creates information structure to enable exploitation and optimization of information. Understands appropriate tools to be deployed to create, extract, maintain, renew, and propagate business knowledge in order to capitalize from the information asset.
Level 3-5
D.11. Needs Identification (ENABLE)
Actively listens to internal/external customers, articulates and clarifies their needs. Manages the relationship with all stakeholders to ensure that the solution is in line with business requirements. Proposes different solutions (e.g., make-or-buy) by performing contextual analysis in support of user centered system design. Advises the customer on appropriate solution choices. Acts as an advocate engaging in the implementation or configuration process of the chosen solution.
Level 3-5

9.3 i Competency Dictionary

The Information Technology Promotion Agency (IPA) of Japan has developed the i Competency Dictionary (iCD) and translated it into English, and describes it at https://www.ipa.go.jp/english/humandev/icd.html. The iCD is an extensive skills and tasks database, used in Japan and southeast Asian countries. It establishes a taxonomy of tasks and the skills required to perform the tasks. The IPA is also responsible for the Information Technology Engineers Examination (ITEE), which has grown into one of the largest scale national examinations in Japan, with approximately 600,000 applicants each year.

The iCD consists of a Task Dictionary and a Skill Dictionary. Skills for a specific task are identified via a "Task x Skill" table. (See Appendix A for the task layer and skill layer structures.) EITBOK activities in each chapter require several tasks in the Task Dictionary. The complete iCD Task Dictionary (Layer 1-4) and Skill Dictionary (Layer 1-4) can be obtained by returning the request form provided at http://www.ipa.go.jp/english/humandev/icd.html.

Task DictionarySkill Dictionary
Task Layer 1 (Task Layer 2)Skill ClassificationSkill ItemAssociated Knowledge Items
Formulation of EIT adoption plan
(EIT strategy formulation and execution promotion)
System strategy planning methods Information system strategy
  • Application service provider (ASP)
  • Business process outsourcing (BPO)
  • EIT portfolio model
  • EIT industry trends (cases)
  • EIT management capability index
  • EIT investment management
  • Enterprise architecture (EA)
  • Knowledge related to cross license agreement
  • Control framework
  • System owner
  • System lifecycle
  • System structure
  • System architecture knowledge (functional decomposition of hardware/software/manual work, hardware architecture, software architecture, application architecture, IS plan)
  • Knowledge related to software agreement
  • Data owner
  • Balance score card
  • Business process management (BPM)
  • Business process re-engineering (BPR)
  • Business process notation methods
  • Business model
  • Business environment analysis methods
  • Process framework
  • Benchmarking
  • Knowledge related to license agreement
  • Risk analysis techniques
  • Act against delay in payment of subcontract proceeds, etc. to subcontractors
  • Development return on development investment
  • Business operations model
  • Design of business operations
  • Business analysis methods
  • Information systems model
  • Significance and purpose of information system strategy
  • Information systems strategy implementation management
  • Information systems strategy evaluation
  • Computerization promotion system
  • Computerization investment planning
  • Product knowledge and trends (cases)
  • Total optimization planning
  • Quality control (quality control framework)

10 Key Roles

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.

The following roles are common to ITSM:

  • Business Relationship Manager
  • Enterprise Architect
  • Service Catalog Manager
  • Service Portfolio Manager

Other key roles include:

  • Business Architect
  • Business Analyst
  • Data Architect
  • EIT Management Team
  • Solution Architect
  • Technology Architect

11 Standards

ISO 15704:2000, Industrial automation systems—Requirements for enterprise-reference architectures and methodologies

ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture description

TOGAF® Version 9.1, available at http://www.opengroup.org/togaf/downloads

12 References

[1] L. Fehskens, "Why We Can't Agree on What "Enterprise Architecture" Means, and Why That's OK, At Least for Now," Enterprise Architecture Conference Europe, London June 2013.

[2] ISO/IEC/IEEE, "ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture description," http://www.iso.org/iso/catalogue_detail.htm?csnumber=50508

[3] Federation of EA Professional Organizations (FEAPO), "Common Perspectives on Enterprise Architecture," Architecture and Governance Magazine, Issue 9-4, November 2013, pp.11-17.

[4] M. Porter, "The Five Competitive Forces that Shape Strategy," Harvard Business Review, January 2008, pp. 79-83.

[5] J. Lapalme, "Three Schools of Thought on Enterprise Architecture," IT Professional, vol.14, no. 6, pp. 37-43, Nov.-Dec. 2012, doi:10.1109/MITP.2011.109.

[6] N. Malik, "Three Schools of Thought for Enterprise Architecture," blog, 28 May 2012; http://blogs.msdn.com/b/nickmalik/archive/2012/05/28/three-schools-of-thought-for-enterprise-architecture.aspx

[7] J. Zachman, "A Framework for Information Systems Architecture," IBM Systems Journal, vol 26, no 3, 1987, IBM Publication G321-5298.

[8] The Open Group (January 23, 2015),"A Historical Look at Enterprise Architecture with John Zachman" http://blog.opengroup.org/2015/01/23/a-historical-look-at-enterprise-architecture-with-john-zachman/

[9] The Open Group (2011),"TOGAF 9.1, Part 11: Architecture Development Method (ADM)—Preliminary Phase" http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html

[10] Enterprise Architecture Framework, Wikipedia, http://en.wikipedia.org/wiki/Enterprise_architecture_framework

[11] This image is copyright John A. Zachman and Zachman International®, Inc. Published with the permission of John A. Zachman and Zachman International®, Inc., www.zachman.com

[12] J. van't Wout et al, "The Integrated Architecture Framework Explained," Springer-Verlag, 2010.

[13] Dekker, Morsink & Partners, http://www.dekkermorsink.nl/raamwerken.htm

[14] The Open Group, TOGAF9.1 ADM Steps Reference Card

13 Additional Reading

Schekkerman, "How to Survive in the Jungle of Enterprise Architecture Frameworks," Trafford

Ross Weill and Robertson, "Enterprise Architecture as Strategy," Harvard Business School Press.

Fine, Charles, Clockspeed : Winning Industry Control in the Age of Temporary Advantage, Perseus Books, 1998.