Difference between revisions of "Acquisition"

Latest revision as of 02:14, 23 December 2017

Welcome to the initial version of the EITBOK wiki. Like all wikis, it is a work in progress and may contain errors. We welcome feedback, edits, and real-world examples. Click here for instructions about how to send us feedback.

1 Introduction

As indicated in the Change Initiatives chapter, there are many reasons to consider outsourcing, including potentially reducing costs or avoiding capital expenditures, speed to market, resource flexibility, and a lack of internal expertise. Outsourcing is also called acquisition. Acquisition may involve hardware components, hardware systems, software components, software systems, or any combination of hardware and software, including turnkey systems.

Acquisition is the process of obtaining a system, product, or service and ensuring its successful implementation, whether the supplies or services already exist or must be created, developed, demonstrated, and evaluated (ISO/IEC/IEEE 12207:2008 [1] and ISO/IEC/IEEE15288:2008 [2]). Acquisition also includes ensuring that proper mechanisms are in place to monitor the performance of the supplier/vendor in providing support and fulfilling other contractual obligations.

The first task, already accomplished in the EIT planning stages, was to do the analysis necessary to determine if acquisition of a needed product or service is preferable to creating it in-house. This is often called a buy or build decision. It provides information about acquisition options (outsourcing models), contracting for acquisitions, resource management, and key elements to be accounted for in implementing the acquisition. The buy/build decision is made after a strategic direction has been set, during the definition of change initiative projects. An acquisition requires a project of its own, which may be embedded in a larger project.

Generally, the EITBOK assumes that the build/buy decision has been made during the definition of change initiatives described in the Change Initiatives chapter. This chapter focuses on the ensuing activities to implement a buy decision. This chapter provides an overview of key activities associated with acquisition including determining whether an enterprise should purchase or build a solution in-house, planning for the acquisition, selecting the type of solution, and contracting for the solution.

After an organization has analyzed the need for a system and decided to acquire it rather than develop it in-house, acquisition planning begins. The acquisition strategy includes a description of what needs to be acquired as well as the estimated implementation timeframe and cost. It also includes a plan for whether the acquirer, the supplier, or a third party is operating and maintaining the system.

During the planning phase, the acquiring organization lays out the activities it must perform to acquire the system. It also further refines the system requirements, including performance, functional requirements, and non-functional requirements. The organization considers the desired parameters for the contract with the supplier. As with requirements in other contexts, performance requirements specify technical attributes for the system (such as response time or processor speed), functional requirements identify what the system should do, and non-functional requirements stipulate certain quality attributes (such as reliability or maintainability). Contractual requirements lay out the respective responsibilities of the supplier and the acquirer, as well as costs and schedules, bonus conditions, and penalty conditions.

2 Goals and Guiding Principles

The goals of acquisition are:

• Select vendors and solutions to achieve best performance and least risk to the organization as a result of planned EIT service change.
• Support the business need and EIT solution selection process through contract negotiation, monitoring, and management during acquisition.

There are also three subgoals for acquisition:

• Ensure that any decision to acquire a technology component or solution is the most appropriate in the situation at hand.
• Verify that a provider is selected by evaluating their capabilities against the project's most salient criteria.
• Ensure that the conditions of acquisition appropriately provide for its successful implementation and support.

These are the principles that guide effective acquisition:

• Best value for purpose—The acquired solution should fulfill the requirements. However, the technical allure of "bells and whistles" often tempts the acquirer to buy more than needed.
• Fairness, integrity, and transparency—The contract should be fair to both parties, and should provide adequate mechanisms for each party to track the other's compliance with the contract. Each should avoid practices intended to take undue advantage of others or the system.
• Importance of effective competition—Effective competition exists when two or more competing offerings are judged solely on their merits, and they acting solely on their own behalf, without collusion.
• Separation of duties to attain checks and balances—Both the acquirer and the supplier should ensure that no conflicts of interest on either side skew the acquisition process.
• Environmental consideration—Many EIT organizations are increasingly conscious of the impact of their purchasing decisions on the environment, as well as the rising costs of energy consumption.

3 Context Diagram

Figure 1. Context Diagram for Acquisition

4 Analysis of Acquisition Feasibility

Various analysis techniques are used to evaluate the feasibility of a particular solution. In this sense, analysis is a careful, formal assessment of how things stand today, with the objective of making good decisions about how to move forward.

4.1 Definitions of Requirements and Customer Needs

