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
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
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.
Tasks
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
Discovery.
The purpose of this activity is to identify the information and data sources within the system/business unit.
Tasks
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.
Tasks
1. Begin creating Functional Specification including the list of SAP fields and the associated logic.
2. Perform Rediscovery / Cleansing as required .
Design.
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.
Tasks
- Perform Rediscovery / Cleansing as required
- Create & complete the Technical Design Specifications.
- Develop and unit test the transfer mechanism .
Moving On to Next Blog
Using TOGAF- Part6- Information System Architecture-Application.
