Information Systems and Data Architecture: The Cornerstone of Digital Transformation

​​In today's data-driven world, designing effective information systems that can process, store, and manage large amounts of data is crucial for organizations to stay competitive. Information Systems Architecture and Data Architecture are two essential components of Enterprise Architecture that play a vital role in achieving this objective.

​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 ADM

​The 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.

Objectives

The objectives of the Information Systems Architecture phase are to:
​

• Develop the Target Information Systems Architectures, describing how the enterprise's Information Systems Architecture will enable the Business Architecture and the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns
• Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures

Approach

Phase 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:

• Phase C: Information Systems Architectures — Data Architecture
• Phase C: Information Systems Architectures — Application Architecture

In this article, we will focus on the Data Architecture and in the next article, we will focus on the Application Architecture.

Data Architecture

The 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 Architecture

Let'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:

• Which parts of your applications will be the go-to source for your master data?
• Will you need to establish a standard across your whole company that everyone has to follow, even when using software packages that may not be flexible?
• How exactly will your data entities be used across different areas of your business?
• How will your enterprise data entities be created, stored, moved around, and reported?
• What kind of data transformations will be necessary to make sure different applications can communicate with each other effectively?
• What software will you need to integrate data with your customers and suppliers? You may need to use tools like ETL or data profiling tools to make sure everything runs smoothly.

 
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:
​

• Structure: Do you have the right organization and standards in place to manage data entities during the transformation?
• Management System: Do you have the right management system and programs to oversee data entities throughout their lifecycle?
• People: Do you have the right people with the necessary data-related skills and roles in your company? If not, you may need to consider training or hiring to make sure you have the resources you need.

 
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 Architecture

In Phase C, the Data Architecture aims to achieve the following objectives:
​

• Create a Target Data Architecture that supports the Business Architecture and the Architecture Vision while considering the Statement of Architecture Work and addressing stakeholder concerns.
• Find potential components for the Architecture Roadmap by identifying the gaps between the Baseline and Target Data Architectures.

Inputs to the Data Architecture

This section defines the inputs to Phase C (Data Architecture).

Non-Architectural Inputs

• Request for Architecture Work
• Capability Assessment
• Communications Plan

Architectural Inputs

• Organizational Model for Enterprise Architecture
  • Scope of organizations impacted
  • Maturity assessment, gaps, and resolution approach
  • Roles and responsibilities for architecture team(s)
  • Constraints on architecture work
  • Budget requirements
  • Governance and support strategy
• Tailored Architecture Framework, including:
  • Tailored architecture method
  • Tailored architecture content (deliverables and artifacts)
  • Configured and deployed tools
• Data principles, if existing
• Statement of Architecture Work
• Architecture Vision
• Architecture Repository including:
  • Re-usable building blocks (in particular, definitions of current data)
  • Publicly available reference models
  • Organization-specific reference models
  • Organization standards
• Draft Architecture Definition Document, which may include Baseline and/or Target Architectures of any architecture domain
• Draft Architecture Requirements Specification including:
  • Gap analysis results (from Business Architecture)
  • Relevant technical requirements that will apply to this phase
• Business Architecture components of an Architecture Roadmap

The Process

The 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
• Develop Baseline Data Architecture Description
• Develop Target Data Architecture Description
• Perform gap analysis
• Define candidate roadmap components
• Resolve impacts across the Architecture Landscape
• Conduct formal stakeholder review
• Finalize the Data Architecture
• Create/update the Architecture Definition Document

 
Select Reference Models, Viewpoints, and Tools

• Review and validate, or create as needed, a set of data principles that are consistent with the overarching Architecture Principles.
• Choose appropriate Data Architecture resources such as reference models and patterns that align with the business drivers, stakeholders' concerns, and the Business Architecture.
• Select relevant Data Architecture viewpoints, considering stakeholder concerns, time dimensions, locations, and business processes. These viewpoints should enable the architect to demonstrate how the stakeholder concerns are being addressed in the Data Architecture.
• Identify suitable tools and techniques for data capture, modeling, and analysis based on the chosen viewpoints. Depending on the level of complexity required, these could range from simple documents or spreadsheets to more advanced modeling tools and techniques, such as data management models and data models.