System requirements are discussed in detail in the Requirements chapter. All of the considerations presented in that chapter apply when acquisition is being considered.

Security should be a major consideration from the beginning of any acquisition project. In order to do due diligence with regard to ensuring security in acquired products and services, it is sometimes necessary to perform an audit of the facilities and work processes of a proposed vendor/supplier. See the Security chapter for more information specific to security.

In order for any acquisition effort to be successful, it is imperative that the enterprise's and project's requirements and constraints be well understood by these parties:

• Persons writing the request for a proposal or request for a bid
• Vendor evaluators
• Contract writers
• Vendors
• Bidders

4.2 Candidate Tools/Products

A detailed business case produced during the build/buy decision process provides a reasonable idea of the magnitude of the project. In addition, the business impact analysis (BIA) provides an indication of constraints that the selected vendor must accommodate. Both of these inputs need to be considered in devising the framework for evaluating vendors.

By scanning the vendor environment, it's possible to come up with a list of candidate tools, products, or service providers. One common way to narrow down the list of possible vendors is to create an evaluation matrix. One axis contains the most salient requirements and the other axis lists the vendors. As the vendors' capabilities are discovered, the matrix is filled in, either with +/- to indicate presence or absence, or with a numerical value to indicate how strongly a condition (requirement) is satisfied.

4.3 Analysis of Alternatives

Requirements can be of several types (e.g., customer requirements, product requirements, product component requirements), and each type can address functional and non-functional considerations. That said, it is always possible that what the buyer (the enterprise or a particular department) says is needed is not actually needed—but they want it. When faced with this type of situation, use the Analysis of Alternatives techniques to focus on the mission that the desired procurement is meant to serve. That often helps eliminate unnecessary frills.

As lifecycle costs and risks—as well as the ultimate goals of the project or program—are considered, alternatives must also be considered when enhancing a project or program. This is called Analysis of Alternatives (AoA). The U.S. Air Force's Analysis of Alternative (AoA) Handbook [3] is one source for more information on the AoA method.

The AoA has several objectives:

1. Qualify and refine alternatives
2. Refine criteria requirements culled from input documents
3. Refine evaluation matrix/criteria
4. Work to gain consensus
5. Reduce uncertainty about the qualifications of vendors and their products
6. Result in the choice of an alternative

AoA requires the consideration of important feasibility factors, such as technology maturity, integration risk, manufacturing feasibility, and, where necessary, supplier maturation (including reliability of performance). It should consider such factors as threat scenarios, operating environment, operations concept, measures of performance, and lifecycle costs.

4.4 Reference Architectures

A reference architecture is used to guide and constrain instantiation of a solution architecture. In its broadest sense, an organization's reference architecture is the technology infrastructure that is already in place, which the new solution must fit into. Thus, the reference architecture presents a set of operational requirements and constraints that must be taken into consideration in evaluating vendors' products.

Reference architectures emphasize commonality, providing a shared vocabulary and a template solution in a particular domain. A technical reference architecture provides a basis for ensuring consistency and applicability of technology within an enterprise. It usually displays the functions and application programming interfaces (APIs) in use, as well as an indication of functions outside the scope of the particular architecture. It provides the framework for a family of software systems, and may include hardware components.

The Zachman Framework for defining an enterprise, TOGAF, [4] and DoDAF [5] are common architectures currently used by the EIT community; however, many (perhaps most) organizations have developed their own reference architectures over time. When contemplating the acquisition of a new capability, it is essential to understand how the proposed capability can be integrated into the existing framework.

4.5 Risks and Constraints

Risk is the probability of damage, injury, liability, loss, or any other negative occurrence. It has two vectors: degree of probability that it will occur, and degree of damage it will cause if it occurs. Selecting any outside vendor involves evaluating the risks that the vendor and the vendor's technology bring to the acquiring organization.

Elements of risk—risk factors—associated with each vendor and product should be identified in advance, before the project starts, and can be reduced or contained by appropriate project management planning. Here are some common elements of risk:

• Lack of vendor track record
• Vendor track record of not delivering on time
• Vendor product stability
• Overstated product capability

When risk factors are recognized in advance, they can be managed. Options for managing them can be evaluated, and the most appropriate options can be selected. There are four approaches to risk management:

