Acquisition
quality attributes are properties of an acquisition approach. An acquisition quality attribute
is a measure or testable property of an acquisition’s strategy that is used to
indicate how well the acquisition satisfies the needs of its stakeholders.
Within the information systems arena, the relationship of business goals and information technology is termed business-IT alignment, and is crucial to the success of an enterprise.
Acquisition quality attributes reflecting business goals can be used to judge the effectiveness of an acquisition strategy — focused on determining how to express, elicit, and analyze acquisition quality attributes for their utility in surfacing potential incompatibilities between a software architecture and an acquisition strategy.
Examples of these initial acquisition quality attributes are criteria by which acquisition strategies are judged:
- Affordability
- Achievability
- Effectiveness
- Flexibility
A critical link exists between acquisition quality attributes and an acquisition strategy calling for an alignment method that collects and analyzes acquisition and software quality attributes in a way that enables deconfliction and prioritization. Acquisition strategies and software architectures built from this consistent set of quality attributes will be aligned and mutually constraining.
You can
think of an acquisition quality attribute as measuring the “goodness” of an
acquisition’s strategy along some dimension of interest to a stakeholder.
- Acquisition quality attributes are derived from the organization’s business goals and relate the business goals to the acquisition strategy. That is, to formulate acquisition quality attributes for an acquisition implies explicitly developing an acquisition strategy that accommodates them: they must be designed into the strategy to minimize the risk of failure.
- An acquisition strategy is a business and technical management approach designed to achieve acquisition objectives within the resource constraints imposed. It is the framework for planning, directing, contracting for, and managing an acquisition. It provides a master schedule for research, development, testing, fielding, modification, post acquisition management, and other activities essential for success.
- A given acquisition strategy embraces key business goals, whether stated or unstated, that can affect the acquisition, referring to the wide array of desires, goals, and objectives held by a broad cross-section of stakeholders spanning the hierarchy from very senior to junior.
- Business goals imply acquisition quality attributes that can be defined by acquisition-specific acquisition quality attribute scenarios that can be used to judge the effectiveness of the acquisition strategy.
Acquisition Quality Attribute Scenarios
An approach for expressing specific acquisition quality attribute scenarios is where stakeholders are encouraged to create small “stories” that specify some event (the stimulus) that occurs in a particular part of the lifecycle (the environment) and a desired behavior (the response).
For example, in software architecture, a quality attribute might be expressed using the following three-part scenario:
- Stimulus – an internal component fails
- Environment – during normal operation
- Response – the system recognizes an internal component failure and has strategies to compensate for the fault
In the acquisition domain, a similar example might be as follows:
- Stimulus – an unexpected budget cut
- Environment – for a multi-segment system
- Response – the program is able to move work between major segments to speed up or slow down separate segments within the available funding
Eliciting acquisition quality attribute scenarios from stakeholders validate that qualities related to an acquisition strategy can be expressed in a meaningful way through these scenarios. A tight relationship exists between an acquisition quality attribute scenario and some element of the of the acquisition strategy.
The following is an example:
- Stimulus – a new need arises when we want to react quickly
- Environment – where there are only a limited number of responsive suppliers
- Response – the organization can satisfy the need by using an existing supplier
Different scenarios result in different acquisition strategies. For an acquisition quality attribute scenario to influence the acquisition strategy, there must be some element of the scenario that leads the organization to choose a strategy. For instance:
- A new technology is found to be unsuitable where schedule is of prime importance; the organization switches to an alternative that is also currently under development and is evaluated to be suitable.
- A new technology is found to be unsuitable where costs must be kept as low as possible; the organization restarts but using an alternative technology.
In the case of these scenarios, the stimulus is the same but the environment changes. In the first scenario, schedule is more important than cost. The second scenario reverses their relative importance.
Although this is a simple example, it demonstrates that different acquisition quality attribute scenarios can lead to different acquisition strategies.
Incompatible Acquisition Scenarios. Conflicts between scenarios are not always obvious, and may be quite subtle without some analysis. For example, organization ABC is using a large, complex legacy system deployed in multiple operational locations, where each location installed its own local variant of the system. Over time, these variants have diverged in response to differing requirements of the local users.
To accommodate mission changes, it has become important to share data across these locations in a more integrated way. A new program was initiated to acquire one replacement capability that would support all of the differing needs across the multiple fielded locations. The program decided to implement an incremental approach to replacing the legacy system so they could respond to budgetary constraints and uncertainties.
For the example described above, the following scenario reflects the expectation of one set of influential stakeholders who advocated the use of a commercial off-the-shelf (COTS) product that had been successfully used at one of the operational installations:
- Stimulus – There is a desire to replace a complex component of a large legacy system with a COTS package
- Environment – Within an established enterprise architecture with many local variations implemented that are largely different from each other
- Response – The program runs a competition to evaluate COTS packages for an enterprise-wide solution.
A second set of stakeholders, reflecting operational users, is counting on the new system to quickly address their current needs. These needs vary among the current fielded locations. During the time it takes the program to define an agreed upon set of requirements for each increment, the user representatives from the various fielded location change their requirements. This leads to a second acquisition scenario:
- Stimulus – Requirements for the next release keep changing
- Environment – For a program with a fixed budget that must be carefully managed
- Response – The program accepts the new requirements
Implied in these two scenarios is a third set of stakeholders: the enterprise system engineers, who are advocating the implementation of an enterprise architecture that extends across all of the local fielded implementations.
This enterprise architecture could be incompatible with both of the above scenarios: each COTS product, by definition, is built to an architecture and a set of requirements that organization ABC has no control over. Moreover, the demands for local fielded implementations compete with architectural changes within a constrained budget.
This enterprise architecture could be incompatible with both of the above scenarios: each COTS product, by definition, is built to an architecture and a set of requirements that organization ABC has no control over. Moreover, the demands for local fielded implementations compete with architectural changes within a constrained budget.
Unfortunately, the two scenarios are potentially incompatible with respect to designing the acquisition strategy. The first scenario describing the implementation of a common COTS product across all locations could provide sizeable value in terms of moving to one capability that is used across all fielded locations, but it may not meet what the current users described in the second scenario consider urgent needs — and both of these may conflict with the move to an enterprise architecture.
