Future-State Physical Architecture and Vendor Selection

From MIKE2.0 Methodology

Activity: Future-State Physical Architecture and Vendor Selection

Objective

The Future-State Physical Architecture and Vendor Selection activity involves the mapping of both back-end and front-end tools to the logical and conceptual architecture. At this stage, there may be multiple vendor products against a single capability. The RFP can then be sent out to these vendors asking them to present their product capabilities.

The response from the vendor may involve a proof of the technology through a demo scenario (sometimes in direct competition with another vendor).

The determination of the technologies is based upon the environment and the user requirements (expressed through the architecture and required capabilities). In dealing with the multitude of tools that exist on the market, it is important that along with evaluation of product features, a strategic evaluation is made of the vendor company and its viability as a business.

The tasks below provide the process for this activity.

Note: While vendor selection is not always required (based on the map-and-gap of current-state vs. future-state requirements), physical architecture work is typically needed for large strategy projects.

Major Deliverables:

• Vendor Options
• RFP/s for Product Selection
• Selected Vendor

Tasks

Map Future-State Logical Architecture to Physical Architecture Options

Objective:

The task maps the logical capabilities that will be required for implementation to potential vendor options. The products that are identified at this stage include those needed to support foundation capabilities as well as more advanced enabling capabilities.

Input:

• Business Intelligence Logical Architecture
• Infrastructure Development Logical Architecture
• Information Development Logical Architecture
• Conduct Gap Analysis Measurement of the Future and Current StateArchitecture
• Current State and Future State Architecture Gap Analysis
• Client SOE on vendors

Output:

• Physical Architecture Options List, mapped to vendors

Define Vendor Options for Infrastructure Management and SDLC Tools

Objective:

This task surveys existing tools to support the overall software development lifecycle. This would include:

• Software development tools
• Testing tools (including test automation and load testing tools)
• Configuration management tools
• Defect tracking tools
• Infrastructure management systems (e.g. backup and recovery systems)

Input:

• Summary on Current-State Capabilities of SDLC Supporting Tools
• SDLC Procedures
• Testing Strategy

Output:

• Recommended vendor options for SDLC tools

Develop RFP for Candidate Technology and Tool Components

Objective:

As the conceptual and logical architecture has now been mapped at the physical level against a number of vendor options, an RFP can be issued out to vendors for product selection. The RFP process will typically involve a formal written response, presentations and product demonstration. This task requires much work on the front-end to identify only those vendors that have credible tools and technologies.

This task may be as formal as developing a weighted scoring system or as informal as a list of elimination requirements (those requirements that are not met eliminate the vendor from further consideration). The output of this task is a succinct requirement listing for the areas noted above. These requirement listings are then used as the screening mechanism for the next task.

Input:

• Map Logical Architecture to Physical Architecture Options
• Define Vendor Options for Supporting Systems and Tools

Output:

• RFP for Candidate Technology and Tool Components

Conduct Technology and Tool Selection

Objective:

The purpose of this task is to select the best technologies and tools for the previously identified requirements. This task involves contacting and scheduling vendors for presentations, demonstrations and in some cases pilot programmes. For software, it may be appropriate to enter into evaluation agreements to validate that the product performs as demonstrated. For hardware, it may be necessary to also enter into evaluation agreements and install the equipment in-house to perform benchmark testing. It is always appropriate to schedule reference calls and site visits.

The output of this task is a selection list of tools and technologies for the proof-of-concept, pilot project or the final selection of tools to be used in the first iteration development.

Input:

• RFP for Candidate Technology and Tool Components

Output:

• Tools and Technologies Selected

Core Supporting Assets

• Use Technology Selection QuickScan to make an objective technology decision

Yellow Flags

• Technology selection is being based largely on subjective factors
• The "short-list" of approved technology vendors do not provide solutions that meet the requirements
• Selected vendors provide technology options either through partnerships or recent acquisitions; the vendors\’ own technologies do not work well together within the overall suite
• Programme plan does not allow sufficient contingency for technology decision-making and procurement
• Required technologies are much more expensive than expected as per original business case
• Hesitation to invest in products to support the SDLC, such as modelling tools

Key Resource Requirements

• Solution Architect
• Technical Architect