• Avoidance (also called elimination)—Removing the risk factor. This may mean eliminating the alternative.
• Control (also called reduction)—Reducing the chances that the risk factor has an impact or reducing the impacts. For example, the acquirer may require certain types of testing and results that meet predefined limits.
• Transference—Transferring the exposure to the vendor. It is common to transfer the financial consequences of loss exposure by imposing penalties if deadlines are not met, for example.
• Retention—Retaining a loss exposure means accepting (rather than transferring) the consequences if the loss occurs. This is usually accomplished by a form of self-insurance—setting aside a contingency reserve (a budget reserve or schedule buffer) to be used, if needed. In addition, it can involve establishing backup in-house skills or vendor skills that can perform any needed corrective work.

Risks should not be confused with constraints. A constraint is something known (or at least knowable) that imposes a restriction. Constraints can include available resources, deadlines, organizational issues, and access to persons knowledgeable about the specific applications involved. They are boundaries to the "space" you are allocated to operate in when defining the specifications for an acquisition.

4.6 Procurement Policies and Procedures

EIT procurement activities are bounded by enterprise policies and procedures. These activities involve both strategic and administrative responsibilities, and they cross many organizational boundaries. In order to make sure that each department plays by the same rules in handling procurements and doesn't break any laws or financial restrictions, an organization usually creates policies about what approvals are necessary for purchases along with the financial limits of signature authorities. In addition, policies control the creation and management of requests for quotations (RFQs), requests for proposals (RFPs), requests for information (RFIs), and managing supplier relationships. Day-to-day tasks may include conducting market research, negotiating pricing, establishing terms and conditions for services, resolving invoice discrepancies, and communicating the status of purchases with internal customers.

5 Acquisition Strategy and Outsourcing Models

An organization's acquisition strategy often drives the selection and use of outsourcing models. The acquisition strategy serves as a roadmap for the acquisition portion of the investment lifecycle. It describes the overall approach for acquiring the capabilities needed to fulfill the objectives established in strategic planning and the definition of change initiatives.

5.1 Commonly Used Resource Options

The subsections below describe several commonly used outsourcing options. Each option carries its own risks, and each requires the acquiring organization to manage the vendor to ensure that it meets its contractual obligations. Whichever sourcing strategy an organization chooses should leave room for negotiations between the acquirer and the supplier.

5.1.1 Software as a Service (SaaS)

When an acquiring organization subscribes to a software as a service (SaaS) solution, the supplier provides remote access to a software-intensive EIT product on a subscription basis. While this seems the simplest approach, it requires a lot of research to make sure that the service works well within the built EIT environment, for example, that it can "talk" to all relevant in-house systems and share information as needed. It also requires very careful development of a contract, to ensure that up-time and other quality attributes are provided.

5.1.2 Turnkey

In many ways, this is the simplest solution. In its ideal form, a turnkey solution arrives ready to be smoothly inserted into current business processes. This approach assumes business and operational readiness to receive and implement the solution. The question of whose responsibility it is to get the customer ready to use the solution is often an open issue. The acquisition strategy must therefore include assignment of responsibilities for ensuring business and operational readiness to accept the new capability, and for installation, verification and validation, and cut-over. (See the Transition into Operation chapter for more information.) The strategy must also address maintenance and defect issues.

5.1.3 Single Vendor

The single-vendor approach is just what it sounds like—one vendor supplies the desired system or service to the acquiring organization. While this approach can reduce risk and confusion, it may not provide the most cost-effective or richly featured solution. However, when it does meet all the requirements of the solution and of the contractual framework, this can be an ideal situation.

An inherent danger of single-vendor acquisitions is that the acquiring organization is often susceptible to becoming too comfortable with that vendor, because the vendor may have become too comfortably embedded in the enterprise's operations, its present environment, and its long-term goals. Familiarity with a vendor can lead to subsequent selections of the same vendor, because it seems a much lower career risk to the EIT managers who are responsible for the decision. The result of familiarity is often that newer and improved products and services are overlooked.

5.1.4 Multiple Vendors

In the multiple-vendor approach, an organization combines products and services from a blend of external providers to meet its needs. While this approach can seem most cost-effective, managing a spider web environment of multiple vendors can be challenging, especially when multiple vendors have to be managed and multiple pieces of an acquisition need to be updated to stay in sync. It leads to extra work for the EIT organization. Here are some examples:

• Matching vendor capabilities to the other vendors correctly.
• Managing each vendor's contract.
• Accommodating differing schedules for updates.
• Getting bug ownership clarified and injecting bug fixes from multiple sources, and can lead to confusion for customers and inconsistent quality of service delivery.
• In addition, this acquisition strategy may necessitate a provision for collecting data from the various vendor system components and creating a centralized repository.

