In the How to develop an information management strategy article, I discussed how to develop a technical strategy using Enterprise Architecture frameworks.
In the A modern information management system architecture, I presented the system architecture components which can be used in an information management solution.
After the technical strategy and architectural road map has been agreed, funding is obtained for creating a particular solution to meet the high level objectives. A business consultant is then engaged to establish sufficient high level functional and non-functional requirements in order that a solution architecture can be successfully developed.
The next stage is to create a information management solution architecture, which pulls together the 4 pillars of enterprise architecture defined in the technical strategy and provides sufficient detail so that infrastructure can be bought and delivery teams can begin high level design.
The sections which should be completed for a holistic information management solution architecture are:-
- Describe the purpose of the solution and tie it back to the strategic business objective.
2. Enterprise Architecture Standards & Policies
- Within a large organisation there are policies around naming conventions, handling of sensitive data, disaster recovery and other legal restrictions which a solution architect has to be mindful of when developing the solution.
3. Business Architecture
- Identify which business capabilities will be affected by the solution and the associated business stakeholders.
- Write a value chain for the solution
- Describe the process that will be used to ensure that master data is controlled.
- Define the teams, locations and business processes which will need to be established for the solution to be supportable in production. For example, a business process will be required for approving a new user for access to a business intelligence solution. A business process will need to be created which describes how the support function should react to issues with the information management system. etc.
4. Application Architecture
- Select the system architecture components from the architectural pattern produced by the enterprise architect.
- Decide on how the data integration will work for the solution. Typical data integration capabilities include:-
– File transfer. Data is saved to a file local to the source system. It can then either be pushed or pulled from the source to a target system using protocols such as secure ftp.
– Data replication. This is replicating data by capturing information from the source database log and applying it to a target database. Usually, minimal transformation of the data takes place, although extra control columns such as the apply timestamp may be included.
– Message queues and workflows. In this situation, an application writes data to a message queue and the associated workflow engine can forward the data on to 1 or more subscribing systems dependent on the contents within the data.
– Extract, Transform and Load (ETL). In this situation, a data integration engine extracts data from a source file or data store, transforms it and then stores it in target file or data store.
For example, if the business consultant’s said that the business want a reporting & data analytics solution where they can capture transactional data and associated messages from source in near real time and be able to query the data as soon as possible. There are no dynamic data masking rules to be imposed but user authentication is required. Data has to be retained online for no more than 2 months and should then be archived for 2 years. There is no need to show data lineage, but a business glossary is required and transactional data should be linked to existing master data maintained via a corporate master data management solution . A viable draft system architecture which would meet that need is shown below:-
Note: The draft solution architecture could be improved by labelling each system component and interface line, so that they can be easily referenced in the description of the system components and interfaces.
Once you’re satisfied that your system architecture diagram meets the outline brief, you should provide a description of the system components which explains it’s purpose and any notable functions and features relevant to the brief. The description for the interface lines should describe the data integration technology and the non-functional requirements such as latency that the interface will need to meet.
- Define audit and reconciliation controls which will ensure that data was transferred from source to target without any loss of data.
- Select the development framework for any data services layer that will need to be created to isolate an application from the persistent data store.
- Describe the user authentication, user authorisation security aspects that need to be met by the solution.
5. Information Architecture
- Take a conceptual data model which has been created by the information architect and tailor it to meet the known needs of the solution as provided by the business consultant.
- Describe data profiling steps that need to be carried out to ensure that the data at source is available and of sufficient quality for the solution requirements.
- Describe how the solution will meet data quality issues.
- Describe the data archive and retention policies
6. Technology Architecture
- Identify candidate vendor solutions in the enterprise architecture catalogue which will meet the functional and non-functional requirements captured by the business consultant.
- Identify candidate vendor solutions which are not available in the enterprise architecture catalogue and for which proof of concepts will need to be carried out to demonstrate that they can meet the functional and non-functional requirements.
- Define the development and test environments which will need to be created during delivery.
- Describe how the solution should meet disaster recovery/business continuity problems.