TL;DR
Phase C has two tracks. For Application Architecture, reuse relevant application and industry reference models. For Data Architecture, focus on data management, data migration, data governance, and conceptual/logical/physical data models.
Practical flow
flowchart TD C["Phase C: Information Systems Architectures"] C --> APP["Application Architecture approach"] C --> DATA["Data Architecture approach"] APP --> APP1["Use relevant application models"] APP --> APP2["Use industry business and application models"] APP --> APP3["Consider III-RM where integration matters"] DATA --> D1["Data management"] DATA --> D2["Data migration"] DATA --> D3["Data governance"] DATA --> D4["Conceptual, logical, and physical data models"] APP3 --> TARGET["Target Information Systems Architectures"] D4 --> TARGET
Application Architecture approach
TOGAF gives less detailed guidance for developing the target Application Architecture than it gives for Data Architecture.
The practical advice is to reuse models instead of starting from a blank page.
Useful sources include:
- application models for common high-level business functions, such as e-commerce or supply chain management
- generic business models and related application models for the organization’s industry sector
- industry-specific application models from sources such as The Open Group, Object Management Group (OMG), and TM Forum
- III-RM from The Open Group, where integrated information infrastructure is a major concern
III-RM means Integrated Information Infrastructure Reference Model. It focuses on the application-level components and services needed to provide integrated information infrastructure.
For representation techniques, see Application Architecture Artifacts.
Data Architecture approach
Good use of data can become a competitive advantage. Phase C should therefore define a solid Data Architecture, not just a list of databases.
Three areas matter especially:
| Area | What to focus on |
|---|---|
| Data management | Define which application components act as master data sources. Understand how data entities are used by business capabilities, business functions, processes, business services, and application services. Understand where enterprise data entities are created, stored, transported, and reported. |
| Data migration | Identify migration requirements. Note where data transformation, weeding, and cleansing are needed. Establish common enterprise data definitions to support transformation and migration. |
| Data governance | Ensure that the enterprise has the structures, management systems, and people needed to manage data through the transformation. |
For representation techniques, see Data Architecture Artifacts.
Data model levels
Use conceptual, logical, and physical data models to define the structure of the Data Architecture.
| Model level | Metamodel entity | What it is used for |
|---|---|---|
| Conceptual data model | Data Entity | Helps IT developers understand the business concepts they are dealing with |
| Logical data model | Logical Data Entity | Defines requirements for data stored in applications, moved between applications, or presented at application interfaces |
| Physical data model | Physical Data Entity | Describes data models that have been implemented |
The three levels keep business meaning, logical design, and physical implementation separate.
Forms of data to handle
Data Architecture should consider different forms of data:
| Form | Meaning |
|---|---|
| Data at rest | Stored data |
| Data in motion | Data moving through transactions, services, or APIs |
| Data in use | Data at the boundary of an application, such as data displayed in a graphical user interface |
| Open data | Data the organization provides for public use |
This helps avoid a narrow view of data architecture that only covers stored databases.
Exam note
- Phase C includes both Data Architecture and Application Architecture.
- Application Architecture often relies on reusable application models and industry reference models.
- III-RM is the Integrated Information Infrastructure Reference Model.
- Data Architecture should address data management, data migration, and data governance.
- Data models can be conceptual, logical, or physical.
- Data Architecture should cover data at rest, data in motion, data in use, and open data.