5.2 Procurement

The processes used in establishing and managing contracts with third-party service providers have become fairly standardized, especially across larger buying organizations, and include the documents described below. It is important to ask for—and check—references. The same format for each of these should be sent to prospective vendors, so that they can be compared more easily:

• Request for information (RFI)—The RFI is a request for more information about a given product or service. The vendor comparison matrix that lists the requirements for the intended solution can be used to formulate the request.
• Request for quote (RFQ) (also called invitation for bid)—The RFQ is used to invite potential suppliers into a bidding process for a specific product or service. It generally follows the RFI, but if sufficient information exists to create a detailed RFQ, the RFI may be skipped.
• Request for tenders (RFT)—Like the RFQ, the RFT invites qualified suppliers or contractors to submit sealed bids for supplying specific and clearly defined goods or services during a specified timeframe.
• Request for proposal (RFP)—The RFP is used in sealed-bid procurement procedures, advising potential suppliers of these factors:
  
  • Scope of work (a statement of work)
  • Description of goods and services to be procured
  • Sufficient specifications to enable an accurate bid
  • Required schedules or timelines
  • Contract type (cost-plus, fixed fee, and so on)
  • Supporting data requirements
  • Contract terms and conditions
  • General criteria used in evaluation procedure
  • Instructions for preparing and submitting technical, management, and cost proposals
  RFPs are publicly advertised and suppliers respond with a detailed proposal, not just a price quotation. They provide for negotiations after sealed proposals are opened, and the award of the contract may not necessarily go to the lowest bidder.

For links to examples for each of these, read more at http://www.businessdictionary.com/.

Organizational infrastructure and negotiation skills are needed to effectively implement these processes. The EIT organization may not have the necessary skills internally to write the requests or evaluate the responses, and so should work with the corporate services that do have the skills and experience, assuming that they are available. If such resources are not available, careful research into these procurement instruments is required.

6 Contracting

A contract is an agreement between a supplier (seller) and an acquirer (buyer). At a minimum, the contract for the final selection must include specifications for the following items, and should mirror any statement of work used in previous communication with the vendor:

• Bill of materials (BOM)—A list and description of exactly what will be delivered.
• Supplier management—A description of exactly how and by whom the supplier will be managed.
• Invoice management—A specification of when and how invoices will be received, tracked, and paid.

Here are some additional considerations for framing a contract to acquire products, components, or services:

• Ownership of delivered intellectual property, technology, and methods—It is important to define in the contract where the ownership of intellectual property resides at the completion of the contract. Items that are procured off the shelf retain the makers' copyrights and trademarks unless stipulated otherwise. Items that are created specifically for the contract are "work for hire" and their associated IP belongs to the acquirer. Physical items that are purchased belong to the acquirer, but items that are leased belong to the supplier.
• Identification of changes and change management—In general, minimize the number of contract alterations, but be sure to specify any known changes or extensions required with regard to the vendor-supplied components, such as APIs, user interfaces, or equipment tolerances. Any changes that are identified during the project should be subject to the acquirer's normal change management processes, both financial and technical. If changes are required to the existing infrastructure, include the acquirer's change control board in the approval process.
• Identification of software and hardware integration concerns—The acquiring organization should identify at least two potential critical issues that could arise when integrating vendor software at the contract level, to ensure that these areas are monitored throughout the process.
• Identification of integration concerns—The contract should explicitly identify all interface requirements between the vendor-provided business application and the existing organizational infrastructure.
• Identification of data needs—The process for moving data out of an old system and into the acquired new system should also be clearly outlined in the contract. Requirements for data exchange with other systems should be clearly defined.
• Provision for Rollback—If things don't go as expected, it's important to have a provision for rollback, or returning the system to a previously defined state.
• Communication strategy and planning—The contract should explicitly explain how communications regarding the project work, including who is the single point of contact (SPOC) for the supplier and the SPOC for the acquirer, as well as when specific communications (e.g., monthly performance reports) must occur.
• Coordinating delivery schedules with business/EIT schedules—Coordinate delivery schedules with business/EIT schedules with integrated project delivery approaches. See the chapter on Transition into Operation for more information.
• Handoff to receiving organizations—When the supplier moves the responsibility for the system to the acquirer (the EIT organization), the process is called handover, handoff, or transition. The terms and conditions of the handover should be clearly specified in the contract. See the Transition into Operation chapter for more detail.
  Handoff to the receiving organization must have the agreement of the receiver that the system is acceptable for use and meets the terms of the contract. See the Transition into Operation chapter for more detail. Contract considerations include:
  
  • Verification of implementation against requirements and contractual obligations—When the solution has been delivered, measure it against the contract to verify that everything has been done—and done properly. This contract quality surveillance is the responsibility of the acquiring organization in most cases, as it is most familiar with the requirement and implementation details.
  • Issue resolution and responsiveness to issues —Although bug fixes may be the most common support need, other types of errors also need to be accounted for, such as requirements, architectural, or design flaws. The contract must specify how problem reports are handled. See the Sustainment chapter for more information on this subject.
  • System, product, or service acceptance—Acceptance is the stage of initial development wherein the system, product, or service is put into production and runs real business functions. During this phase, the solution is monitored to ascertain whether it meets the original business requirements and objectives and whether it functions according to expectations, as well as to assess its reliability, fault tolerance, and freedom from vulnerabilities.
