Date post: | 16-Dec-2015 |
Category: |
Documents |
Upload: | brittney-butler |
View: | 219 times |
Download: | 0 times |
© 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
© 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
Acquisition Implications of SOA AdoptionPat 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
Acquisition Implications of SOA AdoptionPat 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
Acquisition Implications of SOA AdoptionPat 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
Acquisition Implications of SOA AdoptionPat 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
Acquisition Implications of SOA AdoptionPat 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
Acquisition Implications of SOA AdoptionPat Place, 6 May 2010
© 2010 Carnegie Mellon University
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
Acquisition Implications of SOA AdoptionPat 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
Acquisition Implications of SOA AdoptionPat 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
Acquisition Implications of SOA AdoptionPat Place, 6 May 2010
© 2010 Carnegie Mellon University
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
Acquisition Implications of SOA AdoptionPat Place, 6 May 2010
© 2010 Carnegie Mellon University
A New Acquisition Model is Needed
?But what should the model look like?
13
Acquisition Implications of SOA AdoptionPat Place, 6 May 2010
© 2010 Carnegie Mellon University
Proposal: Run Experiments in Acquisition
The Application ShopPilot a Governance ModelPilot a Qualification Process
14
Acquisition Implications of SOA AdoptionPat 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
Acquisition Implications of SOA AdoptionPat Place, 6 May 2010
© 2010 Carnegie Mellon University
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
Acquisition Implications of SOA AdoptionPat Place, 6 May 2010
© 2010 Carnegie Mellon University
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
Acquisition Implications of SOA AdoptionPat 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
Acquisition Implications of SOA AdoptionPat 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
Acquisition Implications of SOA AdoptionPat 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
Acquisition Implications of SOA AdoptionPat Place, 6 May 2010
© 2010 Carnegie Mellon University
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
Acquisition Implications of SOA AdoptionPat Place, 6 May 2010
© 2010 Carnegie Mellon University
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
Acquisition Implications of SOA AdoptionPat 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 [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.