The Role of Architecture in Acquisition
Using enterprise architecture (EA) to identify needs, plan investments, establish transition strategies, and guide system development is a mechanism to achieve strategic goals and improve mission performance across all programs, and departments. This article describes what architecture artifacts and descriptions are most useful to enable acquisition strategy efforts and at what point during the acquisition lifecycle those artifacts and descriptions should be used.
EA and acquisition are key areas that should be tightly integrated within an organization or department program’s acquisition strategy. The first step in a closer, more mutually beneficial relationship between them is to identify the points at which the two areas’ business processes overlap, also known as “touch points.” It is at these touch points that acquisition and EA teams should ensure that their processes and results align with each other. Better alignment of and communication between acquisition and EA at these touch points will reduce functional duplication, improve resource interoperability, and achieve greater benefits.
Three such touch points occur during the following acquisition lifecycle support phases or efforts:
- Requirements Definition
- Request for Information/Request for Proposal (RFI/RFP) Support
- Evaluation Criteria and Performance Metrics
Requirements Definition
A well-defined requirements definition document establishes a solid foundation for acquisition planning and subsequent design activities. The requirements definition document is the official statement of system functional and non-functional requirements. The EA artifacts and descriptions artifacts and descriptions that best support Requirements Definition include Business Process Diagrams and Models, systems/services functionality descriptions. These artifacts and descriptions describe what the system(s) must do (non/functional requirements), the data to be manipulated by the system functions (data requirements), and the user interaction with the system(s) (user interface requirements). Table 1 lists these artifacts and descriptions and their applicable output to Requirements Definition.
Typically, the requirements identified from these artifacts and descriptions can be categorized as usability, performance, security, legal, and operational requirements.
RFI/RFP Support (Solicitation Package)
The primary purpose of a solicitation package is to tell prospective Vendors what is needed. Specific solicitation development depends upon the nature of the acquisition — will it be a Performance Work Statement (PWS) or a Statement of Objectives (SOO), either one the EA artifacts and descriptions described in Table 2 can assist with the solicitation development.
A comprehensive EA provides a medium to communicate, inform and educate the vendor community on the direction of the government program’s requirements. If a government program incorporates an EA overview within Requests for Proposals and Requests for Information, then the government program has provided vendors with a blueprint for the program’s future direction and solution. With vendors “on the same page”, the government is likely to receive greater value for its investments.
Evaluation Criteria and Performance Metrics
Performance metrics and evaluation criteria established at the outset of a project will support acquisition lifecycle at solicitation with the RFI/RFP support and with development/testing of the system. Appropriate EA artifacts and descriptions will identify the following information, Table 3, involved in developing an appropriate acquisition strategy that will lead to selection of the qualified Vendor and appropriate solution.
The EA artifacts and descriptions identified in Table 3 will increase the benefits to the acquisition strategy by providing users with a yardstick with which to assess the degree of value; provide guidance to Vendors as to what to build to satisfy requirements; and provide a basis for specifying system requirements in acquisition specifications.
Conclusion
EA’s principles and standards can serve acquisition by streamlining and reducing the complexity of investment decisions. In addition, because Federal EA focuses on obtaining value for government and citizens, it can help increase the value received from government purchases by ensuring the right choices are made and that there is traceability from investments back to the driving strategic intent. This provides government with a way of being accountable, both internally and externally. Over the long term, the EA discipline can be used to reduce complexity through standardization to the point that government will move from stand-alone, stove-piped systems and business processes to integrated, interoperable systems and processes. The overall effect will be the leveraging of resources across government agencies and better managed and more consolidated and cost-effective contracts. Conversely, it is also important to acknowledge that IT acquisition can provide assistance to EA in terms of adding structured transparency to the EA models and data-centric standard setting process, which is important given the large sums of government funds that are invested in IT and the fact that EA standards will likely remain in place for a substantial period of time. This transparency may take the form of a better understanding of the vendor community perspective that will then yield improved competition and foster higher degrees of value for the government in terms of cost and innovation. By creating this type of reciprocal relationship, acquisition and EA can work together to improve the value of investments.
For more information on the role of architecture in business operations, check out my book at https://www.theheartandbrainofyourbusiness.com/
