1. © 2010 Carnegie Mellon University Acquisition Implications of SOA Adoption Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Pat Place May 6, 2010

2. 2 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Goals To discuss the effect that following the SOA development style has on current acquisition policy and to suggest some acquisition experiments to resolve some issues raised by SOA development Caveat: The comments in this report apply to software-only systems and cannot be immediately applied to hardware-intensive systems such as a combat aircraft or a ship

3. 3 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Perspective If SOA systems are to come into existence we must: Examine the engineering needs Compare those needs to what is permitted by acquisition practice When deltas exists either change acquisition or adopt something other than SOA

4. 4 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University SOA Overview SOA-based systems are composed of: Services that represent reusable business functionality Consumers of consumers (could be applications or other services) Well-defined and maintained service interfaces Infrastructure that: – defines protocols for information exchange – provides mechanisms for service discovery, composition, and invocation – provides services of a generic nature An application is a composition of services, infrastructure, and a consumer that provides some useful work Services in the composition may already exist or be newly created

5. 5 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Nature of System From a user perspective, an SOA application should look the same as a traditional system But internally, for the typical traditional system vs. SOA application: Architectural depictions are hierarchic vs. peer-to-peer Implementations of services are separated from the interfaces (which can lead to code that is “outside” the boundary of the application) Service interaction is frequently defined using an orchestration language such as BPEL Services are shared across applications at run time not just design time Services and applications can be developed independent of each other Services and applications are, typically, smaller than systems Given service reuse and independence of development, it is no longer clear that the unit of acquisition should be a system

6. 6 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Issue: Acquisition Programs Must be Lean SOA promises to lead to rapid development: Individual services are relatively small with respect to current systems Services should not take long to develop (one estimate was 6-9 months) Applications are also small The SOA promise of agility will be lost if development: Is burdened by excessive documentation requirements Has many delays before it can begin (e.g., development of perfect requirements and long lead times for securing funding) Has overly complex lines of communication Somehow, acquisitions must move at the same pace as development Acquisition structure will resemble the services being acquired – Small in size – Low budget – Free from administrative overhead

7. 7 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Issue: Qualification Depends on Context Current practice requires that systems are qualified before they operate. Either a system is or is not qualified Services will be used by multiple applications Some of which will not be known when the service is created The context of the application defines qualification needs Thus the qualifications for the service are not fixed A service may have different qualification needs for different contexts There is limited value to qualifying a small unit of functionality on its own Qualifying a service will be different Cannot afford the delays caused by using large-scale test facilities Distributed use suggests distributed qualification (both geographically and temporally)

8. 8 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Issue: System Integration Becomes Application Orchestration Currently, acquisition assumes relative independence of programs Funding, contracting, reporting, and requirements assume a bounded programmatic structure SI often has responsibility for overall concept, design, analysis, testing, and integration and oversees decisions regarding interfaces Government has become the integrator SOA principles (e.g., applications making use of existing services) create dependencies between programs Combinations of services become crucial for applications Role of integrator changes to sequencing existing services

9. 9 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Issue: a New Governance Model is Needed SOA exacerbates the issues related to control, management, and ownership of components Services funded by one organization will be deployed in environments funded by other organizations Answers to the following questions will depend on context – Where does a service execute? – Who operates the service? – Who owns the network? – Who is permitted to use the service? – Is there a fee for use? Governance must answer the above questions and have the same flexibility and agility as service development

10. 10 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Issue: Service Evolution will be Complex A service may be funded by one community but used by others Responsibility for evolution becomes unclear There may be many more users than first envisioned Developer organization will be under continual pressure for changes Unlikely to be just one path of evolution Funding for modifications becomes unclear What should be the source of funding? What if demand for a service requires new hardware? What if demand requires exposure of internals the developers intended to hide? Policy must permit the “owner” of a service to be overruled

11. 11 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Issue: New Incentives are Needed The technology demands changes in acquisition policy System “owners” must be willing to share data It is harder to create a generic service than a specific one Benefits of generic services are not accrued immediately User community for a generic service cannot be known at development time Program manager rewards/promotions need to be rethought