Examples of data modeling techniques are:

• Entity relationship diagram
• Class diagram

 
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:

• Gather data-related models from existing Business Architecture and Application Architecture materials.
• Evaluate and reconcile data requirements with any existing enterprise data catalogs and models to create a data inventory and entity relationship.
• Develop matrices across the architecture by linking data to business services, capabilities, functions, access rights, and applications.
• Elaborate Data Architecture views by examining how data is created, distributed, migrated, secured, and archived.

 
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:

• Relate to the data domain
• Provide requirements input into the Application and Technology Architectures
• Provide detailed guidance to be reflected during design and implementation to ensure that the solution addresses the original architecture requirements

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:

• First, you need to determine the scope and level of detail that's needed for the Baseline Description. This will depend on how much of the existing data elements are expected to be included in the Target Data Architecture, and whether there are any existing architectural descriptions to work with.
• Next, you'll need to identify the relevant building blocks of the Data Architecture, using the Architecture Repository as a resource. This will help you understand how different data elements are related and how they work together.
• If there are any stakeholder concerns that are not adequately addressed by the existing architecture models, then you may need to create new models to describe the Baseline Architecture. In this case, you can use the models that were identified in Step 1 as a guideline for creating new architecture content.

 
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:

• Conduct trade-off analysis to resolve any conflicts between different viewpoints
• Ensure that the models align with the principles, objectives, and constraints
• Document any changes made to the selected models from the Architecture Repository
• Test the architecture models are complete and meet the requirements

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:

• Affects any existing architectures
• Has been impacted by recent changes
• Presents opportunities for leveraging in other areas of the organization
• Affects other ongoing or planned projects
• Is impacted by other ongoing or planned projects

  
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
​

• Choose appropriate standards for each building block, with a focus on reusing existing reference models from the Architecture Repository as much as possible.
• Thoroughly document each building block in the architecture document.
• Conduct a final review of the overall architecture against business requirements, and document the reasoning behind any decisions made regarding building blocks.
• Create a final report documenting how the requirements have been traced throughout the architecture development process.
• Record the final mapping of the architecture within the Architecture Repository, highlighting any building blocks that could be reused, and make this information available to others through the Architecture Repository.
• Complete all outstanding work products, including the gap analysis.

 
Create/Update the Architecture Definition Document

Document the rationale for building block decisions in the Architecture Definition Document:
​

• Business data model
• Logical data model
• Data management process model
• Data Entity/Business Function matrix
• Data interoperability requirements (e.g., XML schema, security policies)
• Use modeling tools to generate reports or graphics that illustrate critical architecture views if appropriate. Share the document with relevant stakeholders for review, and integrate their feedback.

Outputs

The outputs of Phase C (Data Architecture) may include, but are not restricted to:
​

• Refined and updated versions of the Architecture Vision phase deliverables, where applicable:
  • Statement of Architecture Work, updated if necessary
  • Validated data principles , or new data principles (if generated here)
• Draft Architecture Definition Document , including:
  • Baseline Data Architecture, Approved, if appropriate
  • Target Data Architecture, Approved, including:
    • Business data model
    • Logical data model
    • Data management process models
    • Data Entity/Business Function matrix
  • Views corresponding to the selected viewpoints addressing key stakeholder concerns
• Draft Architecture Requirements Specification, including such Data Architecture requirements as:
  • Gap analysis results
  • Data interoperability requirements
  • Relevant technical requirements that will apply to this evolution of the architecture development cycle
  • Constraints on the Technology Architecture about to be designed
  • Updated business requirements, if appropriate
  • Updated application requirements, if appropriate
  • Data Architecture components of an Architecture Roadmap

Summary

​In 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.​​​​​