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.

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

Task: 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.

Task: 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.