Before diving into the fundamental steps of developing an Enterprise Architecture, let’s briefly recap what an Enterprise Architecture is and why it is important for an enterprise to develop one. An architecture represents a collection of elements and how they relate to each other. Examples of architectures include business architectures, software architectures, hardware architectures, and network architectures. A hardware architecture will contain all of the hardware that hosts and supports the software applications utilized by the enterprise in its business operations.
Naturally, Enterprise Architecture describes the elements that make up the enterprise and how they relate to each other. The goal of Enterprise Architecture is the alignment of business and IT through establishing a common understanding of how people, business processes, and technology must collaborate to achieve a strategic business vision. Enterprise architecture is both a process and its result. It describes the vision, the steps required to achieve it, and the standards that must be maintained throughout its pursuit. An Enterprise Architecture encompasses all the above through its multiperspective view of the entire enterprise. It is a system of systems. There’s precisely one Enterprise Architecture that goes to different levels of detail according to the purpose it must meet.
EA is a time-consuming exercise. Developing an Enterprise Architecture that delivers tangible business value requires a multidisciplinary team of architects. Despite its complexity, the Enterprise Architecture must be understandable to all stakeholders. It is for this reason that it is structured in multiple layers and perspectives with each communicating a distinct message to a specific group of stakeholders. It is the interconnectedness of these distinct messages that ultimately creates a big picture and common understanding of the business vision to all stakeholders. For instance, to business leaders, the Enterprise Architecture must be a vehicle for communicating business strategy while also being a guide for those tasked with implementation. Consequently, stakeholder engagement plays a central role in developing an Enterprise Architecture.
Developing an Enterprise Architecture is an iterative process that should result in a well-defined and repeatable program for transforming organizations in a controlled fashion. This process will include establishing an architecture framework, producing architecture artifacts, and governing the implementation of the architecture. A key part of this is establishing an enterprise-wide understanding of the word “architecture” early on.
This chapter will look at the development of the business architecture, application architecture, data architecture, and infrastructure architecture which were introduced in Chapter 1.
The Enterprise Architecture Framework
The process of developing an Enterprise Architecture is defined by an Enterprise Architecture Framework. It contains the tools, processes, principles, and templates required to create an Enterprise Architecture. The Open Group Architecture Framework (TOGAF) and the Zachman Framework are two of the most common EA frameworks. They put forward standards, approaches, services, design, components, and concepts that guide the development of specific architectures.
The EA framework must be responsive to the enterprise’s strategic goals and must therefore be founded on a thorough understanding of the enterprise’s business and IT visions. It must be clear and robust enough to guide the development of the Enterprise Architecture but still be flexible enough to adapt to environmental changes over time.
- 1.
Gain insight into the current state of your enterprise
- 2.
Enable the business to measure the gap between where your business is and where you would want it to be
- 3.
Accurately align business processes with the IT processes that support them
- 4.
Deploy enterprise-wide changes faster through established standards and governance
- 5.
Greater accountability for and control of IT costs within the business context
- 6.
A common language for enterprise-wide decision making, particularly on IT investments
- 7.
Create a well-defined and clear IT landscape
So, what does it take to develop an Enterprise Architecture? The following are the two key elements required.
The Framework
A proven methodology must be followed in architecture development.
Recognized standards and principles must form the basis of compliance in producing architectural deliverables.
Relevant best practice templates must guide the production of architectural artifacts.
The People
The right skills, resources, and organizational buy-in are the most crucial aspects of developing an Enterprise Architecture.
Stakeholder engagement and stakeholder modelling are the starting point of ensuring organizational alignment and facilitate other important steps such as requirements modelling.
Business leaders and steering committees must deliver robust governance of the Enterprise Architecture effort.
These elements are critical when developing an Enterprise Architecture.
The Framework
This section gives a high-level overview of Enterprise Architecture Frameworks. An Enterprise Architecture Framework is a program that guides the process of Enterprise Architecture development by providing a set of practices, principles, and requirements for artifacts that describe an enterprise’s architecture. It also describes how to use the resultant architecture.
As a single point of departure, the framework can be seen as a mechanism that allows a team of enterprise architects to understand each other and create the shared language required for all stakeholders to understand the enterprise vision. Creating your enterprise’s EA Framework may be a matter of adapting a mainstream framework like TOGAF or the Zachman Framework, or it could mean inventing one from scratch. Adopting the EA Framework will include wording it in a way that the people in your enterprise understand and possibly going through test runs to see how well it aligns with your organizational culture.
At a minimum, components of Enterprise Architecture framework include architecture domains, standards, and a view model
Architecture Domains
A pyramid diagram of the architecture domain begins with business as the driver at the top, followed by data and applications as the facilitators and infrastructure as the supporter.
Domain architectures
The architecture domains in Figure 3-1 are regarded as layers that contain processes within themselves and also offer services to the layers above. This is depicted through the pyramid structure of the diagram. Each layer is supported by the one below it. The Business Architecture drives the organization’s business strategy through its business capabilities. The Data Architecture and Application Architecture facilitate the execution of the business capabilities through supporting applications and data. The Infrastructure Architecture mainly includes low-level hardware such as servers, switches, and other ancillary services that support the entire enterprise. The architecture layers and how they are documented in the Enterprise Architecture will be explored in depth later in this chapter. EA implementation must be executed at a specific standard to enhance the likelihood of its success. The EA framework contains standards that guide EA implementation.
Standards
Standards form a model or measure for comparison to attain a level of quality assurance. They may be policies or guidelines the EA development process and EA itself must conform to. These policies or guidelines consist of rules that control the specification of Enterprise Architectures and the arrangement of their components. For example, an enterprise may have cybersecurity standards that include access management and password policies. In the design of the security aspect of the Enterprise Architecture, architects in conjunction with the cybersecurity team must ensure that processes are in place to ensure that these cybersecurity standards are met.
Standards may also include prescriptions of the kind of design patterns, architecture representations, architecture vocabulary, or architecture artifacts that must be utilized within a particular context. The use of an EA framework in the development of an Enterprise Architecture is a standard as there will be a notable difference between an EA developed using an EA framework and one developed with no clear frame of reference.
The stakeholders within the architecture
The goals, objectives, and concerns associated with that architecture
Architecture perspectives that cater to every stakeholder
How those perspectives relate to each other
An enterprise architect seeks to deliver consistent IT services, adopting a standardized approach to developing products and applications. Enterprise architecture aids that effort greatly. For example, by using open-system standards, you can provide common services and create reusable building blocks. This will save the business costs and facilitate interoperability.
View Model
System specifications are generally too extensive and comprehensive to be understood by a single individual. Additionally, stakeholders have different concerns and therefore have different end goals when examining the Enterprise Architecture. Frameworks introduce different view models that facilitate stakeholder engagement by providing different viewpoints into the specification of a complex architecture. Consequently, Enterprise Architectures are inherently multidimensional and their descriptions should follow suit. An EA framework enables the creation of viewpoints that are directly relevant to stakeholders’ concerns.
Enterprise Architectures must depict complex systems in a context relevant to their audiences. These audiences comprise executives, business leaders, and IT personnel. Each audience must view the Enterprise Architecture in terms that they understand and that also speak to their concerns within the enterprise. View models comprise views and viewpoints that create an approach to system analysis that is relevant to the audience analyzing the Enterprise Architecture. They allow different stakeholders to comprehend a very complex system of systems and how they relate.
A pyramid diagram of architecture domains consists of different stakeholders that oversee each of the domains. Example HR, security managers.
Different stakeholder perspectives
A view is a representation of the entire architecture through the lens of a particular group of concerns. Each viewpoint is a partitioning of the architecture according to specific stakeholder concerns. A view omits information deemed not relevant to a particular group of stakeholders while maintaining relevant information with the purpose being to simplify the Enterprise Architecture for those specific stakeholders by only addressing what concerns them. An architectural viewpoint developed to accommodate business leaders will not go in depth about supporting infrastructure such as network topologies but rather focus on business standards, processes, and principles. It may however depict how the availability of a robust network supports the business processes to achieve those business standards and abide by business principles. Viewpoints facilitate the analysis of specific areas of expertise.
Essentially, a view represents a specification of the architecture at a particular level of abstraction from a particular viewpoint (related set of concerns). Higher levels of abstraction are less detailed and allow the architect to understand the entire architecture. Lower levels of abstraction allow the architect to zone in on specific issues. A viewpoint model includes the objects that are part of the viewpoint but also includes the other object relationships that are relevant to that viewpoint within the system.
It is critical to understand the purpose of the architecture to direct efforts toward meeting it. Stakeholders must be able to leverage the view models in understanding the architecture within the context of their roles to deduce whether it will meet their goals. Frameworks assist as a minimum guideline for each stakeholder’s interest, but the architect must still engage stakeholders to establish their specific interests in addition to the guidelines. View models provide an approach to architecture development that communicates a common and relevant understanding while remaining flexible enough to accommodate changes in the architecture.
An illustration of a stakeholder's point of view on E A development. Users represent their duties, and are influential in user testing. Architects align business objectives with software systems. Customers enhance the service delivery of the enterprise, and developers have to analyse the current systems and make decisions.
Stakeholder concerns and how they influence EA development
Each view has only enough detail to address the concerns of the stakeholder. Customers are concerned with the high-level functions of the architecture that provide the services they expect. Users only want to see enough detail to be convinced that the resulting systems will assist them in their duties, whereas developers need enough detail to build the systems. Accommodating all these perspectives means representing the architecture in multiple views. For instance, by providing high-level focused models for the customer and user; and more detailed and elaborate descriptions for the system architects and developers.
The next section dives into one of the most popular EA frameworks, The Open Group Architecture Framework (TOGAF).
The Open Group Architecture Framework (TOGAF)
As the SAP Enterprise Architecture Framework is founded upon The Open Group Architecture Framework (TOGAF) standard, we shall have a brief look at some of its main elements. TOGAF provides adaptable EA processes, best practices, structures, guidelines, techniques, roles, artifacts, and principles that save the time of creating your own EA Framework from scratch. The guidance provided by TOGAF has been tried and tested as a framework for the designing, overseeing, and governing of Enterprise Architecture.
- 1.
Introduction
- 2.
Architecture Development Method (ADM)
- 3.
ADM Guidelines and Techniques
- 4.
Architecture Content Framework
- 5.
Enterprise Continuum and Tools
- 6.
Reference Model Library
- 7.
Architecture Capability Framework
- 1.Introduction
Provides a high-level introduction to the key concepts of Enterprise Architecture including domain architectures, ADM, repositories, etc.
Provides definitions of common terms such as defining an “enterprise” and “Enterprise Architecture”
- 2.Architecture Development Method (ADM)
An iterative cycle that provides repeatable processes for developing architectures.
It consists of nine phases that guide architects in developing Enterprise Architectures:
- 1.Preliminary Phase – Defining the principles, objectives, and requirements for a future architecture
- 2.
Phase A: Architecture Vision – Determining the scope of the architecture and the methodologies that will be utilized
- 3.
Phase B: Business Architecture – Describing an architecture vision through models
- 4.
Phase C: Information Systems Architectures – Data modelling and application architecture
- 5.
Phase D: Technology Architecture – Translating a system description into an actionable implementation plan
- 6.
Phase E: Opportunities and Solutions – Defining the main steps toward changing your current architecture to the target one, the basis of the implementation plan
- 7.
Phase F: Migration Planning – Determining timelines, required resources, road map, and costs of the implementation plan
- 8.
Phase G: Implementation Governance – Establishing governance mechanisms for architecture development
- 9.
Phase H: Architecture Change Management – Providing a controlled process for implementing change
The ADM is the most recognizable part of TOGAF including clear activities and expected inputs and outputs.
Phases can be adapted to the extent applicable to the enterprise.
- 3.ADM Guideline and Techniques
The guidelines provide alternatives for the application of ADM in different usage scenarios such as the use of iteration or when addressing specific requirements.
Techniques support the tasks that are carried out in the ADM such as performing a gap analysis or risk management.
- ADM Guidelines and Techniques covers the following topics:
- 1.
Iteration in ADM
- 2.
Architecture Landscape
- 3.
Security Architecture
- 4.
SOA
- 5.
Architecture Principles
- 6.
Stakeholder Management
- 7.
Architecture Patterns
- 8.
Business Scenarios and Business Goals
- 9.
Gap Analysis
- 10.
Migration Planning Techniques
- 11.
Interoperability Requirements
- 12.
Business Transformation Readiness Assessment
- 13.
Risk Management
- 14.
Capability-Based Planning
- 4.Architecture Content Framework
A model that categorizes the outputs of Enterprise Architecture development.
It provides a checklist of architecture outputs.
It establishes an enterprise-wide standard for the delivery of architecture outputs during ADM process.
- It provides specific examples of each content type and forms clear distinctions between artifacts, deliverables, and building blocks:
Deliverables – Normally, the work products of projects that are reviewed and signed off by stakeholders. They may form reference models for future architectural efforts.
Artifacts – Catalogs, matrices, and diagrams that are used to describe features of the architecture.
Building blocks – A package of functionality defined to meet the business needs across an organization.
- 5.Enterprise Continuum and Tools
A model for structuring a virtual repository
A methodology to classify solution artifacts and classify architecture
- Comprised of two inner continuums, the Architecture Continuum and Solutions Continuum
The Architecture Continuum categorizes outputs (deliverables, artifacts, building blocks) with regard to rules, architecture designs, representations, and relationships. The Architecture Continuum guides the Solutions Continuum.
The Solutions Continuum provides actual methods to implement the assets in the Architecture Continuum, leveraging technologies and frameworks. It supports the Architecture Continuum.
- 6.Reference Model Library
Generic reference architecture models that address common business objectives.
- There are two reference models:
Technical Reference Model (TRM) – A Foundation Architecture that provides a model for generic services and functions as the foundation to more specific architecture
Integrated Information Infrastructure Model (III-RM) – A model for business application and infrastructure application
The generic nature of TRM is a result of it categorizing services by functional area without delving into how they are implemented. This means you get a standard information system model that guides the design and development of customized information systems.
TRM and III-RM are the foundation of capturing the business environment in the framework.
They guide you in translating business criteria into a language and specifications that technology managers can understand and use. Reference models create a shared understanding that architects, managers, and all staff use to make sure development initiatives are in line with the enterprise’s overall strategy. Reference models should not overly constraint Enterprise Architecture development but should be used as a guide without stifling the architect’s creativity.
- 7.Architecture Capability Framework
The Architecture Capability Framework goes over the structure, processes, skills, roles, and responsibilities required to establish and operate an architecture practice within an enterprise.
The enterprise identifies governing bodies that will govern the Enterprise Architecture development process throughout the organization.
- An Enterprise Architecture capability is established through an architecture board, compliance reviews, contracts, governance, maturity models, and employee skills frameworks:
- 1.
Architecture board – Consists of representative stakeholders that oversee the implementation of the governance strategy
- 2.
Compliance reviews – A means to scrutinize the compliance of a specific project against established architectural criteria and business objectives
- 3.
Architecture contracts – Agreements on the deliverables between development partners and sponsors
- 4.
Architecture maturity models – Used as a comparative measure to assess the enterprise’s level of architectural maturity and used as the basis for decision making in regard to the next steps in the evolution of the Enterprise Architecture
- 5.
Architecture skills frameworks – Insights into the competency levels required for specific roles
When Would You Use TOGAF?
When you need a highly detailed and standardized framework to govern your architectural transformation
An iterative process that continually aligns your processes with current goals
An end-to-end means for executing the architecture development process
A framework guides the enterprise in defining the architecture, but there is still a need for a clear action plan for building it in the context of your specific enterprise particularly in the context of the resources available to you such as skills, time, and cost. There are many implicit factors to take into account that may not be immediately apparent. For instance, the scheduling of the Enterprise Architecture development effort has to be structured in such a way that results can be seen early on in order to boost team morale.
The action plan should define the steps required to transition the enterprise toward its target architecture founded upon a robust modernization strategy. The next steps are to initiate the preceding Architecture Development Method by creating an architecture vision.
The Architecture Vision
The architecture vision provides an overview of how the entire enterprise will be transformed by the proposed architecture. It describes the domains of business, data, applications, and infrastructure in the context of their as-is state (baseline architecture) and to-be state (target architecture). It can be considered a preliminary document to the final architecture description but should be referenced continually during the process of Enterprise Architecture development.
This phase initiates and formalizes the Enterprise Architecture development effort as a legitimate project within the enterprise. It does this through getting the support of key decision makers through various activities such as identifying business drivers and aligning them to the architecture purpose, validating architecture principles, scoping the project, and identifying stakeholder concerns and articulating how they will be addressed. An architecture vision creates a common understanding of the project across the enterprise by communicating what needs to be done and why, not necessarily how it needs to be done at this stage. It enables stakeholders to better understand their roles within the Enterprise Architecture and how their interests will be met. The main output of this phase is a Statement of Architecture Work.
What strategic goals will the architecture help in achieving?
Who are the stakeholders and how will they use the architecture?
What problems does the architecture aim to solve?
Which problems are the priorities?
What standards will we use for documenting the process?
- 1.
Ensure that the project is adequately recognized and established within the enterprise. Line managers and other decision makers must be fully onboard.
- 2.
Confirm the business objectives, principles, and goals driving the organization.
- 3.
Identify relevant stakeholders and their interests.
- 4.
Define the scope of the baseline architecture effort.
- 5.
Identify the business requirements to be met and the constraints that must be overcome.
- 6.
Propose an architecture definition that addresses these requirements and constraints.
- 7.
Attain approval to proceed through articulating benefits of the EA effort to decision makers
- 8.
Understand the impact of the project in the context of the other projects the enterprise is running
Activities must be carried out to ensure enterprise-wide acknowledgment of the project. This starts by the purpose of the architecture vision being clearly articulated. Business drivers that are linked to a return on investment motivate the stakeholders within the enterprise to pursue Enterprise Architecture development. Articulating how stakeholder interests will be met through Enterprise Architecture development is the goal of this phase. All of this will ultimately lead to gaining support from corporate and line management.
On a strategic level, there must be a thorough understanding of the business strategy and goals to bring them into synergy with the goals and objectives of the Enterprise Architecture. It is important to ensure that the business goals and drivers are documented and accepted by corporate management through validating their accuracy. If they do not exist, work with the relevant parties to define them. In similar fashion, review the architecture principles that will guide the development of the baseline architecture. Typically, these principles would have been provided by a committee tasked with creating a shared IT vision for the enterprise. The architecture vision will include a first draft of the baseline and target architectures that will be built upon going forward.
The scope of the Enterprise Architecture development effort must be defined in terms of the required level of detail, the size of the enterprise, timelines, and the architecture domains to be developed. During the scoping process, constraints must be identified, and measures of dealing with them must be put forward. It is critical to scope the Enterprise Architecture development effort accurately as this forms the basis of decision making around resource allocation and managing expectations.
Requirements engineering is a central part of developing an architecture that will ultimately align business and IT while delivering tangible value to stakeholders. Enterprise Architecture facilitates the process of requirements engineering through analyzing business processes, business cases, business drivers, capabilities, goals, and stakeholder modelling.
Identify the stakeholders and their concerns. Naturally, stakeholders will be interested in the fulfillment of business requirements that affect them directly.
TOGAF recommends the use of “business scenarios” to discover and document business requirements. The business scenario process has seven steps that can be performed iteratively to identify and analyze business needs. These business needs are used to produce business requirements that must be addressed by the Enterprise Architecture. Business requirements should be prioritized and regularly monitored. All changes to business requirements must be recorded, versioned, and audited.
Always strive to focus on the most critical and doable deliverables. The business requirements from the business scenario exercise can be prioritized according to how closely linked they are to the enterprise’s strategic goals. You can also target processes that are performing inefficiently and must be optimized to address a critical business requirement. The business scenario approach also ensures that the business requirements being addressed are indeed of interest or concern to the relevant stakeholders.
Managing stakeholders is crucial to the success of Enterprise Architecture development. Architects must engage with a wide range of stakeholders (executives, implementation team, line managers) early on to gather information about how to best engage them with the appropriate level of diplomacy and cultural sensitivity. As mentioned in earlier sections of this chapter, views and viewpoints will play a critical role in providing tailored views of the architectures to keep the relevant stakeholders informed. Having open communications with stakeholders will make them feel a part of the process and facilitates any contributions they may have.
A Stakeholder Matrix
Influence | Support | Understanding of EA Purpose | Contribution | |
|---|---|---|---|---|
Chief Executive Officer | High | Medium | High | High |
Chief Financial Officer | High | Medium | Low | Medium |
IT Manager | Medium | High | High | High |
HR Manager | Low | Low | Low | Medium |
IT Service Provider (External) | Low | High | High | Medium |
Chief Auditor | Medium | Low | Low | Low |
The shareholder matrix depicted in Table 3-1 identifies key stakeholders and where they stand in terms of their influence, support, understanding of the purpose of EA, and their contribution to it. This provides insight that is valuable to identifying the best way to navigate the EA endeavor.
The output of this phase is an approved Statement of Architecture Work. It details what architecture domains are to be developed and to what level of detail. A road map that includes a schedule and the required resources to complete the Enterprise Architecture development effort is included alongside a baseline architecture. A baseline architecture depicts where the enterprise is currently and provides context to the level of effort, resources, and time required to transition to a future desired state. The Statement of Architecture Work must be approved in accordance with the appropriate governance structures.
In practice, this process is not as black and white. There may be instances where this information is unavailable. This must not stop the architect from making progress. With the accumulation of information, understanding, and their own experience, the architect can make assumptions about certain aspects of the architecture at a high level. More detailed specifications can be made as the project progresses. It is very difficult for any enterprise to pull off the architecture development process in one go simply because of the rapid changes that occur in their business environments. The architecture itself must be flexible enough to accommodate change during its development to avoid being out of date by the time of its completion.
The architect must focus on the high-level aspects of the architecture vision that are closely linked to the strategic goals of the enterprise and are less likely to change due to the long-term nature of strategic goals. Lower-level aspects such as business processes that aim to deliver more immediate results must be adaptable. This is the benefit of the standardization enabled by an established framework. It is possible to change aspects of the architecture on a modular level that does not disrupt the entire architecture. Architecture is a continual process rather than an event. Implement a cycle of updating and regularly reviewing architectures; adapt them accordingly.
- 1.
Clear lines of communication and reliable communication tools.
- 2.
Invite participation in the process by all stakeholders.
- 3.
Agree upon a methodology and applicable standards to govern the process.
- 4.
Secure the support of senior management.
- 5.
Reliable means of documenting information within and across architecture domains and business functions.
- 6.
Avoid overscoping the project, prioritize the problems to be solved, and aim to start delivering results within six months.
- 7.
It’s a team effort. It is impossible for a single architect to articulate the architecture at all levels because it encompasses a wide array of disciplines.
An Enterprise Architecture vision ultimately determines how an enterprise views the technology that supports its business operations in meeting its business requirements and ultimately achieving the enterprise’s strategic goals. Upon gaining an understanding of the framework and the architecture vision, the last and arguably the most important factor are the stakeholders.
The People
The architecture vision is essentially about deciding what to do and how much time there is to do it. The next step is selecting and organizing the people to do it on schedule. The development team should consist of up to six members headed by the chief architect. The chief architect must be a strong leader with a combination of good technical and soft skills. The development team is the focal point in connecting business and IT and so must include individuals with a strong grasp on both areas. Enterprise architects must generally have multiple skillsets as their work deals with the enterprise as a whole.
The architecture team should include system architects and functional experts in the areas within the scope of the architecture that provide specialized knowledge. The functional experts will divide their time between their daily duties and the enterprise development effort. System architects will collaborate with the functional experts and other stakeholders to develop the business requirements that they must translate into a coherent vision of what the system should do. In the case of packaged applications such as SAP, this may mean selecting the solution that most closely meets the business requirements. Furthermore, the system architects must establish how the systems will evolve and stay abreast of the latest technologies that could facilitate that evolution.
All of this will be overseen by steering committees, review boards, quality assurance teams, and conflict resolution bodies. Architecture steering committees are made up of chief architects, domain experts, and line managers. They ensure that the Enterprise Architecture development process remains on time and on budget. Steering committees assess progress and enforce corrective measures in case of any issues.
As much as there is a dedicated architecture development team, remember to invite stakeholder participation. Architecting must be an open process that stakeholders can make contributions to and ultimately facilitate buy-in. Stakeholders must be involved in the creation of deliverables, circulating drafts for review and feedback.
A hierarchy flowchart begins with chief information officer followed by the architecture team, solution delivery team and external stakeholders from top to bottom.
Stakeholder hierarchy
- 1.
Business Architecture
- 2.
Data Architecture
- 3.
Application Architecture
- 4.
Technology Architecture
The Architecture
Information about an enterprise’s environment is best captured by architectures or architectural views. An architecture organizes complex information in layers that are easier to understand and communicate. The common way of depicting these layers is as the business, data, applications, and infrastructure architectures. Consequently, architectures cut across domains and allow them to be seen in one view of the enterprise.
Architectures can be defined on a strategic or tactical-based level with each level becoming more focused and detailed than the last. The process of Enterprise Architecture development utilizes the concepts of a baseline architecture, a target architecture, and transitional architectures (optional).
Baseline Architecture
Developing a baseline architecture or as-is architecture is about defining the current architectural makeup of the enterprise. Some enterprises assume they do not have an architecture because they do not have a documented architecture. This is a common misconception. As long as there is some kind of information system in your enterprise, you have an architecture.
What information systems is the enterprise using now? This is our point of departure.
These information systems do not have to be enterprise-wide. As defined in Chapter 1, section “What Is an Enterprise?”, an enterprise is people collaborating together for a purpose, supported by a platform. This means that the information system could be only serving the warehouse and procurement department but still be documented as an Enterprise Architecture.
The baseline architecture takes stock of what information systems are being used within the enterprise, their components, and the relationships between them. The baseline architecture allows you to analyze them in order to deduce their business value to the organization and the cost of running them, identify redundancies and potential for growth or replacement, and map out which users are utilizing them.
Make sure to avoid going into too much detail and describe only the critical functionality/processes of the systems that you anticipate will need replacing. Legacy systems that will not be replaced must be documented thoroughly to clearly understand how to ensure their interoperability with new systems. An architect should not spend too much time modelling baseline architectures as this is an iterative process; you will come back to them with new information based on the development process of your target architecture. Capture enough information to support your first iteration of the target architecture.
The Target Architecture
The target architecture is a description of the desired future state of the enterprise. It details the systems that the enterprise would like to implement to support business operations. Similar to the baseline architecture, the target architecture includes their interoperability, their purpose, and potential business value. The systems the enterprise would like to implement are generally improvements from the baseline architecture; there is hardly an enterprise that intends to maintain business as usual five years into the future. Consistency is important so make sure to use the same views used in the baseline architecture.
The target architecture takes future business needs into account. It should be a reflection of how the enterprise intends to evolve mainly in terms of its business architecture. The business architecture is therefore the main driver of the target architecture, whereas the baseline architecture was purely about documenting what already exists. An example of the business architecture driving the development of a target architecture is that of a traditional brick-and-mortar grocery store chain planning on introducing an end-to-end ecommerce platform in the next three to five years. This evolution in their business model will dictate the kind of technological transition they must undergo, and the target architecture will depict this.
The applications and infrastructure architectures may also drive the target architecture. For example, an enterprise may still be utilizing a legacy system or on-premise solutions but have come to realize that they may get more value out of cloud-based heterogenous solutions. Technology begins to drive the target architecture because system integration and meeting interoperability standards become critical to achieving that vision.
It is important that both the baseline architecture and target architecture development processes are iterative. This is because you are continually gathering new information and requirements are bound to change, business requirements in particular. Make sure to not get caught up in having the architecture set in stone; just make sure to gather everything relevant to the current iteration.
A target architecture is not purely an upgrade of the baseline architecture. It may be an architecture totally different to the baseline architecture; it is only seen through the same views that were used to develop the baseline architecture. The resulting document should be adequate for the planning and implementation of future systems.
Are there new products the enterprise plans on introducing?
Are there new business units dedicated to these products?
Are the functions depicted in the target architecture sufficient to support them?
What data/information is required to support them?
Are existing information systems capable of supporting them?
Answers to these questions may change over time to ensure that the target architecture is adaptable. The target architecture should be in conformance to the standards and principles stated in the architectural framework. Some mistakes to avoid are insufficient analysis of business requirements and undermining the importance of stakeholder input. It should be clear that the poor analysis of existing business requirements will lead to not knowing what processes to preserve from the baseline architecture and what new processes to introduce into the architecture. Enterprises have multiple stakeholders that generally have conflicting interests. Do everything you can to gain total consensus like inviting stakeholders’ input and representing the architecture in ways that all stakeholders can understand.
Transitional Architectures
Transitional architectures are an “in-between” state representing necessary transitional checkpoints in the transformational period from the baseline architecture to the target architecture. These transitional architectures must be developed with the same effort as the target architecture itself as they would have been deemed necessary for its realization. The transitions include thoroughly planned changes that involve existing and new business processes, data models, applications, and infrastructure.
We shall now look at the domain architectures. Please note that the fundamental output of all domain architectures is a baseline architecture and a target architecture.
Business Architecture
We have already spoken about the importance of business drivers under the section on architecture vision, so it should be clear that the Business Architecture is the foundation of a successful Enterprise Architecture. The business architecture encompasses why the business exists and what it does to fulfill that “why.” It describes the business objectives, strategy, capabilities, and processes that must be adopted in order to achieve the target architecture. All the other architectures must understand and use the business architecture as a reference point for the end goals of architecture development. They all must enable the achievement of business value.
Furthermore, the business architecture should help executives and business leaders understand how the architecture addresses the strategic objectives. The business architecture is in essence a translation of the enterprise’s mission, vision, business drivers, and strategic goals. It represents the business capabilities in the context of the enterprise’s architecture. It details how the business operates in the baseline architecture and how the business needs to operate to achieve its target architecture, therefore facilitating a gap analysis.
We have already learned that IT and business alignment is fundamentally about incorporating the right technologies to best support the business capabilities and deliver business value. It is because of this that the business architecture is the focal point of IT and business alignment. The business architecture must be as accurate as possible in order to inform the decisions of the most suitable technologies required to meet business requirements. This ultimately forms the road map between the as-is and to-be states of the enterprise.
The business architecture describes who requires information and where information is required to meet business requirements. The business architecture may be further segregated into business functions such as finance, HR, or procurement to inform architects about where information systems should be located to best support them. An alternative approach would be to characterize the enterprise in terms of the products/services it delivers. This can then be elaborated upon in terms of the business processes that produce them, the stakeholders that receive and produce them, and the business units responsible for them.
Strategic plan – Strategic plans speak to the desired future of the enterprise and are essentially the basis of the direction that the enterprise seeks to go in.
Mission and vision – These are almost guaranteed to exist, and they provide a succinct description of an organization’s area of business and its goals.
Business objectives – Business objectives or goals break down the strategy into specific terms that can be linked to the business value of the architecture. If the architecture speaks to achieving the goals, then it is easier to communicate it to the enterprise.
Business processes – Business processes are a detailed description of how an organization goes about delivering its products and services. The supporting technology must be aligned with these business processes and facilitate their execution.
The main outputs of this process are the target business architecture, baseline business architecture, gap analysis results, technical requirements, and up-to-date business requirements. Remember that formal stakeholder reviews form an integral part of developing the business architecture as ultimately the same stakeholders will have to be convinced that the architecture speaks to their concerns. The business capabilities in the business architecture create and utilize data during transactions. The data architecture supports the business capabilities of the enterprise.
Data Architecture
The aim is to describe the important types and sources of data required to support the business, in a way that is accurate, consistent, and understandable to stakeholders. It describes the information flows and business process information to support business operations. It also describes the logical relationships and dependencies among business processes. It details how the placement and distribution of information supports users and IT applications.
It is important to note that this process is not about database design though links can be made to existing storage at the architect’s discretion. Data is produced, utilized, and discarded across all domains. The flow of information fuels the business architecture, and as a result, it must be accurate, useful, and secure. Knowing which business functions leverage information, which applications serve as the master record and how the information is stored and manipulated, is integral to seeing the business processes achieve enterprise goals. A gap analysis will also take part here in regard to determining the data that the enterprise will need to carry out their target business processes.
Data in the wrong location.
Irrelevant data.
Data not available when required.
Data doesn’t exist.
Data relationship gaps.
The data architecture is described by several elements.
Conceptual Data Model
This is a diagram that describes the critical data within an information system and the context in which it is deemed critical (consumers or processes that require it). The conceptual model can be produced at a business function level or across enterprises in special cases such as when an enterprise seeks to depict the flow of information in its supply chain. The diagram depicts data entities and how they relate to each other.
Logical Data Model
A logical data model depicts the makeup of data elements and how they relate to each other. The model is independent of any technology platform or specific Relational Database Management System. It does not detail how the data will be implemented, that is the physical data model. The logical data model adds more information to the conceptual model and details what data is used. It details the information that is critical to the operation of the enterprise on a day-to-day basis.
- 1.
Entities – Each entity represents a set of items relevant to a business.
- 2.
Relationships – Associations between entities.
- 3.
Attributes – Attributes describe entities.
Given that entities describe items that are relevant to a business and relationships describe how they’re associated within the context of the business, the logical data model creates a connection between business requirements and quality data structure.
Physical Data Model
Physical data models are not a must, but they may offer a useful starting point for the data architect. The data architect can use these models to deduce the logical data models and, consequently, the conceptual data models for baseline architectures. Even in scenarios when the information models were developed from the conceptual data model initially, going from the physical data model back up to the conceptual data model can be a means of double-checking the validity of the models.
Validated data principles
Gap analysis results
Impact analysis (areas where the Business Architecture may need to adapt to accommodate the Data Architecture)
It is important to note the importance of a robust data architecture in regard to maintaining data standards. Data is often exchanged with parties outside of the organization; standards that codify the way that data should be represented and transmitted between interested parties should be enforced.
Applications are required to enter, manage, and manipulate the data required by the business capabilities. The application architecture supports these processes.
Application Architecture
The next step is to assess the current IT applications that support the business functions. This includes documenting the data entities they utilize. The Application Architecture catalogs the applications in the enterprise describing the work that they do to capture, transform, manage, and store data. Again, this is not an exercise of application systems design but rather a high-level description (not a specification) of the applications showing logical dependencies and relationships among functional areas. The objective here is to attain an understanding of the applications critical to the enterprise’s business processes and what those applications have to do to manage data and to present information to the stakeholders and computer actors in the enterprise.
The applications manage the data objects in the Data Architecture and support the business functions in the Business Architecture. The data architecture details the scope of the applications, application user groups, the applications’ associations with data, and how the applications are physically distributed in different locations.
The applications are not associated with any specific technologies or service providers. What is of importance here is what the applications do to facilitate and support business operations.
The application architecture also speaks to the interfaces that are required by the applications and their interoperability. An application architect will be able to take this information and use it to develop a road map toward a target architecture. The level of detail to be defined will depend on the extent to which existing application components are likely to be carried over into the Target application architecture and on whether existing architectural descriptions exist.
The applications architecture is described by several elements.
Application Lists
This is essentially a list of applications utilized within the enterprise based on a set criteria such as being the applications in the baseline architecture. The criteria can be anything that allows stakeholders to better understand the architecture such as an application list based on functional areas that the applications are used in.
Application Diagrams
These are representations of the applications within the enterprise and how they relate to each other. A common example is an application communication diagram that depicts models and mappings related to communication between applications (e.g., application components and interfaces between components).
Application Matrices
The purpose of application matrices is to depict the relationship between applications and capabilities, the business roles and the business processes that utilize them within the enterprise. For instance, defining the applications used by a particular business role or process allows you to analyze the value of that application and whether it needs to be upgraded, replaced, or leveraged differently.
Interface Lists
Similar to the benefit of application communication diagrams, interface lists show the complexity of enterprises and how their applications are connected by depicting the number and types of interfaces between them. In the case of the baseline architecture, interface lists reveal why systems are failing when the connectedness of the applications produces a “Spaghetti diagram.”
Business Processes and Applications
Applications exist for the reason of supporting business processes. Documenting the baseline architecture of how current applications support the current business processes forms the foundation of a gap analysis that will inform the effort required to achieve a target architecture. This is ideal for the identification of redundancy, duplication, and inefficiencies that may not be immediately apparent due to years of the enterprise introducing new applications and business processes to dynamically adapt to changes in its business environment.
Validated application principles
Gap analysis results
Applications architecture report
Infrastructure Architecture
The infrastructure (or technology) architecture is the foundation of the other architectures through providing supporting services, computing platforms, and the interfaces (interoperability) the applications need to run. The infrastructure includes descriptions of the logical, physical, and virtual infrastructure that supports the execution of application services. It is important to articulate how infrastructure meets business requirements as this is not immediately apparent to nontechnical stakeholders.
The infrastructure architecture considers the relationships between technology components (software and hardware) at a detailed level to develop what TOGAF terms as Application Platform Services. These are services that are provided to applications in a standard and repeatable way, resulting in the benefits of availability, assurance, usability, and adaptability. TOGAF’s Technical Reference Model (TRM) facilitates the establishment of Application Platform Services by providing a reference of platform services.
The TRM contains architectural building blocks that create the platform for business and infrastructure applications that will provide the application and infrastructure services. Utilizing the TRM will ensure that architectures will be developed using a standard set of elements that allow for repeated and therefore standardized use. TRM allows for any type of technology, physical or virtual, to be modelled. Once the TRM is defined within the context of your enterprise, it can eventually be used as the basis for all Infrastructure Architecture models by creating instances of the infrastructure elements.
The information required for the infrastructure comes from surveying the networking infrastructure and topology, software, hardware, and telecommunications that support the systems in use. Assess the strengths and weaknesses of these components and the potential for automation. The scope of this exercise will depend on the size of the enterprise, but as a rule of thumb, identify and detail the components that support systems that execute applications for each functional area. To plan the transition of a system, you need to know the resources it requires.
Lastly, an enterprise will most likely run at multiple locations. These locations will probably be modelled within the context of the business activities that take place at those locations. In the same way, these locations also need to be articulated according to what data is located at those locations and subsequently the infrastructure required to support the collection of that data. Factors such as security , bandwidth, and performance are areas that require attention. It is important to note however that with the movement toward cloud computing, a lot of these considerations are no longer applicable with the only consideration being accessibility zones.
The main output of this development process is target infrastructure architecture.
After describing the different domain architectures, take the opportunity to get stakeholders involved by conducting a survey. First, conduct the survey before sharing the architecture in order to determine if the results are consistent with the baseline architectures. Thereafter, conduct the survey to gauge the satisfaction and understanding of the target architecture among stakeholders.
Summary
This chapter explored the process of developing an Enterprise Architecture particularly according to the Architecture Development Methodology (ADM) created by The Open Group Architecture Framework (TOGAF). The process starts off with the selection of a framework that you have determined will adequately govern and guide the development of your Enterprise Architecture development process. Frameworks come equipped with standards, principles, and best practices that you must use as a reference point to ensure the success of your project.
Subsequently, we introduced the four architecture domains of Business Architecture, Data Architecture, Application Architecture, and Infrastructure Architecture that form an efficient mechanism for organizing architectural information. The accurate and consistent development of these domain architectures is critical to the entire Enterprise Architecture effort as the gap between the baseline architectures and target architectures they produce dictates the work that must be done to transition the organization toward a future state.
Enterprise Architecture is about understanding today while planning for tomorrow while adapting your plan to new information and environmental changes you experience between those two points in time.
The next phases tackle the aspect of making the architecture work (governance) and keeping the process running. They will be explored in the next chapter within the context of SAP Enterprise Architecture as SAP has specific standards and best practices for these subsequent steps.
- 1.
Enterprise Architecture setup activities will take three to six months depending on the size of the architecture team.
- 2.
You must have the full backing and sponsorship of the C-level executives.
- 3.
The chief architect must be a great leader who knows how to manage expectations and stakeholder relations.
- 4.
There must be a clear need for Enterprise Architecture and not carrying out Enterprise Architecture as a formality.
- 5.
Members of the Architecture team must be willing to impart their knowledge and understanding on to others.
- 6.
Give adequate consideration to external stakeholders as they are easy to forget and maybe almost as integral as some internal stakeholders.
- 7.
The Enterprise Architecture development process is an iterative process and should be treated as such. Do not dwell on activities for too long as you will likely be conducting them again.