Stakeholders and Concerns Modeling the View Key Issues
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.
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.
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