12. 12 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University A New Acquisition Model is Needed ? But what should the model look like?

13. 13 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Proposal: Run Experiments in Acquisition The Application Shop Pilot a Governance Model Pilot a Qualification Process

14. 14 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University The Application Shop Is an acquisition program whose only responsibility is to creating services and applications that may not be known when the program begins A single “acquisition entity” designed to create small projects Divorces the lifecycle of a service/application from an acquisition program Characteristics: Staffed by acquisition experts and system engineers Determines what projects are needed to meet the large scale needs Would be judged by projects initiated and completed, not by milestones known in advance Will provide design-time rules for projects Will provide documentation and test templates for the projects Inwardly very agile Outwardly, guides completed projects (i.e., services and applications) through external hurdles (e.g., certification)

15. 15 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Project Initiation Based on an approved set of “requirements” in a statement of need Burden of requirements development is outside the AppShop Once requirements are accepted Determine what services exist or are needed Determine how to divide needed work into projects Initiate the projects Acceptance of requirements and determination of projects based on sound engineering practices performed by the AppShop

16. 16 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Project Completion Development team delivers code, internal tests, documentation to the AppShop AppShop applies acceptance criteria Coding standards Sufficiency of internal testing Compliance to interface standards AppShop oversees operational testing Use test harnesses for services for which there is not yet an application AppShop performs outward-looking tasks: Negotiates with infrastructure owner Deals with certification

17. 17 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Measures of AppShop Success Indicators of how well the AppShop is serving the user community: Ratio of deployed applications to requested applications Delta between actual deployment and requested deployment schedules Rise and fall of requests Other indicators: Whether or not the AppShops are bringing the DoD closer to net-centricity – For a service, the number of applications or other services using it – For an application, the ratio of service to non-service code – For an application, the number of users – Assessment of the relative importance of the service and its consumers

18. 18 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Piloting SOA governance model Incoming assumptions: Define a new application that requires construction of a new service and also uses an existing service and infrastructure Need a change to the existing service to support the new application Different organizations operate the existing service and infrastructure Constrain the existing service so that there is insufficient budget or schedule for new modifications Goals of the pilot: Determine nature of MOU between different parties Determine how to appropriately use “colors of money” to accommodate the needs of the new application Discover potential incentives for existing owners to accommodate the new application and service

19. 19 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Piloting SOA-Based Qualification Process Incoming assumptions: That a service has already been qualified for one context of use Define a new application that can be created rapidly if it reuses the service but with different QoS needs from existing services Re-qualifying the service will not re-qualification of the existing application Goal of the pilot: Uncover mechanisms for analysis of QoS-based qualification Demonstrate ability to re-qualify a service

20. 20 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Conclusion Change is inevitable if SOA is to be adopted Current acquisition practices are clearly unsuitable for SOA Modifying acquisition must be based on the needs of the technology Much work and research is needed The only way forward is to experiment with acquisitions to see what can be done (e.g., the AppShop)

21. 21 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University Contact Information Slide Format Patrick R.H. Place Senior Member of Technical Staff Research, Technology, and System Solutions Telephone: +1 412-268-7746 Email: prp@sei.cmu.edu U.S. mail: Software Engineering Institute Customer Relations 4500 Fifth Avenue Pittsburgh, PA 15213-2612 USA Web: www.sei.cmu.edu http://www.sei.cmu.edu/contact.cfm Customer Relations Email: info@sei.cmu.edu Telephone: +1 412-268-5800 SEI Phone: +1 412-268-5800 SEI Fax: +1 412-268-6257

22. 22 Acquisition Implications of SOA Adoption Pat Place, 6 May 2010 © 2010 Carnegie Mellon University NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this presentation is not intended in any way to infringe on the rights of the trademark holder. This Presentation may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at permission@sei.cmu.edu.permission@sei.cmu.edu This work was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 252.227-7013.