Enterprise Architecture
This is a guide on enterprise architecture.
Check out Audible on Amazon and listen to the newest books!
Understanding Enterprise Architecture
Enterprise architecture is a discipline that extends far beyond what is commonly referred to as IT architecture. The term "enterprise" in this context refers to the complete organizational context, encompassing all business processes, information technology systems, and supporting infrastructure. For large organizations, the enterprise may also refer to a specific business area or division within the broader organization. Examples of enterprises include government departments, entire organizations, or even collections of organizations operating under a single ownership structure.
Depending on the specific circumstances and organizational boundaries, the enterprise may also encompass partners, suppliers, customers, and various other stakeholders who interact with or contribute to the organization's operations. This broad perspective is essential because it recognizes that modern organizations do not operate in isolation but rather within complex ecosystems of interconnected relationships and dependencies.
A business strategy for an enterprise is developed by examining future conditions and determining how the business should operate at some defined point in the future. When such a strategy is executed, the entire business must be aligned and prepared to operate in accordance with that vision when the appropriate time arrives. This alignment encompasses all areas of the business, from front-line operations to back-office support functions.
The fundamental purpose of enterprise architecture is to align and integrate all business processes to support the organization's business strategy. While enterprise architecture is most commonly applied on the IT side to ensure that all IT components are prepared to support business objectives, it also includes any manual processes that may be present within the organization. It is critically important to understand that enterprise architecture is not exclusively an IT function. Indeed, enterprise architecture can be effectively employed for comprehensive business transformation initiatives that extend well beyond technology considerations.
The Value and Challenges of Enterprise Architecture
It is important to acknowledge that realizing a return on investment from enterprise architecture can take years to materialize. However, when implemented properly, enterprise architecture can easily become the determining factor between a thriving business and one that ceases to operate successfully. While it may be relatively easy to recognize the advantages of having professionals examine the IT infrastructure broadly and identify opportunities for streamlining and cost reduction, other advantages extend to similar improvements on the business side.
Both business and IT functions can benefit from reduced complexity and maximized investments in technology through effective enterprise architecture practices. Senior management support is absolutely essential when establishing an enterprise architecture practice within any organization. If the Chief Executive Officer and Chief Information Officer are not supportive of the initiative, it becomes extremely difficult to build a successful practice and to balance business innovation and change with IT efficiency and process automation.
The reality is that the business will change as much as IT will through enterprise architecture initiatives. Enterprise architecture does not always sit within the IT department; it can be controlled from the business side rather than from IT. Even when enterprise architecture resides within a business unit, it is essential to remember that enterprise architects need to possess an appropriately high level of IT knowledge and expertise in order to perform their roles effectively.
The Role of Architecture Frameworks
A framework is a structure designed to support or enclose something else. In the context of enterprise architecture, this something else is the business or enterprise that is engaged in the architecture initiative. Such a structure makes it easier to think about the business in a systematic and organized manner. Indeed, a framework can be described as a way of looking at reality, or at least the reality of a specific business or enterprise.
This structured approach offers numerous advantages that virtually all businesses and enterprises can benefit from. It provides standards in terms of approach, terminology, and methods that make it easier to share information and collaborate with others. In terms of architecture frameworks, TOGAF, which stands for The Open Group Architecture Framework, was developed through a large collaborative effort involving hundreds of companies and corporations. As a result, although there are theoretical portions within the framework, the bulk of this framework is highly practical and has been refined for the largest enterprises in the world.
Following such a framework makes it easier for an enterprise to acquire resources who are familiar with the framework from any prior architectural work and methods used. This familiarity fulfills the requirements of the many stakeholders involved while promoting best practices across the organization.
The framework examines both the current state of the enterprise and the future state, as well as how to transition from one to the other. There are, of course, other architectural frameworks available for this kind of work, such as NIST, which stands for the National Institute of Standards and Technology, which are described in terms of interrelationships, and others as well. This is simply to point out that there are a number of ways to establish an enterprise architecture practice according to a set of standards and practices, yet these alternatives are not frameworks in the same comprehensive sense as TOGAF.
If an organization is beginning enterprise architecture practice in its very early stages, it may be worth examining how different groups approach enterprise architecture and which approach may work best within the specific enterprise, as no two enterprises are truly identical.
Building a new enterprise architecture practice is a highly complicated endeavor that will touch on many processes and stakeholders. TOGAF is designed to standardize these interactions and reduce the risk associated with producing organizational architectures. The results can be very economical while still fulfilling the business requirements. With TOGAF supporting an enterprise architecture group, literal business transformation can result, with the entire enterprise working towards the business vision. If required, TOGAF can also be applied to processes that span multiple organizations.
The assurance that TOGAF brings through its framework centers around enabling open or flow systems. This relates to a part of system theory concerning systems exchanging information with each other and mitigating any and all risk factors that may arise. The framework provides the tools to accomplish this. This represents the essence of the architecture framework around TOGAF.
The Open Group and the Development of TOGAF
The Open Group is a global consortium that enables the achievement of business objectives through IT standards. The organization has hundreds of member organizations that contribute to the consortium and its standards, specifically TOGAF. Boundaryless Information Flow is how this vision is often referred to. Briefly stated, it means having the ability to deliver the required information in an understandable way to the correct people and across systems in a timely and secure manner.
TOGAF itself was first developed in 1995 and was initially based on research conducted by the Department of Defense and the United States government. After spending millions of dollars and years of research, the Department of Defense gave explicit permission to The Open Group to use what is called TAFIM, or the Technical Architecture Framework for Information Management, as a starting point for TOGAF. Since that time, The Open Group has been very successful in furthering TOGAF, and it is now in its ninth version, specifically major version 9.1 at the time of this writing. The Open Group's Architecture Forum is the place where changes to the standard are discussed and revised.
Components of TOGAF
Aside from some introductory components, TOGAF is largely made up of the Architecture Development Method, often referred to as the ADM, including guidelines and techniques. These describe how to actually produce the various architectural components required to have an enterprise architecture. It is a method in that there is an order to follow. The architectural components should be developed in a specific order for best results or expected best results. The guidelines and techniques provide further information around the practical application of the ADM. These represent the refinements and suggestions from Architecture Forum members over decades of experience in doing enterprise architecture.
In addition, there is an Architectural Content Framework, which describes a structure for storing all architectural documents and other outputs from the ADM. Perhaps the most important outputs are the reusable architectural components. Then there is the Enterprise Continuum and Tools section, which describes the categorization and storage of the outputs. The TOGAF Reference Models, including TOGAF's Foundation Architecture and the Integrated Information Infrastructure Reference Model, form part of the foundation for creating an enterprise architecture practice, even if neither model is used directly.
Finally, there is the Architectural Capability Framework, which centers around building up and maintaining enterprise architectural practice. This includes information around the relevant skill sets and business processes required to operate, among other things. TOGAF is a large standard and framework, and it is difficult to understand and apply the framework without it being split apart into components. It is important to note that the intention is for TOGAF to be considered and applied as a whole framework. The splitting apart is merely for describing different pieces in isolation. It is best to apply the framework holistically at first. While it is possible to use pieces of TOGAF separately and successfully, the full value of TOGAF is only realized when the full framework is applied.
Architecture Types and Domains
Within each domain, architecture documentation and analysis can occur at a variety of levels. For example, a high-level data architecture diagram may discuss financial data as a single entity. A mid-level document may break this down by financial module, such as accounts payable, fixed assets, or something similar. A lower-level document may represent only a single module itself, such as payroll distribution, general ledger transactions, or employee master file audit trail.
Regardless of the level of documentation, the domain itself is considered primary. Thus, data architecture would include all of the above examples but would not include a diagram showing how the corporate wide area network in its current state links various sites, even though this indirectly shows how some of the data may be accessed.
The business architecture domain starts with a vision statement or document as its input. It deals primarily with the business organizational structures, including processes. However, it also includes governance around those structures and processes. While business strategy is usually defined in a vision statement or similar document, there is a certain refinement and description that will happen within this domain.
The data architecture domain includes information architecture. Although TOGAF uses data architecture in its nomenclature, there are also times when information architecture is used interchangeably. The data architecture includes all information and data assets, whether logical or otherwise. A data asset is any piece or collection of information that may have future value to the business. It is important to keep in mind that this fits into the business architecture, which defines how the business operates. Data architecture defines the data required so that the business can operate in that way. Additionally, it includes any data management assets and resources.
The application architecture domain looks at the different architectures and provides the applications to support the collection and use of the required data. This includes supporting the business workflows and other capabilities, such as various data interactions including relationships. The application architecture domain also examines individual applications and how they relate in order to provide a complete business solution for the required data and business processes.
The technology architecture domain looks more at the required technology infrastructure to support the applications and back-end data in order to provide the business with the ability to operate as desired. This infrastructure most often includes servers, both hardware and software, networks, communications systems such as local area networks and wide area networks, and similar components. It can also include other elements such as middleware if required. Standardizing the infrastructure architecture is less of a primary concern in this domain.
While there is a great deal of interaction between the different domains, there is much that is found wholly within each. Generally, the flow of architecture follows the order in which the domains are represented. Decisions or standards made at a lower level can impact the upper levels in various ways. For example, if the technology architecture decides that Windows will be the standard server operating system, what happens when the application architecture requires an application that only works on Linux? This is how these components can help address such situations. This provides a broad overview of the TOGAF architectural domains.
The Architecture Development Method
The Architecture Development Method of TOGAF is its core. All of these phases or activities are performed iteratively in a cycle as enterprise architectures are defined and implemented. As the business continually changes, the architecture will need to change with it. Whenever the business strategy or vision statement document changes, this should signal a need to examine what must change within the architectures. Even when the business continues with the same strategy, the application and technology architectures should be reviewed periodically in order to keep pace with new releases of hardware and software and other changing conditions.
The preliminary phase is around setting up enterprise architecture practices and capability. There should be some principles established, but not too many. Attempting to keep the number of principles under ten is advisable. If TOGAF will not be used as it is, then any changes need to be fully defined and agreed upon by stakeholders. While it may be tempting to consider this complete when it is done, periodically this should be reviewed and the capability changed if required. As the business changes, the principles and processes may need to change with it, and the rest of the phases will depend upon this phase.
Phase A is the Architecture Vision. For each architecture developed, it is like launching a project with a project management office or similar entity. The relevant stakeholders must be identified and the appropriate scope agreed upon. Similar to a project charter, an Architecture Vision is created and approved before proceeding with any architectural work.
Phase B is where the Business Architecture is developed based upon that vision. Phase C is where the Information Systems Architecture is developed based on the vision and the Business Architecture. This includes both the data and application architecture domains. Phase D is where the Technology Architecture is developed based on the vision and the business and information system architectures.
Phase E is where the opportunities and solutions are examined. This can be considered implementation planning or, if the vision is extensive, implementation architecture. Phase F is where migration planning is developed. This is the plan for how to move from the current state architecture to the final state architecture. There can be additional intermediate architectures as well, so Phase F should not be considered a single monolithic activity.
Phase G is where implementation governance is performed. This important phase allows the architects to ensure that the transition to the final state architecture is proceeding as planned. Phase H is where architecture change management is conducted. Change management for the new architecture should be established. This is the final phase in the cycle.
The requirements management phase is not truly a phase. Rather, it is something that should be done as required during all of the other phases. As an architecture is developed, various requirements will present themselves and need to be managed to ensure that the result will meet the business need. Often, an enterprise architecture practice will have a number of individuals looking at this at all times.
Outputs of the Architecture Development Method
When using the Architecture Development Method, there will be a variety of outputs including deliverables, artifacts, and building blocks. A deliverable is something required at the end of the project or architectural development. Usually this is the focus of the project. As such, it may have many formal processes around it, such as sign-off and agreement. A documentation deliverable may or may not be valuable after the project is complete. Sometimes the documentation itself may be a product, or perhaps it only had worth during the project. In that case, it can be archived or made part of the project's record. Other examples of a documentation deliverable include a reference model or a standard. When doing something for the first time, this is typical. Subsequent projects can take advantage of this or make use of this. There could be many such deliverables and potentially save substantial time when developing future architectures.
An artifact is a document related to the architecture itself. This can be a list or catalog of items or centered around relationships between items, such as a diagram, metrics, or something more complex like a more elaborate graphical representation. Each deliverable will likely have a number of artifacts either within it or related to it. This becomes like its own ecosystem.
A building block is a reusable artifact or a group of artifacts. The key thing is that each building block can be combined with others in order to build new architectures or solutions. The name is very fitting. An Architecture Building Block involves multiple solution building blocks, and these usually cross architectural domains such as business processes, information data, or applications. The purpose is to better describe a business capability.
A Solution Building Block is used when implementing a capability rather than just describing it. For example, a building block may be the data entry clerks within a payroll department. This would be an example of a Solution Building Block. If an architecture was being developed to change from a paper-based time sheet system to an electronic one, this Solution Building Block may show in the current state as performing data entry from paper into the system. In the future state architecture, these clerks may not appear at all, having been replaced by another Solution Building Block representing managers within the organization. Alternatively, they may appear in another architectural deliverable around centralizing the data entry business function into a separate service and capability. This piece could represent either another Solution Building Block, which could be used in an Architectural Building Block around the system conversion requiring some data entry, or a standalone component. These are effectively the core outputs for TOGAF under the Architecture Development Method.
Architecture Repository and Enterprise Continuum
In TOGAF, the Enterprise Continuum refers to how artifacts can be reused from the most generic foundations through to something that has been fully customized to the organization. It examines all repositories, including configuration management databases, requirements, and others. It does this within the enterprise and not just archival sources as resources to be used within the Enterprise Continuum. In return, it helps to classify and structure the assets within those repositories.
Conceptually, there is an Enterprise Continuum and a Solutions Continuum which together provide a breakdown of the Enterprise Continuum. For any architecture being developed, there will be some context and requirements. This involves the architecture vision and stakeholders along with the strategies involved. This guides the architecture across its own continuum, referred to as the architectural continuum. For any specific architecture developed for a specific need, a more generalized architecture can also be developed for the purpose of reuse.
Once some generalized architectures exist and are validated, when a new specific architecture is being developed, these generic architectures can be adapted to the specific need instead of starting over each time, which can save an enormous amount of time. In this concept, reuse within the Enterprise Continuum is critical to being efficient when developing architectures.
Still within the Enterprise Continuum, when going from architectures to solutions or the Solutions Continuum, the same concept can apply. Specific solution designs can be generalized and stored for future use. Then, when developing a new solution, these generic designs can be reused in order to save both time and achieve a higher quality product output. Over time, these generic designs will go through changes and become the result of many solutions having used them.
Going outside of these artifacts will increase risk. Once the solution is deployed, its artifacts and deliverables will become part of the architectural context and the architectural repository. Both feed into the Enterprise Continuum. A full loop is effectively created. The architectural repository will become the major input to the Enterprise Continuum and output storage. Realistically, this is the main purpose. The categorization offered by the Enterprise Continuum makes it easier to find relevant artifacts in a timely manner.
Everything created by the Architecture Development Method will be stored in the repository. This is a large number of artifacts and the repository should be large. The Enterprise Continuum or meta model aligns with the ADM as well. Thus, the process of creating the artifacts is represented within the repository. The architectural repository is for future reference to existing architectures, to develop generic architectures based on them, and to define the suitable ones for reuse. Since all the artifacts are collected, there will be many at varying levels of understanding in architecture. Assuming this is done well, there will be a set of documents describing the same thing for a vast set of different audiences, including stakeholders, other architects, practitioners, and similar groups.
The main components of the architecture repository include the architectural meta model, architectural capability, mosaic governance, and architectural landscape. These represent the asset architecture at various levels. The Standards Information Base contains the standards that are being enforced. Reference libraries contain templates and patterns. Governance logs contain the governance activity record. These are all key components. This provides a comprehensive overview of how solutions are generalized and moved to more specialized solutions with TOGAF.
Enterprise Architecture Capability
There is a great deal of work that enterprise architects perform. If they are spread out across the organization, they will never have the true enterprise perspective. Their view will be constrained within whichever business unit they are in, and collaboration between such people in different business units will be very limited. However, within a single business unit reporting to a Vice President or C-level executive at minimum, the enterprise architecture business unit will have the true enterprise perspective and good collaboration between the architects. This business unit will become responsible for the architectural repository, providing solution designs, and working on the project portfolio or perhaps a specific project or set of projects for the organization.
In enterprise architecture, it is important to find the required knowledge and skills for the people who will be in the business unit. For example, they must have systems thinking, which is the ability to see the big picture. They are usually very senior people within the organization or within the business domain in which they were operating previously or will be operating. They must have superb interpersonal, leadership, and communication skills in order to deal appropriately with the vast variety of people with whom they will meet and collaborate. The ability to explain complex technical concepts so that people without a technical background can fully understand and appreciate them is an essential skill.
There are many other things to consider, such as project management experience, financial modeling, operations, time management, customer service, and similar capabilities. As an independent business unit, the enterprise architecture function will have its own leader, whether a manager, director, or whatever title may be chosen. This unit will implement any standard business process required, such as human resources payroll processes so that employees get paid, performance management, or resource management processes. With any business unit, there are usually some financial responsibilities along with managing the physical office environment.
In addition, there will be some processes that become more customized for enterprise architecture. For example, dealing with stakeholders, while common to all business units, takes on new life due to the wide breadth of stakeholders and an enterprise-wide endeavor. Enterprise architecture will need to send out organizational-wide communications which receive more scrutiny than most. There will also be the need to have management or work processes involved with doing enterprise architecture. More importantly, there needs to be management of the actual work being done. Broadly speaking, this is called governance.
Governance in this context means that all architecture that should be done by enterprise architects will be brought to them so that it can be done properly. It will not be done by someone else, somewhere else in the organization. This provides for consistency in the architect outputs and maximizes the reuse of artifacts within each area, which will be organization-wide. Architectural risk management can now happen in a single place and also be communicated out from that place. While more decisions will take place at higher levels within the organization when strategically important, this will ultimately save time and effort since solutions will be deployed using standardized architectures instead of reacting after the fact. An enterprise architecture practice will proactively drive initiatives forward under a business transformation methodology. This provides a broad overview of how enterprise architecture is viewed from a capability perspective.
Summary of Key Concepts
Enterprise architecture encompasses the complete organizational context, including all business processes, information technology, infrastructure, and external stakeholders such as partners, suppliers, and customers. Its primary purpose is to align and integrate all business processes to support the organization's business strategy, and it is not exclusively an IT function but can be used for comprehensive business transformation.
Architecture frameworks such as TOGAF provide structure, standards, and methodologies that make it easier to think about and manage the business, offering practical guidance developed through collaborative efforts involving hundreds of organizations. These frameworks examine both current and future states of the enterprise and provide the means to transition between them.
The Open Group is a global consortium that developed and maintains TOGAF, with its vision of Boundaryless Information Flow enabling the delivery of required information in an understandable way to the correct people across systems in a timely and secure manner.
TOGAF is composed of the Architecture Development Method, guidelines and techniques, the Architectural Content Framework, the Enterprise Continuum and Tools section, TOGAF Reference Models, and the Architectural Capability Framework, all of which should be applied holistically for maximum benefit.
The Architecture Development Method consists of phases including the preliminary phase, Architecture Vision, Business Architecture, Information Systems Architecture, Technology Architecture, Opportunities and Solutions, Migration Planning, Implementation Governance, and Architecture Change Management, with Requirements Management occurring throughout all phases.
Outputs of the Architecture Development Method include deliverables, artifacts, and building blocks, with Architecture Building Blocks and Solution Building Blocks serving as reusable components that can be combined to build new architectures and solutions.
The Enterprise Continuum and Architecture Repository provide mechanisms for categorizing, storing, and reusing architectural artifacts, enabling organizations to leverage generalized architectures and solutions for specific needs, thereby saving time and improving quality.
Enterprise architecture capability requires a dedicated business unit with senior professionals who possess systems thinking, interpersonal skills, communication abilities, and diverse technical and business knowledge, operating under governance structures that ensure consistency and maximize reuse across the organization.