• System, product, or service follow-on—No solution lasts forever—even during acquisition, it is important to plan for maintenance, upgrades, and ultimately retirement and replacement. If the contract is for products, it should specify the supplier's responsibilities for service after acceptance. Responsibilities can include update/refresh schedules, notification of new capabilities, and so on. For more information about the activities involved, see the Sustainment in Operation and Transition into Operation chapters.
• Resource management—Eventually the supplier transfers the product or service to the acquiring organization. The acquisition plan needs to address what the supplier's obligations are for providing resources during the transition to operation and what responsibilities lie with the acquirer. Refer to the Transition into Operation chapter for more details.
  Resource management as it pertains to acquisition activities addresses such issues as:
  
  • How the necessary technical knowledge needed to operate and maintain the system is transferred to the EIT organization personnel
  • How any necessary workforce development (employee training, certification, etc.) is achieved
  • Ensuring that required processes are in place to support internal ownership of the acquired system
  The teams who receive the new solution, including operations and maintenance personnel, need to be trained on its use and any tools needed for support, and on the processes to be used to support and maintain the system. The contract should provide for appropriate education and training for impacted staff. It should also specify the problem reporting, problem resolution, and contract monitoring processes used. It is critical to the efficacy of the acquisition to monitor contractor performance to ensure that the supplier remains accountable for performing as specified (or better) in the contract.

7 Summary

Acquisition is a multi-faceted activity that occurs after a build/buy decision has been made. The acquisition process entails all of the management activities required in any project. In other words, each acquisition of an EIT product and services solution requires its own project. It requires understanding the business problem to be solved, or the opportunity to be captured, architecting a solution, managing its implementation and delivery, and ensuring its fitness for use.

In addition to the management activities required when developing an in-house solution, acquisition requires expertise in contract definition, negotiation with vendors, vendor management, and analysis of risks beyond those associated with in-house development.

8 Key Maturity Frameworks

Capability maturity for EIT refers to its ability to reliably perform. Maturity is measured by an organization's readiness and capability expressed through its people, processes, data, technologies, and the consistent measurement practices that are in place. See Appendix F for additional information about maturity frameworks.

Many specialized frameworks have been developed since the original Capability Maturity Model (CMM) that was developed by the Software Engineering Institute in the late 1980s. This section describes how some of those apply to the activities described in this chapter.

8.1 IT-Capability Maturity Framework (IT-CMF)

The IT-CMF was developed by the Innovation Value Institute in Ireland. This framework helps organizations to measure, develop, and monitor their EIT capability maturity progression. It consists of 35 EIT management capabilities that are organized into four macro capabilities:

• Managing EIT like a business
• Managing the EIT budget
• Managing the EIT capability
• Managing EIT for business value

The two most relevant critical capabilities are sourcing (SRC) and supplier management (SUM).

8.1.1 Sourcing Maturity

The following statements provide a high-level overview of the sourcing (SRC) capability at successive levels of maturity.

8.1.2 Supplier Management Maturity

The following statements provide a high-level overview of the supplier management (SUM) capability at successive levels of maturity.

9 Key Competence Frameworks

While many large companies have defined their own sets of skills for purposes of talent management (to recruit, retain, and further develop the highest quality staff members that they can find, afford and hire), the advancement of EIT professionalism will require common definitions of EIT skills that can be used not just across enterprises, but also across countries. We have selected three major sources of skill definitions. While none of them is used universally, they provide a good cross-section of options.

