Developing an Acquirers View

Stakeholders and Concerns      Modeling the View      Key Issues


Stakeholders and Concerns

This view should be developed for personnel involved in the acquisition of any components of the subject architecture.

Major concerns for these stakeholders are understanding what building blocks of the architecture can be bought, and what constraints (or rules) exist that are relevant to the purchase. The acquirer will shop with multiple vendors looking for the best cost solution while adhering to the constraints (or rules) applied by the architecture, such as standards.

The key concern is to make purchasing decisions that fit the architecture, and thereby to reduce the risk of added costs arising from non-compliant components.

Modeling the View

The acquirer's view is normally represented as an architecture of solution building blocks, supplemented by views of the standards to be adhered to by individual building blocks.

Both views can be modeled in terms of the ADML entities (components, ports, connectors, and roles). All of these entities may have attributes of varying kinds. The attributes that are essential to the acquirer are budget and standards.

Key Issues

The acquirer typically executes a process similar to the one below. Within the step descriptions one can see the concerns and issues that the acquirer faces.

Procurement Process Steps

Step Description and Output

Acquisition planning

Creates the plan for the purchase of some component. For IT systems the following considerations are germane to building blocks.

This step requires access to architecture and solution building blocks.

    The procurer needs to know what architecture building blocks apply constraints (standards) for use in assessment and for creation of RFO/RFIs.

    The procurer needs to know what candidate solution building blocks adhere to these standards.

    The procurer also needs to know what suppliers provide accepted solution building blocks and where they have been deployed.

    The procurer needs to know what budget this component was given relative to the overall system cost.

 

Concept exploration

In this step the procurer looks at the viability of the concept. Building blocks give the planner a sense of the risk involved; if many architecture or solution building blocks exist that match the concept, the risk is lower.

This step requires access to architecture and solution building blocks. The planner needs to know what architecture building blocks apply constraints (standards), and needs to know what candidate solution building blocks adhere to these standards.

 

Concept demonstration and validation

In this step, the procurer works with development to prototype an implementation. The procurer recommends the reusable solution building blocks based upon standards fit, and past experience with suppliers.

This step requires access to reusable solution building blocks.

 

Development

In this step the procurer works with development to manage the relationship with the vendors supplying the solution building blocks. Building blocks that are proven to be fit for purpose get marked as approved. 

This step requires an update of the status to "procurement approved" of a solution building block.

 

Production

In this step, the procurer works with development to manage the relationship with the vendors supplying the solution building blocks. Building blocks that are put into production get marked appropriately.

This step requires an update of the status to "in production" of solution building blocks, with the system identifier of where the building block is being developed.

 

Deployment

In this step, the procurer works with development to manage the relationship with the vendors supplying the solution building blocks. Building blocks that are fully deployed get marked appropriately.

This step requires an update of the status to "deployed" of solution building blocks, with the system identifier of where the building block was deployed.

 


Copyright The Open Group, 2000