Skip to Content

Moving on from Buisness Architecture to Information Systems Architectures focuses on identifying and defining the applications  and data that support the enterprise’s business  architecture for e.g defining views that relate to information,knowledge ,and application services. As per fundamental TOGAF methodology the implementation is top-down design and bottom up implementation.In summary we can take data being created by application,processed by application and archived by application .This means that thedesign starts with Business Architecture, and then progresses to Data (or Application)Architecture, then Application (or Data) Architecture, before finally designing the TechnologyArchitecture. Implementation then reverses this, starting with Technology Architecture beforeimplementing the Application (or Data) Architecture, then the Data (or Application) Architecture, and finally the Business Architecture.

Top Down Design

Bottom Up Implementation

Busn Arch Design                 Tech Arch Implementation           
Data Arch Design Application Arch Implementation
Appl Arch Design Data Arch Implementation
Tech Arch Design Busn Arch Implementation

The goal  of Data Architecture is to define the data entities relevant to the enterprise, not to design logical or physical storagesystems.In the context of Data Architecture i.e DATA Management we have considered  application components that will serve as the system of record or reference for enterprise Master Data,enterprise wide standard,utilization of data entities in business functions,processes and services,how and where they are stored,created ,transported and reported,Level of complexity of data transformation required as well requirement of any software.

The Gap Analysis Templates used was as shown  below

Data Gap Analysis

As per standard TOGAF  we have also stressed on identification of Data Migration requirements and also provide indicators as to the level of transformation ,and cleansing that will be required to present data in the format that meets the requirements and constraints of application domain so we have used

  •  Refrence  data models , and techniques such as E-R relationship diagrams, class diagrams,object role modeling.
  •  Data architecture viewpoints those that will enable the architect to demonstrate how the stakeholders concerns are being addressed in the data architecture.
  • Identified  required catalogs of data building blocks  showing the organisation data inventory.
  • Identified required matrices showing the core relationships between model entities,how data is created,maintained,transformed and passed to other applications or used by other applications.

Process Aspect For Order and Buy Data

Transactional Entities:

  • Define what data entities will be required for each process. Then define the common entities.
  • Define each entity and high level characteristics of the entity such as what doe sit define, number of instances, security, data life cycle management etc.
  • Analytical Entities
  • For analytical entities focus on their relationships
  •  KPI Entities
  • Define what data entities will be required to compute the KPI. Validate ensure these entities are collected as part of normal business process or through additional process that can be characterized as Complex Work .

Enterprise Value

  • Skills Acquired
  • Link these skills with skills required in overall skills competencies inventory maintained .

Master Data

  • Master Data Defined
  • Master Data Entities Services Defined

Following data sources were identified :

  • Customer

  • Agency

  • Quotes

  • Policy

  • Fund

  • Claims

  • Pay outs

 Data ARCH

In this context i would also like to highlight some of the proceses relataed to DATA Architecture that we have under taken (though it may appear generic) such as

Data Conversion Process  It is an objective of the data conversion process to provide a “seamless” cut-over for business users upon the commissioning of the new Order & buy system. This means that partially completed business processes would still be reflected within the new system and the impacts on financial business operations due to the cut-over to the new system are minimized.the following steps were followed

Site survey:

The purpose of this task is to establish system/business unit specific information with regards to the legacy data conversion and migration requirements. 


1.   Identify the system/business unit sites that need to be surveyed.

2.   Conduct a system/business unit site survey and record the following details in a document.

  • Scope – what system(s) are being surveyed and which business users access and maintain the system(s). 
  • Business Objectives – document the present business with regards to organizational structure, work practices, operations activities, etc.
  • Inputs – document what automated or manual processes pass information to this system.
  • Processing – document how the input data is processed; what databases, file structures and etc. are used.
  • Outputs – document what reports are generated; what data is created, what data is passed to other systems.
  • Document the estimated number of records, frequency of change to the records, and possible key contacts, business and system contacts


The purpose of this activity is to identify the information and data sources within the system/business unit.


1.   Define the scope of  functionality that needs to be implemented and identify the  business functions that support the functionality. Identify site legacy systems that currently support the business functionality in scope. 

2.   Identify the legacy data files required to support the site legacy systems identified in Task 1. 

3.   Validate and cleanup legacy data files in the legacy system whenever possible

4.   Clearly identify, document and prepare the data dictionaries of all legacy systems associated with the targeted functionality release.

Data Mapping.

In many cases, multiple legacy data fields, along with logic and conversion rules, are needed to create the  data fields. These data conversion rules need to be documented in the specification and data mapping matrix file.  


1. Begin creating Functional Specification including the list of SAP fields and the associated logic.

2.  Perform Rediscovery / Cleansing as required .  


The purpose of this activity is to collate the information gathered from the Discovery activities into a detailed  Specification.  This allows for the coding and testing of the conversion routine in the Execution phase.


  1. Perform Rediscovery / Cleansing as required
  2. Create & complete the Technical Design Specifications.
  3. Develop and unit test the transfer mechanism .


 Moving On to Next Blog

Using TOGAF- Part6- Information System Architecture-Application.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply