soa implementation and testing summary n.
Skip this Video
Loading SlideShow in 5 Seconds..
SOA Implementation and Testing Summary PowerPoint Presentation
Download Presentation
SOA Implementation and Testing Summary

SOA Implementation and Testing Summary

322 Views Download Presentation
Download Presentation

SOA Implementation and Testing Summary

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. SOA Implementation and Testing Summary Track 3, 1pm Wednesday Cory Casanave, Data Access Technologies, Inc

  2. Focus:SOA in the real world • We are not solving “little problems”, how can SOA address real-world problems? • A users perspective • What SOA will do for me. • Approach to applying SOA. • Lessons learned. • Beyond SOA hype and technology

  3. SOA for GSA’s Financial Line of Business • Chris Smith, GSA Director of Financial Management Systems • GSA Finance has developed an SOA to support • Enterprise transformation to a line of business • Evolution of I.T. Infrastructure • Better integration within GSA and externally • Model based acquisition • Chris will provide a business perspective on SOA and Enterprise Architecture

  4. SOA for the Defense Modeling and Simulation Office • Doug Clark, DMSO/GARD Associates • John James & Larry Pizette, MITRE • SOA in the M&S Domain • Why SOA • Governance & Business Case • SOA & Middleware • Infrastructure • Reuse • Adoption and challenges

  5. Bringing Semantics to Service-Oriented Architecture • Dean Allemang, TopQuadrent • Ontology-based Mediation for eGovernment • Ontology support for SOA • Semantics and Enterprise Architecture • Semantic Mediation • Realtime EA

  6. Common Concerns for Applying SOA And putting users in control of it

  7. Architecture in the large • We are not concerned with “a service” but how a network of services work together to solve our problems and the problems of the communities we participate in. • This provides context and semantics for the services. • We have to understand Service Oriented Architecture as well as the “Architecture of Services” ™. • How to approach and integrate our enterprise architecture and SOA is of key concern.

  8. Business and Technology • SOA can’t be just another middleware technology and solve any real problems, we have to understand how it fits with our enterprise, department and mission. • SOA is as much a business concept (including government and defense) as a technology concept, understanding communities and organizations as agile interrelated services. • The SOA technologies need to be architected to serve these business needs. • Business stakeholders need to “own” their architecture, not be subject to the processes imposed by vendors. • Key to SOA success is bringing business and technology together.

  9. Transformation & Governance • The business transformation implied by SOA is more daunting than any of the technical issues. • How do we govern the SOA process, create consensus and elicit management support? • How do we help foster the business changes needed for the kind of agility SOA can offer? • Who does business architecture? • Architecture requires involved participants, how do we get everybody from top management to staff involved in the process? • Big bang doesn’t work, how do we do this incrementally?

  10. Show me! • There are a lot of promises for benefits, have these been realized? • Has anyone really done this at federal government scale? • Is there any other organization at the federal government scale? • Are we early in the process to know? • What does it really cost? • Are there industry benchmarks for benefit? • What are the best practices?

  11. How does SOA work with legacy and COTS? • Sure, they may expose a service – but they will be monolithic inside – is this really SOA? • What does it make sense to expose as services? • Can Legacy & COTS be “retrofitted” to be SOA? • How do we get existing applications to use services? • Who owns the data?

  12. The Federal Enterprise Architecture • The FEA is becoming the architectural framework for the federal government. • How does this relate to SOA? • How can we achieve agility while still living within a government wide framework? • What does an SOA architecture at this scale look like?

  13. Model Based Procurement Current Strategic Analyze Requirements against or Create BA Order & Requirements Service Component Reuse Library SOA Architecture Fund/Contract Component Component Fund/Contract Generate Adapt Construct Fund/Contract Fund/Contract Reuse Elaborate Services Contractor Design Implement Test SC Integration Testing Solution Solution

  14. SOA is about Communities Collaborating • Communities • Large communities, spanning the globe • Small communities in an organization or coalition • Even a small department, working together • Collaboration is the key • Modern government, defense and business is about collaboration – joint missions, supply chains and group efforts • SOA as an enabler • SOA can be an enabler for participants in these communities to work together for mutual and individual value. How do we relate the architectures and technologies to achieve community collaboration?

  15. People, Components & Organizations Collaborating Role Role Enterprise Component Service Interface Enterprise Component Role Service Interface Service Interface Enterprise Component

  16. Enterprise Component Enterprise Component Enterprise [Web] Service Enterprise [Web] Service “All that Technology” & Complexity UI Client Tier Browser UI Server Tier UI Framework Business Logic Middleware Wrapper Enterprise Component Adaptation Legacy Systems DBMS Data Managers Containers

  17. The new shape of applications Bridged Monoliths Network of Service Providers and Consumers

  18. Model What You Simulate & Perform Validation & Metrics SOA Architecture Process & Information Validation & Metrics Execution Simulation Management Information SOA World M&S World

  19. Getting value from Architecture • Architectures, like SOA, are moving from dead paper documents to living representations of our organizations and technologies • They need to be “executable”, if you can’t execute your architecture – what do you do with it? • Driving the technical solutions from the business perspective. • Acquiring solutions that fit into your architecture. • Deriving value from the effort of the architecture – technical specifications, model based acquisition, workflow, planning. • Is SOA the key to getting value from architecture?

  20. So Please Join or Session SOA Implementation and Testing Wednesday, 1pm