Creating mappings between these frameworks and our chapters is challenging, because they come from different perspectives and have different goals. There is rarely a 100 percent correspondence between the frameworks and our chapters, and, despite careful consideration some subjectivity was used to create the mappings. Please take that in consideration as you review them.

9.1 Skills Framework for the Information Age

The Skills Framework for the Information Age (SFIA) has defined nearly 100 skills. SFIA describes seven levels of competency that can be applied to each skill. However, not all skills cover all seven levels. Some reach only partially up the seven-step ladder. Others are based on mastering foundational skills, and start at the fourth or fifth level of competency. SFIA is used in nearly 200 countries, from Britain to South Africa, South America, to the Pacific Rim, to the United States. (http://www.sfia-online.org)

9.2 European Competency Framework

The European Union's European e-Competence Framework (e-CF) has 40 competences and is used by a large number of companies, qualification providers, and others in public and private sectors across the EU. It uses five levels of competence proficiency (e-1 to e-5). No competence is subject to all five levels.

The e-CF is published and legally owned by CEN, the European Committee for Standardization, and its National Member Bodies (www.cen.eu). Its creation and maintenance has been co-financed and politically supported by the European Commission, in particular, DG (Directorate General) Enterprise and Industry, with contributions from the EU ICT multi-stakeholder community, to support competitiveness, innovation, and job creation in European industry. The Commission works on a number of initiatives to boost ICT skills in the workforce. Version 1.0 to 3.0 were published as CEN Workshop Agreements (CWA). The e-CF 3.0 CWA 16234-1 was published as an official European Norm (EN), EN 16234-1. For complete information, see http://www.ecompetences.eu.

9.3 i Competency Dictionary

The Information Technology Promotion Agency (IPA) of Japan has developed the i Competency Dictionary (iCD) and translated it into English, and describes it at https://www.ipa.go.jp/english/humandev/icd.html. The iCD is an extensive skills and tasks database, used in Japan and southeast Asian countries. It establishes a taxonomy of tasks and the skills required to perform the tasks. The IPA is also responsible for the Information Technology Engineers Examination (ITEE), which has grown into one of the largest scale national examinations in Japan, with approximately 600,000 applicants each year.

The iCD consists of a Task Dictionary and a Skill Dictionary. Skills for a specific task are identified via a "Task x Skill" table. (See Appendix A for the task layer and skill layer structures.) EITBOK activities in each chapter require several tasks in the Task Dictionary.

The table below shows a sample task from iCD Task Dictionary Layer 2 (with Layer 1 in parentheses) that corresponds to activities in this chapter. It also shows the Layer 2 (Skill Classification), Layer 3 (Skill Item), and Layer 4 (knowledge item from the IPA Body of Knowledge) prerequisite skills associated with the sample task, as identified by the Task x Skill Table of the iCD Skill Dictionary. The complete iCD Task Dictionary (Layer 1-4) and Skill Dictionary (Layer 1-4) can be obtained by returning the request form provided at http://www.ipa.go.jp/english/humandev/icd.html.

10 Key Roles

• Architecture team [6]
• [Organizational] Change manager
• Procurement manager
• Product manager
• Service portfolio manager
• Service strategy manager
• Service owner
• Solution manager

Other key roles are:

• Business Analyst
• Project Manager
• User Experience Team

11 Standards

IEEE 1062:2015, IEEE Recommended Practice for Software Acquisition

ISO/IEC 12207:2016, Systems and software engineering—Software lifecycle processes (in preparation)

ISO/IEC 15288:2015, Systems and software engineering—System lifecycle processes

ISO/IEC 27036, Information technology—Security techniques—Information security for supplier relationships (3 parts)

ISO/IEC/IEEE 26512:2011, Systems and software engineering—Requirements for acquirers and suppliers of user documentation

ISO/TS 22318:2015, Societal security—Business continuity management systems—Guidelines for supply chain continuity

12 References

[1] U.S. Air Force, Analysis of Alternative (AoA) Handbook: A Practical Guide to Analysis of Alternatives, Air Force Materiel Command Office of Aerospace Studies, 2010; http://www.prim.osd.mil/Documents/AoA_Handbook.pdf.

[2] J. Zachman, The Zachman Framework, Zachman International, Inc., 2008; http://www.zachman.com.

[3] TOGAF, version 9.1, The Open Group, 2011; http://www.opengroup.org/togaf.