SOA Architecture Delivery Process

1. SOA ArchitectureDelivery Process by Dr. Robert Marcus robert.marcus@sri.com 720-352-0784 SRI International 1100 Wilson Boulevard Arlington, VA 22209

2. Problems with Enterprise SOA • Enterprise standards groups get rewarded for developing standards and potential reusable resources • Organizational projects get rewarded for delivering required functionality under budget and within schedule • These two goals can incompatible if the use of standards and reusable resources does not provide benefits to projects • These problems have been called out by a recent GAO report on the GIG and are not unique to SOA

3. Proposed Solution • Create a reusable architecture standards delivery group and process • This group should be compensated equally for getting standards implemented and having projects succeed • The process will consist of injecting standards and reusable components into the system life cycle when appropriate • Feedback from projects will be used to revise and improve standards and create new reusable components • The following slides are based on experience within the world’s largest corporation and the world’s largest aerospace company.

4. Architecture Delivery Process 2. Technology Development 1.Concept Refinement 3.System Development and Demonstration 5. Operations And Support 4. Production and Deployment Projects Architecture Delivery Group Standard Reusable Technology Components And Services Standard Models, Existing Testbeds And Simulations Existing Hosting Centers and Platforms Reusable System Management Tools and Processes Standard Reusable CONOPS Centralized Resources Up arrows are delivered standards. Down arrows are improvements based on experience

5. Architecture Delivery Team’s Role • 1. Concept Refinement <-> Reusable CONOPS • 2. Technology Development <-> Reusable standards, components and services • 3. System Development and Demonstration <-> Standard models, existing testbeds, and simulations • 4. Production and Deployment <-> Existing Hosting Centers and Platforms • 5. Operations and Support <-> Reusable System Management Tools and Processes • Experience – These teams have been used to deliver object, middleware and Web frameworks to multiple projects within enterprises

6. 1. Concept Refinement • Whenever possible Concepts of Operations should be reused or incrementally refined for new systems to enable collaboration with existing organizations and easy migration from existing operational procedures. • If radically improved Concepts of Operations are required or enabled with new technology, these new concepts should be incorporated in future operational processes. • Experience: Create reusable scenarios that can be customized and used to drive downstream tasks

7. 2. Technology Development • Reusable components and services should be used whenever possible. Standards should be followed if they do not negatively impact project successful completion. • Standards should be classified with respect to maturity. Immature standards should not be required. Feedback from projects should be used to determine new standards and update the status of existing standards • Experience: Maintain a Web accessible site for retrieving the current status and points of contacts for reusable services and components

8. 3. System Development/Demonstration • Reusable standard models and simulations should be used in the development and testing of new systems. If possible, testbeds should be maintained to help in the evaluation of new systems • When new system models and simulations are needed, they should be incorporated into the testbeds for use with future systems • Experience: Establish a testing center where new services and standards can be evaluated in simulated production environments

9. 4. Production and Deployment • Whenever possible existing platforms and hosting centers should be reused and extended for the production and deployment of new systems • If new platforms and hosting centers are required to deploy a system, then these resources should be available for future new systems. • Experience: Use enterprise hosting centers for the deployment and management of widely shared services

10. 5. System Operations and Support • Reusable processes based on standard tools should be the basis of system operations and support • Additional processes and tools that become necessary to handle new systems should be incorporated into future operations standards • Experience: Enterprise-wide frameworks in key infrastructure areas (e.g. information assurance) should be established to reduce the risks and costs of interoperability problems. These frameworks should be created using federation across diverse organizations rather than a single top-down approach.

11. Reusable Resource Repository

12. Reusable Resource Repository • Stores information about the functionality, retrieval, and use of reusable resources • Maintained by the Architecture Delivery Team • Contains inputs from the Centralized Standards Group and suggested additions from the Project Teams • Repository can be accessed through the Web • Resources in the Repository are indexed by the stages in the System Life Cycle • Experience: Unless there is a group that can support the retrieval and use of components in the repository, it is very difficult to enforce reuse.

13. Reusable Resource Repository Project 1 SOA Architecture Delivery Team Centralized Standards and Reuse Organization Project 2 Project 3 Project 4 Reusable Resource Repository

14. Reference Publications • “Great Global Grid: Emerging Technology Strategies” Downloadable book at http://www.great-global-grid.com • “Transitioning Large Organizations to Object Technology” chapter in CRC Handbook on Object Technology http://www.arrakis.es/~devis/handbook/ • “DoD Management Approach and Processes Not Well-suited to Support the Development of the Global Information Grid” http://www.gao.gov/new.items/d06211.pdf