Information Systems Architecture focuses on the design and implementation of the information systems used by an organization incorporating both data architecture and application architecture. In this article, we will delve into the intricacies of Information Systems Architecture focusing on Data. We will explore the key concepts, processes, and outputs to ensure that an organization's data assets are optimally utilized to support its strategic objectives. An Overview of TOFAF and the ADMThe Open Group Architecture Framework (TOGAF) is a widely used framework for the development of enterprise architecture. It provides a structured approach to designing, planning, implementing, and managing an organization's information systems architecture. One of the key components of TOGAF is the Architecture Development Method (ADM), which is a step-by-step process for creating an information systems architecture. The ADM is divided into several phases, and Phase C, the Information Systems Architecture phase, focuses on developing the Data and Application Architectures, which are critical components of the overall Information Systems Architecture as shown in the figure below.  Phase C: Information Systems Architectures Overall, Phase C is a critical phase in the ADM, as it focuses on developing the Data and Application Architectures that are essential components of the Information Systems Architecture. By following the structured approach provided by TOGAF, organizations can create an effective and efficient information systems architecture that supports their business goals and objectives. ObjectivesThe objectives of the Information Systems Architecture phase are to:
ApproachPhase C involves some combination of Data and Application Architecture, in either order. Major applications systems — such as those for Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), etc. — often provide a combination of technology infrastructure and business application logic. Some organizations take an application-driven approach, whereby they recognize certain key applications as forming the core underpinning of the mission-critical business processes, and take the implementation and integration of those core applications as the primary focus of their architecture effort (the integration issues often constituting a major challenge). Detailed descriptions for Phase C are given separately for each architecture domain:
In this article, we will focus on the Data Architecture and in the next article, we will focus on the Application Architecture. Data ArchitectureThe Data Architecture is a key component of Phase C, and it involves designing the organization's data structure, data management, and data storage requirements. Developing the Data Architecture in Phase C of the ADM is a critical step in creating an effective Information Systems Architecture. By following the structured approach provided by TOGAF, organizations can ensure that their Data Architecture is aligned with their business goals and objectives and supports their overall Information Systems Architecture. This section describes the Data Architecture part of Phase C. Key Considerations for Data ArchitectureLet's talk about some important things to keep in mind when it comes to data architecture. Data Management When a company is making big changes to their overall architecture, it's crucial to consider how data will be managed. A solid plan for managing data makes it easier to take advantage of the benefits that data can bring to your business. Some things to consider are:
Data Migration When you're replacing an existing application, you'll need to migrate data (like master, transactional, and reference data) to the new application. Your Data Architecture plan should identify exactly what you'll need to do to make sure your data is transformed, weeded, and cleansed to meet the needs of your new application. The goal is to have quality data in your new application from the start. It's also important to establish a common definition for data across your company to make sure everyone's on the same page. Data Governance To ensure your transformation is successful, you need to have good data governance in place. There are a few different dimensions to consider here:
If the enterprise lacks such resources and skills, the enterprise should consider either acquiring those critical skills or training existing internal resources to meet the requirements through a well-defined learning program. Objectives of the Data ArchitectureIn Phase C, the Data Architecture aims to achieve the following objectives:
Inputs to the Data ArchitectureThis section defines the inputs to Phase C (Data Architecture). Non-Architectural Inputs
Architectural Inputs
The ProcessThe level of detail required in Phase C of the Architecture Development Method (ADM) depends on the scope and objectives of the overall architecture project. When introducing new data building blocks, it is necessary to define them in detail during this phase. If existing data building blocks will be carried over to the target environment, they may have already been sufficiently defined in previous architectural work, but if not, they should also be defined in Phase C. The order and timing of the activities in Phase C should be determined based on the established Architecture Governance and the specific situation at hand. For example, it may be appropriate to prioritize either the development of a Baseline Description or a Target Architecture. The steps in Phase C (Data Architecture) are as follows:
Select Reference Models, Viewpoints, and Tools
Examples of data modeling techniques are:
Determine Overall Modeling Process To support each viewpoint, we need to choose the appropriate models using the selected tool or method. We also ned to ensure that all stakeholder concerns are addressed and, if necessary, create new models or modify existing ones. The recommended process for developing a Data Architecture includes the following steps:
Identify Required Catalogs of Data Building Blocks When we talk about data, we can organize it into different categories based on its characteristics and structure. This can be shown in a catalog that breaks down the data into related pieces (like data entity, logical data component, and physical data component). During the Business Architecture phase, we created a diagram that shows the important data entities needed by the main business services. This diagram is important because it helps us identify what data we need to support the architecture vision. By tracing the connections between business functions, capabilities, applications, and data entities, we can create an inventory of the data required for the architecture. This helps us understand what data we have and what we still need. Once we have all the data requirements in one place, we can refine the inventory to ensure consistency and eliminate any gaps or overlaps in the data. This is important because it helps us use the data more effectively in the architecture. Identify Required Matrices In this stage, it's important to identify the necessary matrices. One such matrix is the entity to applications matrix which can validate the mapping of data entities to applications. This will help in understanding how data is created, maintained, transformed, and utilized by various applications. Any gaps in the mapping, such as entities that are not created by any application or data that is created but never used, should be noted for further analysis. The rationalized data inventory that was created earlier can now be used to update and refine the architecture diagrams that show how data relates to other aspects of the architecture. Once these updates are made, it may be necessary to iterate on the Application Architecture to address any changes identified. Identify Required Diagrams When developing a Data Architecture, it's important to create diagrams that represent the information from different viewpoints based on stakeholder requirements. After refining the data entities, a diagram that shows the relationships between them and their attributes can be created. It's worth noting that the information may come from various sources, such as enterprise-level data from system service providers and package vendors, as well as local-level data stored in personal databases and spreadsheets. While creating these diagrams, it's crucial to carefully assess the level of detail needed. Some physical system data models may have a highly detailed level of modeling, while others may only include core entities. Not all data models may be up-to-date, as applications are often modified and extended over time. Therefore, it's important to strike a balance in the level of detail provided, whether it's reproducing existing detailed system physical data schemas or presenting high-level process maps and data requirements. Identify Types of Requirement to be Collected Now that we have developed the Data Architecture catalogs, matrices, and diagrams, it's time to collect the requirements for implementing the Target Architecture. These requirements may:
Develop Baseline Data Architecture Description This is all about creating a Baseline Description of the existing Data Architecture. This step is important to ensure that we have a good understanding of the current state of the Data Architecture before we move on to defining the Target Data Architecture. Here's how you can approach this step:
Develop Target Data Architecture Description To create a Target Data Architecture Description, you need to identify the data elements that are relevant to achieving the Architecture Vision and Target Business Architecture. This means figuring out what data is needed to reach the goals of the project. You should use the Architecture Repository to find building blocks of data that can be used in the new architecture. If there are any missing pieces, new architecture models can be created based on the existing ones from Step 1. You should also explore different options for the Target Architecture and talk to stakeholders about the advantages and disadvantages of each one using the Architecture Alternatives and Trade-offs technique. Perform Gap Analysis Ensure the accuracy and internal consistency of the architecture models through the following steps:
Use gap analysis techniques to identify discrepancies between the Baseline and Target architecture, and document any gaps found. Define Candidate Roadmap Components Following the creation of a Baseline Architecture, Target Architecture, and gap analysis, we need to create a data roadmap to prioritize activities over the coming phases. This initial Data Architecture roadmap will be used as the basis to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase of the TOGAF ADM. Resolve Impacts Across the Architecture Landscape After finalizing the Data Architecture, it is important to evaluate its potential impacts and implications across the broader Architecture Landscape. It is recommended to examine other architecture artifacts to determine whether the Data Architecture:
Conduct Formal Stakeholder Review Now, it's time to conduct a formal review with stakeholders. During this review, we will compare the proposed Data Architecture with the original motivations for the architecture project and the Statement of Architecture Work. This will help us identify any areas where the Business and Application Architectures may need to be adjusted to accommodate the changes in the Data Architecture. For example, we might need to update forms, procedures, applications, or database systems. If the impact on the Business and Application Architectures is significant, we may need to revisit and make adjustments to those areas. Next, we will assess if any changes are required in the Application Architecture due to the changes in the Data Architecture. If the impact is significant, we may need to have a short iteration of the Application Architecture at this point to address the necessary changes. Furthermore, we will identify any constraints on the upcoming Technology Architecture. If needed, we will refine the proposed Data Architecture to accommodate these constraints, ensuring that it aligns with the overall architecture vision. Finalize the Data Architecture
Create/Update the Architecture Definition Document Document the rationale for building block decisions in the Architecture Definition Document:
OutputsThe outputs of Phase C (Data Architecture) may include, but are not restricted to:
SummaryIn conclusion, Phase C of the ADM is a critical stage in the development of an effective enterprise architecture. During this phase, the organization's data architecture is developed to enable the achievement of the business goals and objectives defined in the previous phases. This involves identifying the current state of the organization's data architecture, defining the desired future state, and identifying the gaps between the two. By addressing these gaps, the organization can ensure that its data architecture supports the achievement of its strategic goals and objectives. In the next article, we will be covering the second component of Phase C, which is application architecture. Together with data architecture, application architecture plays a crucial role in enabling the organization to achieve its strategic goals and objectives. Therefore, it is essential that the organization takes a structured and comprehensive approach to developing both its data and application architectures during Phase C of the ADM.
0 Comments
TOGAF provides a comprehensive approach to enterprise architecture that can help organizations align their IT strategies with their business goals, improve their business processes, and increase their overall efficiency. One of the key phases in the TOGAF framework is the Business Architecture phase. This phase focuses on the development of a high-level business architecture for an organization. By understanding the organization's business strategy, goals, and stakeholders, and identifying the business functions, processes, capabilities, and information required to support them, the Business Architecture phase provides a solid foundation for the rest of the enterprise architecture process. Overview of Business ArchitectureBusiness Architecture is a comprehensive representation of various aspects of a business, including capabilities, end-to-end value delivery, information, and organizational structure. It establishes relationships among business views, strategies, products, policies, initiatives, and stakeholders, and links business elements to business goals and elements of other domains. Knowledge of Business Architecture is essential for architecture work in any other domain and is the first architecture activity that should be undertaken, unless already included in other organizational processes. Business Architecture is Phase B of the Architecture Development Model (ADM) as shown in the figure below.  Architecture Development Model The Business Architecture provides insight into how to achieve business goals and objectives, which is not necessarily explained by the business strategy. The amount of work required depends on the enterprise environment, and it is necessary to re-use existing material as much as possible. Existing Architecture Definitions can be used as a starting point, and it is essential to gather and analyze only the information that allows informed decisions to be made relevant to the scope of this architecture effort. The focus should be on building a complete picture without going into unnecessary detail if the effort is to support an existing Business Architecture. However, if the effort is focused on defining new business processes, it may require a lot of detailed work. Objectives of Business ArchitectureThe objectives of Business Architecture (Phase B) are as follows:
Inputs to the Business ArchitectureThere are a number of inputs required to complete the Business Architecture, both, Non-Architectural and Architectural that we’ll explore in this section. Non-Architectural Inputs
Architectural Inputs
A Step by Step Guide to Business ArchitectureDuring teh Business Architecture phase (Phase B), it is necessary to develop new models that accurately describe the business needs in detail. Any existing business artifacts that will be transferred and maintained in the target environment may have already been defined in previous architectural work, but if not, they should be defined here. The sequence and timing of the tasks in Phase B should be adjusted based on the specific circumstances, and should comply with the established Architecture Governance. In particular, it is important to determine whether to prioritize the development of Baseline or Target Architecture based on the situation at hand. The steps in the Business Architecture phase are as follows:
Select Reference Models, Viewpoints, and ToolsThe architect should choose relevant Business Architecture resources such as reference models and patterns, based on the business drivers and stakeholder concerns. They should also select appropriate Business Architecture viewpoints, such as operations, management, and financial, to demonstrate how the concerns of stakeholders are being addressed. Additionally, the architect should identify suitable tools and techniques for capturing, modeling, and analyzing the Business Architecture, based on the selected viewpoints, ranging from simple documents and spreadsheets to more advanced modeling tools like activity models, business process models, and use-case models, depending on the level of sophistication required. The Overall Modeling Process The process of business modeling and strategy assessments can be effective in establishing the desired state of an organization's Business Architecture. The outcomes from this activity can then be used to define the necessary business capabilities, organizational structure, and value streams that will bridge the gaps between the current and target state. The existing frameworks for these maps should be utilized, focusing on identifying gaps and mapping business value to achieve the Target Business Architecture. To support each viewpoint, the appropriate models should be chosen to fulfill the specific requirements using the selected tool or method. It is crucial to ensure that all stakeholder concerns are addressed, and in case they are not covered, new models should be created to address the gaps or enhance the existing models. Business scenarios are a valuable technique that can be used iteratively at different levels of detail in the hierarchical decomposition of the Business Architecture to discover and document business requirements. The following techniques can be utilized to progressively decompose a business:
The level and rigor of decomposition needed vary from enterprise to enterprise and within an enterprise. The architect should consider the enterprise's goals, objectives, scope, and purpose of the Enterprise Architecture effort to determine the appropriate level of decomposition. Value stream maps help in identifying the most important activities and their interrelationships, providing a basis for analysis and improvement. Develop Baseline Business Architecture DescriptionTo support the development of the Target Business Architecture, it is necessary to first develop a Baseline Description of the current Business Architecture. The level of detail required for this description will depend on how much of the existing business elements will be carried over into the new architecture and whether existing Architecture Descriptions exist. Relevant Business Architecture building blocks can be identified by drawing on the Architecture Repository. In cases where new architecture models are needed to address stakeholder concerns, the models identified in Step 1 can be used as a guide for creating new architecture content to describe the Baseline Architecture. Develop Target Business Architecture DescriptionCreate a Target Description for the Business Architecture, as needed to support the Architecture Vision. The level of detail and scope should depend on the relevance of the business elements to achieving the Target Architecture Vision, and whether architectural descriptions exist. The relevant Business Architecture building blocks should be identified as much as possible, with reference to the Architecture Repository. In cases where new architecture models need to be developed to meet stakeholder concerns, the models identified in Step 1 should be used as a guide to produce new architecture content that describes the Target Architecture. It may be appropriate to explore different Target Architecture options and engage stakeholders in discussions about these alternatives, using Architecture Alternatives and Trade-offs. The Target Business Architecture will include the following:
Perform Gap AnalysisEnsure the accuracy and internal consistency of the architecture models by following these steps:
Define Candidate Roadmap ComponentsAfter creating the Baseline Architecture, Target Architecture, and conducting gap analysis, the next step is to develop a Business Architecture Roadmap. This roadmap will prioritize the activities needed in the upcoming phases. The initial roadmap created will serve as a basis for a more detailed, consolidated, cross-discipline roadmap to be defined in the Opportunities & Solutions phase. Resolve Impacts Across the Architecture LandscapeAfter finalizing the Business Architecture, it is crucial to assess any broader impacts or implications. This involves reviewing other architecture artifacts within the Architecture Landscape to determine:
Conduct Formal Stakeholder ReviewReview the initial motivation behind the architecture project and the Statement of Architecture Work, and compare them with the proposed Business Architecture to ensure that it aligns with the purpose of supporting subsequent work in other architecture domains. Modify the proposed Business Architecture only if required. Finalize the Business Architecture
Create the Architecture Definition Document
If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the document for review by relevant stakeholders, and incorporate feedback. Outputs from the Business Architecture Phase The outputs of the Business Architecture, or Phase B may include, but are not restricted to:
SummaryBusiness Architecture is a crucial component of any successful enterprise architecture program. It provides a clear understanding of the business goals and drivers and helps to align them with the overall architecture vision. By defining the business strategy, goals, and objectives, Business Architecture serves as a foundation for subsequent architecture work in other domains, such as data, application, and technology. Effective Business Architecture requires a thorough understanding of the enterprise environment and a collaborative approach that involves key stakeholders from across the organization. The use of established frameworks, such as TOGAF, can help to ensure that Business Architecture is developed in a structured and consistent manner. By providing a clear understanding of the business requirements and drivers, Business Architecture enables organizations to make informed decisions about technology investments and align them with business goals. It also helps to identify opportunities for process improvement and optimization, which can result in cost savings and increased efficiency. In summary, Business Architecture is an essential element of any enterprise architecture program, providing a comprehensive view of the business that enables informed decision-making and supports the successful implementation of architecture solutions.
The Architecture Vision phase helps organizations to establish a shared understanding of the future state of their enterprise architecture and provides a roadmap for achieving it. In this article, we will explore the key inputs and outputs of the Architecture Vision phase, as well as the process for implementing it in an organization. The TOGAF Architecture Vision phase of the ADMThe Architecture Vision phase describes the initial phase (Phase A) of the TOGAF ADM (Architecture Development Method) as shown in the figure below.  Architecture Vision: Phase A This phase sets the foundation for the rest of the ADM and focuses on establishing a clear understanding of the organization's business objectives, drivers, and constraints. It also involves creating a high-level view of the enterprise architecture that supports these objectives. The main objectives of the Architecture Vision phase are:
Inputs to the Architecture Vision PhaseThe Architecture Vision phase of the TOGAF ADM requires several inputs to be successful. These inputs provide the context, requirements, and constraints necessary to develop a clear and effective architecture vision and roadmap. The main inputs required for the Architecture Vision can be split into Non-Architectural and Architectural as follows: Non Architectural
Architectural Organizational Model for Enterprise Architecture including:
Tailored Architecture Framework including:
Populated Architecture Repository providing all of the existing architectural documentation including:
A Guide to Creating the Architecture VisionThe creation and development of an architecture vision involves a a number of specific steps to be taken. the following section provides a step-by-step process for creating and developing the architecture vision. The level of detail addressed in the Architecture Vision phase will depend on the scope and goals of the Request for Architecture Work, or the objectives and scope associated with this iteration of architecture development. The steps in the Architecture Vision phase are as follows:
Outputs of the Architecture Vision PhaseThe outputs of the Architecture Vision phase are critical in providing a solid foundation for the rest of the ADM phases. They offer a clear understanding of the organization's strategic objectives, business requirements, and constraints, as well as a high-level architecture vision and roadmap that supports these objectives. Phase A outputs include the following:
By producing these outputs, the Architecture Vision phase helps to establish a shared understanding of the organization's strategic objectives, business requirements, and constraints among stakeholders. This, in turn, enables the enterprise architecture. Once an Architecture Vision is defined and documented in the Statement of Architecture Work, it is critical to use it to build a consensus. Without this consensus it is very unlikely that the final architecture will be accepted by the organization as a whole. SummaryThe Architecture Vision phase is a critical step in the TOGAF ADM that can help organizations to develop a clear and effective enterprise architecture that supports their business objectives. By following the process outlined in this article and applying best practices, organizations can ensure a successful Architecture Vision phase that sets the foundation for a successful enterprise architecture development process. The TOGAF Architecture Development Method (ADM) is a framework for developing and implementing Enterprise Architecture. It provides a structured approach for organizations to design, plan, implement, and manage their enterprise architecture, ensuring that it aligns with the organization's goals and objectives. The ADM consists of nine phases, each with a specific focus and set of tasks. These phases range from establishing the overall vision and goals for the architecture, to implementing and managing the architecture over time. By following the ADM, organizations can ensure that their architecture is comprehensive, effective, and adaptable to changing business needs. The nine phases of the ADM are shown in the figure above and we'll take a closer look at each of these.
Overall, the ADM provides a structured and iterative approach to developing and implementing enterprise architecture, with a focus on alignment with business goals and objectives. The Benefits and Challenges of the ADM The TOGAF Architecture Development Method (ADM) provides several benefits for organizations that are looking to develop and implement effective Enterprise Architecture. However, there are also some challenges that organizations may face when using the ADM. Here are some of the key benefits and challenges of the TOGAF ADM. Benefits
Challenges
In conclusion, the TOGAF ADM provides a structured and systematic approach for developing and implementing Enterprise Architecture. While there are challenges associated with using the ADM, the benefits of this approach outweigh the challenges for many organizations, leading to more effective and successful enterprise architecture.
The Open Group Architecture Framework (TOGAF) is a popular framework for developing and implementing EA. TOGAF provides a common language, methodology, and framework for designing and managing EA, allowing organizations to standardize their approach and increase efficiency. It is a comprehensive framework that covers all aspects of EA, from planning and development to implementation and maintenance. TOGAF has gained widespread adoption among organizations of all sizes and industries, and is often used in conjunction with other frameworks and methodologies. The TOGAF framework is divided into four main components:
Overall, TOGAF provides a holistic and structured approach to enterprise architecture development and management, which can help organizations achieve their business goals more effectively and efficiently. Components of the TOGAF Framework The Open Group Architecture Framework (TOGAF) has several key components that provide a structured approach to developing and managing enterprise architecture. These components include:
These components of TOGAF provide a comprehensive and structured approach for developing and managing enterprise architecture, with a focus on alignment with business goals and objectives. Benefits of Enterprise Architecture
Challenges of Enterprise Architecture
In summary, while enterprise architecture and TOGAF provide significant benefits to organizations, there are also challenges in implementing and measuring the success of enterprise architecture. Organizations should carefully consider these factors before embarking on an enterprise architecture initiative. |
AuthorTim Hardwick is a Strategy & Transformation Consultant specialising in Technology Strategy & Enterprise Architecture Archives
March 2025
Categories
All
|
