Solution Architecture Definition/Revision

From MIKE2.0 Methodology

Activity: Solution Architecture Definiton or Revision

Objective

The Solution Architecture Definition/Revision activity defines in detail the Solution Architecture for the new information management environment. The Solution Architecture provides the overall technology solution for a specific increment and ties together the overall approach. It will typically contain aspects of Conceptual, Logical and Physical Design with the goal being an approach that provides sufficient technical details to undertake detailed logical and physical design, development, testing and implementation of the project.

Not all projects will have a specific Solution Architecture deliverable (this information may be distributed across deliverables) but if it is used it often becomes one of the most significant design deliverables.

The SAFE Architecture can be directly applied to a number of well-known architecture models for defining architecture aspects such as the Enterprise Architecture or Solution Architecture. One such model for Solution Architecture is Krutchen’s 4+1 View of Architecture ^[1]. This architecture model is suggested as part of the Rational Unified Process as an approach for providing a holistic picture of software architecture. Whether or not a project applies RUP, Krutchen’s model provides a good model for Solution Architecture.

For implementing solutions using the SAFE approach, Krutchen’s model has been adapted to suit an approach focused on the procurements of technologies, starting with a conceptual architecture approach. Many of the technologies across the Technology Backplane will not be custom-built, so having a model that is purposely designed for product selection has shown to be an effective approach. Krutchen’s model views the architecture from different perspectives, each of which expresses particular aspects of the solution’s character:

• Conceptual Architecture View: This view depicts the high level logical software architecture. It provides a common model of what services are provided to fulfil explicit and implied requirements of scenarios. It avoids focusing on how services are delivered by software.

• Logical View: This view describes the specific logical software components that will deliver the Conceptual Architecture in sufficient detail to realise the solution in terms of COTS or bespoke software solutions.

• Physical View: describes what specific physical software components will deliver the Logical View. This view of the architecture would show the use of specific software solutions – e.g. the representation of the ETL solution using Informatica.

• Process View: describes how scenarios will be delivered by co-ordination between software components, and by interaction with external actors

• Implementation View: describes non-functional considerations relating to the implementation and distribution of the Component View on physical hardware and data communication networks. The Implementation View also considers implementation issues relating to areas such as security.

In addition, Use Cases (sometimes called Scenarios) are employed to provide a unifying business view across the architecture. This approach is used to iteratively and incrementally develop the architecture, considering each view in turn. The first 3 views are defined during the Blueprint but will be refined to greater detail during the Solution Architecture.

This approach for Solution Architecture builds on the Overall Blueprint Architecture developed in Phases 1 and 2. Whilst the Overall Blueprint Architecture is at the Strategic Level, the Solution Architecture is at the next level down for implementation. Any changes to the Solution Architecture should flow back up into the Strategic Conceptual, Logical, Physical and High Level Solution Architecture models that make up the Overall Blueprint Architecture.

Major Deliverables

• Solution Architecture

The Tasks below reflect some of the main sections of the overall Solution Architecture:

Tasks

Define Data Quality Management Processes

Objective:

The purpose of this task may be 2-phased: It may described at a fairly detailed how the data re-engineering processes can implemented across the environment to improve data quality. It may also be done post-creation of the re-engineering processes to show how they can be operationalised into the integration environment or be part of the data migration approach.

Input:

• Detailed Business Requirements for Increment
• Target Conceptual Data Model and Logical Data Model
• Data Quality Assessment Report
• Data Re-Engineering Processes

Output: Solution Architecture Updated with:

• Data Quality Management Conceptual Design

Define ETL Conceptual Design

Objective:

The purpose of the ETL Conceptual Design is to guide the overall solution approach that feeds into the ETL Logical and Physical Design. It is at a high level, but should contain the following:

• Sketch of the overall flow
• List of sources
• Whether a staging area is to be used
• List of targets
• Major transformations
• Volume estimates
• Frequency of update (Timing)
• Mention of significant complexities, such as:
  • Slowly-changing dimensions
  • Interface with a data re-engineering tool
  • Very complex transformations

It will also be important to cover the overall approach integration architecture and how it will handle different types of scenarios. The ETL Conceptual Architecture should present the high level strategy related to:

