Enterprise Architecture
Note: This wiki is a work in progress, and may contain missing content, errors, or duplication. We welcome feedback, edits, and real-world examples.
Contents
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 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.
The results of the EA process provides inputs to the enterprise's strategy at the highest level. EA also takes the enterprise's strategy and figures how to manifest it throughout the organization, both high and low. <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.
2 Goals and Principles
The goals of the Enterprise Architecture 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 enterprises long-term goals and future desired state. Provide holistic information and insights to help executives and IT make better decisions and to identify opportunities to implement solutions that will enable the organization to reach the future desired state. - Align IT 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 IT, 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 Enterprise Architecture include:
- Architectural decisions seek to simplify operations.
- Decision are based on 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 should promote collaboration between the business and IT.
- 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
Figure 1. Context Diagram for Enterprise Architecture
4 What is Enterprise Architecture?
4.1 The Concept of Enterprise
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.
4.2 The Concept of Architecture
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]
4.3 A Definition of Enterprise Architecture
The Federation for Enterprise Architecture Professional Organizations (FEAPO) defines EA 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 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 Figure 2).
Figure 2. Urban Planner and Enterprise Architect versus Building Architect and Solution Architect [3]
4.4 The Evolution of Enterprise Architecture
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.
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, 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: [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]
- Enterprise IT architecting — Designing IT services and creating IT systems that address the enterprise's needs
- Enterprise integrating — Aligning the business with all of its capabilities, including IT; uses capability analysis to understand the impacts of strategy on the business processes and systems, and helps to frame the initiatives that should be created, and insures that investments are made in the right place
- 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
These differences between these categories vis depicted graphically in Figure 3.
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, 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.
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. [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).
In 1995, based on TAFIM, The Open Group Architecture Framework (TOGAF) was first released. Since then, TOGAF 9.1 was release in 2011 and it is considered a proven enterprise architecture 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]
4.5 The As Is and To Be States
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 6. [14]
Figure 6. TOGAF 9.1 ADM Steps [14]
4.6 The Layers or Aspects of Enterprise Architecture
The conventional model (called the BIAT model [1]) of an organization’s EA is sometimes represented as a four layer horizontal stack (see Figure 4).
Figure 4. Conventional BIAT Diagram (Note: In some diagrams, the layers are shown vertically and might be called domains or aspects.)
4.6.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. Instead, the EA community simply knows what business means; however, some sense of what business is, can be inferred from the stack metaphor — it is whatever is ultimately supported by the technology layer.
4.6.2 Data or Information Layer
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.
4.6.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.
4.6.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 technologies.
4.6.5 Where the Action Is
Three unstated presumptions of the BIAT model are that
- The transformative value of EA is typically delivered by transforming the application and technology layers,
- The agility of the enterprise is a consequence of agility of the EIT function, and
- The alignment of the business and EIT is achieved by "aligning EIT" with the business.
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.
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).
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.
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.
Figure 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.
Figure 5. Modified BIAT Diagram
4.7 Evolving EA Frameworks
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 Zachman Framework, which is one of the first EA frameworks, and a simpler version, the 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:
- Contextual — the why; the connection to the business strategy and principles
- Conceptual — the what; the service level
- Logical — the how; the logical flows
- Physical — the with what; the specific elements
Figure 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 Zachman Framework, and it was groundbreaking when it was introduced. [11]
Figure 7. Zachman Framework for Enterprise Architecture [11]
Figure 8 depicts the Integrated Architecture Framework (IAF) in less detail than the Zachman Framework figure. [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.
Figure 8. Integrated Architecture Framework [13]
With these additional layers, different perspectives and dimensions of detail become more apparent than in the simple BIAT model.
5 Enterprise IT Architecture and Relationships to Other Disciplines
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.
5.1 The Relationship between EA and Other Architectures
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.
Figure 9 shows that the simple view of enterprise architecture (first introduced in Figure 5) also describes other typical architecture types. All of them must consider solution, information, application, software, middleware, infrastructure, and network storage.
Figure 9. Enterprise and Other Enterprise-related Architectures
5.2 The Relationship between Enterprise Architecture and Enterprise IT
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.
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.
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.
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:
- Strategy maps
- Capability maps
- Information maps
- Value maps
- Heat maps
- Organization maps
- Operating models
- Product maps
- Stakeholder maps
- Process models
- Dynamic rules based routing maps
- Data models
- Network models
- Systems models
- Vitality and renewal plans
- A wide range of hybrid blueprints and models with specialty uses based on the challenge at hand
5.3 Solutions and Their Relationship to EA
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 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.
5.4 EA and Nonfunctional 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 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.
- 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 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.
5.5 EA and Business Architecture and 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.
5.6 EA and Scope
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.
6 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
- The as is and to be states
- The use of EA frameworks
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 Construction chapter).
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.
EA 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.
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.
7 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. Please 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.
7.1 IT-Capability Maturity Framework (IT-CMF)
The IT-CMF was developed by the Innovation Value Institute in Ireland. It helps organizations to measure, develop, and monitor their EIT capability maturity progression. It consists of 35 IT management capabilities that are organized into four macro capabilities:
- Managing IT like a business
- Managing the IT budget
- Managing the IT capability
- Managing IT 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).
7.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 1 | Enterprise architecture is conducted within the context of individual projects, by applying one-off principles and methods within those projects. |
| Level 2 | A limited number of basic architecture artefacts and practices are emerging in certain IT domains or key projects. |
| Level 3 | A common suite of enterprise architecture principles and methods are shared across the IT function, allowing a unifying vision of enterprise architecture to emerge. |
| Level 4 | Planning by the IT function and the rest of the business consistently leverages enterprise-wide architecture principles and methods to enable efficiency and agility across the organization. |
| Level 5 | Enterprise architecture principles and methods are continually reviewed to maintain their ability to deliver business value. |
8 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 3 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 Enterprise Architecture (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.
8.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 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)
| Skill | Skill Description | Competency Levels |
|---|---|---|
| IT governance | The establishment and oversight of an organisation'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 which meet current and future business requirements; policies and practices for conformance with mandatory legislation and regulations; strategic plans for technology to enable the organisation'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 coordination | Typically within a large organisation in which the information strategy function is devolved to autonomous units, or within a collaborative enterprise of otherwise independent organisations, the coordination of information strategy matters where the adoption of a common approach (such as shared services) would benefit the organisation. | 6-7 |
| Information security | 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. | 5-7 |
| Technical specialism | The development and exploitation of expertise in any specific area of information or communications technology, technique, method, product or application area. | 5-6 |
| Innovation | The capability to recognise and exploit business opportunities provided by information and communication technology, best practices, methods and standards, to ensure more efficient and effective performance of organisations, to explore possibilities for new ways of conducting business and organisational processes, and to establish new services or businesses. | 5-6 |
| Enterprise and business architecture | The creation, iteration, and maintenance of structures such as enterprise and business architectures embodying the key principles, methods and models that describe the organisation'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, organisation, 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, assure and govern the required evolution; this facilitates change in the organisation's structure, business processes, systems and infrastructure in order to achieve predictable transition to the intended state. |
5-7 |
| Emerging technology monitoring | 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. | 5-6 |
| Network planning | The creation and maintenance of overall network plans, encompassing the communication of data, voice, text and image, in the support of an organisation'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, fibre-optic, wireless, or any other technology. | 5-6 |
| Data management | 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 organisation’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 organisation. | 5-6 |
| Methods and tools | Ensuring that appropriate methods and tools for the planning, development, testing, operation, management and maintenance of systems are adopted and used effectively throughout the organisation. | 5-6 |
| Requirements definition and management | 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. | 5-6 |
| Network design | The production of network designs and design policies, strategies, architectures and documentation, covering voice, data, text, e-mail, 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 centres. | 5-6 |
| Database design | The 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 management | 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. | 5-7 |
| IT strategy and planning | The creation, iteration and maintenance of a strategy in order to align IT 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 specialism | The development and exploitation of expertise in any specific area of information or communications technology, technique, method, product or application area. | 5-6 |
| Business modelling | 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, organisation and time. Models may be used to represent a subject at varying levels of detail and decomposition. | 5-6 |
| User experience analysis | 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 prioritisation of stakeholders’ “user experience” needs and definition of required system behaviour and performance. Resolution of potential conflicts between user requirements and determination of usability objectives. | 5 |
| User experience design | 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-centred evaluation and feedback and communication of the design to those responsible for implementation. | 5-6 |
| Analytics | 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. | 6-7 |
8.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, please see http://www.ecompetences.eu.
| e-CF Dimension 2 | e-CF Dimension 3 |
|---|---|
| A.1. IS and business Strategy Alignment (PLAN) Anticipates long term business requirements, influences improvement of organisational process efficiency and effectivenes. Determines the IS model and the enterprise architecture in line with the organisation’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) Analyses 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 optimisation 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. Architecture 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 optimisation of information. Understands appropriate tools to be deployed to create, extract, maintain, renew and propagate business knowledge in order to capitalise 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 |
8.3 i Competency Dictionary
The Information Technology Promotion Agency (IPA) of Japan has developed the i Competency Dictionary (iCD), 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. 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. (Please 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 Dictionary | Skill Dictionary | ||
|---|---|---|---|
| Task Layer 1 (Task Layer 2) | Skill Classification | Skill Item | Associated Knowledge Items |
| Formulation of IT adoption plan
(IT strategy formulation and execution promotion) |
System strategy planning methods | Information system strategy |
|
(More)
9 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 associating those with skills in the IPA database.
The following roles are common to ITSM.
- Enterprise Architect
- Service Portfolio Manager
- Service Catalog Manager
- Business Relationship Manager
10 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
11 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
[15] C. Fine, “Clockspeed,” Perseus Books, 1998.
12 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.
