© 2010 carnegie mellon university acquisition implications of soa adoption software engineering...

© 2010 Carnegie Mellon University

Acquisition Implications of SOA Adoption

Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213

Pat PlaceMay 6, 2010

2

Acquisition Implications of SOA AdoptionPat Place, 6 May 2010


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



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



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



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



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



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



Issue: System Integration Becomes Application OrchestrationCurrently, 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



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



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



Issue: New Incentives are Needed

The technology demands changes in acquisition policySystem “owners” must be willing to share dataIt 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



A New Acquisition Model is Needed

?But what should the model look like?

13



Proposal: Run Experiments in Acquisition

The Application ShopPilot a Governance ModelPilot a Qualification Process

14



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



Project Initiation

Based on an approved set of “requirements” in a statement of needBurden of requirements development is outside the AppShopOnce 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



Project Completion

Development team delivers code, internal tests, documentation to the AppShopAppShop applies acceptance criteria•Coding standards•Sufficiency of internal testing•Compliance to interface standards

AppShop oversees operational testingUse test harnesses for services for which there is not yet an applicationAppShop performs outward-looking tasks:•Negotiates with infrastructure owner•Deals with certification

17



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



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



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



Conclusion

Change is inevitable if SOA is to be adoptedCurrent acquisition practices are clearly unsuitable for SOAModifying acquisition must be based on the needs of the technologyMuch work and research is neededThe only way forward is to experiment with acquisitions to see what can be done (e.g., the AppShop)

21



Contact Information Slide Format

Patrick R.H. PlaceSenior Member of Technical StaffResearch, Technology, and System SolutionsTelephone: +1 412-268-7746Email: [email protected]

U.S. mail:Software Engineering InstituteCustomer Relations4500 Fifth AvenuePittsburgh, PA 15213-2612USA

Web:www.sei.cmu.eduhttp://www.sei.cmu.edu/contact.cfm

Customer RelationsEmail: [email protected]: +1 412-268-5800SEI Phone: +1 412-268-5800SEI Fax: +1 412-268-6257

22



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 [email protected].

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.

mailto:[email protected]

© 2010 carnegie mellon university acquisition implications of soa adoption software engineering...

Documents

soa systems

soa slide

soa application

lean soa

soa development style

soa development caveat

composition of services

acquisition programs