• extraction increments
• full data loads
• frequency
• data staging
• bulk load
• incremental updates
• purging

Both of the initial population and the refresh are at a high level in the Solution Architecture and are realised in the ETL Design. In some cases the ETL Conceptual Design will be a separate deliverable.

Input:

• Detailed Business Requirements for Increment
• Target Conceptual Data Model and Logical Data Model
• Data Quality Management Conceptual Design
• Overall Blueprint Architecture

Output: Solution Architecture Updated with:

• ETL Conceptual Design

Metadata Management Conceptual Design

Objective:

This task determines how metadata will be obtained, created and stored. It also determines who the users are; and, how and what metadata should be made available to them.

Since metadata usually resides in different places it will take effort to consolidate the different sources. The uses of the metadata will also influence the management strategy and the selection of tools that capture metadata.

The end users will need the following metadata categories of interest, which may include:

• Business definition of the data
• Physical data models
• Common Messaging Model for data in motion
• Sources to answer questions about the data
• Data Re-Engineering metadata
• Data Quality metadata
• Algorithms or formulas used to derive data (in business terms)

The technical users will need to know the above plus the following:

• Legacy files
• Database structures

Input:

• Overall Blueprint Architecture
• Detailed Business Requirements for Increment
• Target Conceptual Data Model and Logical Data Model
• Updated Metadata Repository from Data Profiling and Data Re-Engineering

Output: Solution Architecture Updated with:

• Metadata Management Conceptual Design

Define Security Conceptual Design

Objective:

The Security Architecture is sometimes broken into a separate deliverable, depending on the complexity of the requirements. Some issues to consider in defining the security model are:

• What kind of login access control is needed for each of the client side programs?
• What access control is needed at the database itself?
• Will security be managed at the level of the user, the relation, and/or the view?
• Who will control accounts and privileges, and what procedures will be used?
• What kind of audit trail is needed?
• Should security be managed through database capabilities, and/or through stored procedures or gateway programs?
• How do security concerns impact the distributed architecture, and the use of performance strategies such as replication and caching?

Security requirements will be particularly complex if the solution must service external clients or if the data is of a secretive nature. Security Standards should drive the Security Architecture.

Input:

• Data Security Standards
• Overall Blueprint Architecture
• Detailed Business Requirements for Increment
• Security Requirements

Output: Solution Architecture Updated with:

• Security Conceptual Design

Define Infrastructure Management Conceptual Design

Objective:

Provides the conceptual design for all other processes used for creating and maintaining the information management environment. Examples include:

• Backup & Recovery
• Archiving
• Usage monitoring of the information management environment

Input:

• Overall Blueprint Architecture
• Detailed Business Requirements for Increment

Output: Solution Architecture Updated with:

• Infrastructure Management Conceptual Design

SDLC Processes Conceptual Design

Objective:

Other areas to note in the Solution Architecture may be a specific design related to the Testing or Deployment Architecture. Whereas the SDLC standards would have been defined at an earlier stage, if advanced capabilities are required (e.g. automated procedures for testing) it should be explicitly designed within the Solution Architecture. This may then be broken down in a separate deliverable, depending on the complexity of the requirements.

Input:

• Testing Strategy
• SDLC Procedures
• Testing Plans for Applications, Infrastructure and Information Development
• Deployment Plan
• Configuration Management Baseline
• Overall Blueprint Architecture
• Detailed Business Requirements for Increment

Output: Solution Architecture Updated with:

• Conceptual Design for SDLC Processes

Core Supporting Assets

• provide a very high level starting point. This architecture deliverable is much more comprehensive.

Yellow Flags

• Solution Architecture highlights major areas of complexity not envisaged during requirements definition
• Solution Architecture diverges from the vision of the Strategic Architecture

Key Resource Requirements

• Solution Architect
• Other architecture or technical leads in their respective areas

Potential Changes to this Activity

This activity should be generalised enough to cover the solution architecture tasks that would also apply to unstructured content. Expansion may also be required for BI architecture tasks. The solution architecture should have the flexibility to cover certain types of architecture such as EII, SOA and MDA.

References

1. ↑ Krutchen, P.B, The 4+1 View Model of Architecture', IEEE Software, pp. 4250, November 1995