Continuous Improvement - Infrastructure

From MIKE2 Methodology

Contents 1 Activity: Continuous Improvement - Infrastructure 1.1 Objective 1.2 Major Deliverables 1.3 Tasks 1.3.1 Re-factor Integration Infrastructure 1.3.2 Progressively Automate Processes 1.3.3 Review and Recommend Physical Infrastructure Changes 1.3.4 Move to a Metadata-Driven Architecture 1.4 Core Supporting Assets 1.5 Yellow Flags 1.6 Key Resource Requirements

Activity: Continuous Improvement - Infrastructure

Objective

There will be many opportunities to increase the business value delivered by the infrastructure environment. Besides the approach outlined in the Technology Blueprint, which is focused on delivering new capabilities, there should be a structured approach to looking at the existing environment and continuously improving the core capabilities that already exist.

Continuous improvement of the infrastructure environment is done to:

• Reduce cost
• Remove inefficiencies
• Improve software quality
• Improve manageability
• Reduce risk

Continuous improvement of the infrastructure environment involves closely monitoring the current-state environments and instituting tactical changes that are inline with the strategic vision.

Major Deliverables

• Improvements to integration infrastructure through re-configuration or re-design
• Changes to hardware
• Changes to Software Development approach

Tasks

Re-factor Integration Infrastructure

Objective:

Most integration processes are unnecessarily complex and difficult to mange. Organisations should strive to continuously improve their integration environment towards a Service Oriented Architecture based on principles of:

• Reuse of common components
• Modularity and loose-coupling between services
• Improving software quality and manageability
• Improving software performance
• Reducing complexity though adoption of standards

Revisiting existing integration infrastructure should be a planned part of the overall programme – reviewing "working" components for quality and efficiency is still a valuable process. Feedback from the operation and monitoring lifecycle should act as the key input towards re-factoring.

Input:

• Design and software artefacts from existing integration environment
• Results from monitoring integration environment

Output:

• Re-factored Integration Infrastructure

Progressively Automate Processes

Objective:

Manual business processes dominate most organisations. These manual processes, often the main avenue of performing work, have no ability to scale. Lack of end-to-end visibility into business processes result in "black holes" across organisational or departmental boundaries that breed a non-disciplined organisation. To monitor the business activity, generating reports and Key Performance Indicator(s) is a heroic effort.

Most of these processes are unnecessarily manual, providing opportunities to significantly improve business capabilities. Automation of business processes helps to address some of the following issues:

• An inability to scale to meet growing business volumes without significantly increasing staff.
• Time lags between completed tasks that result an ineffective supply chain.
• Data quality issues that result from the manual entry of data
• The lack of a capability to effectively analyse and optimise current business process inefficiencies.

These processes can be automated in a progressive fashion, focusing first on either the most inefficient processes or those that are easiest to automate.

Input:

• Strategic Business Requirements
• BusinessTime Model for Information Integration
• Design and software artefacts from existing integration environment

Output:

• Improved integration infrastructure to progress towards BusinessTime model

Review and Recommend Physical Infrastructure Changes

Objective:

Upgrading physical infrastructure related to hardware, network and platforms will provide a means to improve performance, reduce cost and scale to meet new business demands for higher volumes. Physical infrastructure changes can often be implemented reasonably easily, with major benefits to the business. Physical infrastructure changes should always be framed in terms that show business benefits, even if these benefits are non-functional.

Upgrading physical infrastructure shouldn’t just focus on the production environment. There are often major opportunities to improve efficiencies in the SDLC by improving infrastructure in the development and test environments. As even minor improvements in developer efficiency can greatly reduce cost and improve time-to-market, this is an area that should receive considerable focus.

As cost/physical resource assets are continually decreasing, organisations should be intimately aware of changing physical infrastructure costs. There are often significant advantages that can be gained through consolidation or moving off legacy platforms. Infrastructure contracts should be reviewed at least every 6 months.

Input:

• Strategic Business Requirements
• Design and software artefacts from existing physical infrastructure environment
• Results from monitoring physical infrastructure environment

Output:

• Improved Physical Infrastructure

Move to a Metadata-Driven Architecture

Objective:

Organisations should be continuously moving towards a metadata-driven approach for integration. To achieve consistency, quality and reusability, metadata must be integrated between the sources of record for metadata. This metadata integration capability provides an ability to build metadata flows into and out of a managed metadata environment. Taking a metadata-driven approach also means:

• Making changes to the design and development processes as part of the SLDC as part of moving to a model-driven approach
• Capturing operational metadata to understand the impact of changes in design time
• Maximizing automation in documenting of data relationships and flows, and subsequent changes
• Being able to assess the impact of changes in definitive terms – tables, columns, entities, classes of systems, hours in development time, etc.
• Being mindful of how taking metadata-driven approach will change the traditional development and analysis lifecycle – deployment planning, data classification, and team-based development with proper read/write access control is key

The strategic architecture Blueprint should provide at least a long-term moving towards a metadata-driven architecture. This Metadata management approach will need to be across all components in the architecture. Foundation Capabilities for Metadata Management should be in place before moving to a more active metadata-driven integration approach.

Input:

• Overall Blueprint Architecture
• Design and software artefacts from existing physical infrastructure environment

Output:

• Changes in architecture towards a metadata-driven approach

Core Supporting Assets

Yellow Flags

• Resistance to re-factoring on the premise that the software already is in production
• Continuous Improvement of infrastructure must be managed specifically with the the infrastructure team, especially those not used to re-factoring and its benefits

Key Resource Requirements

• Infrastructure Architect
• Information Architect