1. Tom Clarke Washington State Administrative Office of the Courts May 25, 2004 Service-oriented Architecture Connecting the Dots

2. c What do we want?  Flexible software  Low cost software maintenance  Platform independence  Business responsiveness  Open standards  In short, a MIRACLE!

3. c What do our customers want?  Instant response to a changing business  Decreasing infrastructure costs  Real-time event-driven information  Support of strategic business initiatives  User friendly applications  In short, a MIRACLE!

4. c Can an SOA help?  Yes – if appropriately and incrementally combined with other improvements  Maybe – if the justice industry gets its act together on standards and the vendors follow  No – if we expect a magic bullet

5. c Some definitions  Enterprise Architecture  consistent principled guidelines for making decisions about technology  collection of risk mitigation strategies  Service-oriented Architecture:  asynchronous, event-driven  loosely coupled, flexible  public interfaces  reuse of components & logic

6. c

7. c What should an EA include?  Business values, goals and principles  performance measures  Business processes & best practices  functional standards  Enterprise data model  data exchange standards, GJXDM, GJXDD  Enterprise technology stack  web services, SD process, PM process

8. c EA Issues  Can be IT-centric or process-centric  Before choosing framework, determine:  business drivers (is there an ROI?)  scope (how much commonality?)  governance (who will enforce?)  Need executive business support  choose pilot that spans business silos  show value of architectural standards

9. c What should an SOA Include?  Registry of services  Reusable distributed services  Open standards-based interfaces  Reusable business logic  Event-driven asynchronous messaging  Focus on systems—not databases  Incremental delivery strategy

10. c How do web services fit in?  SOA is a design principle  Web services are a technology stack  Applies primarily to automatic data exchanges between applications  Excludes some business benefits of EA & SOA:  Internal application flexibility  Alignment with performance measures

11. c

12. c CTA Performance Standards  Top level of Enterprise Architecture  Identifies specific business goals  Guides IT alignment with the business  Requires IT support to implement

13. c

14. c CTA Functional Standards  Middle of Enterprise Architecture  Describes common business processes  Describes IT requirements as use cases  Supports IT alignment with the business

15. c

16. c CTA Data Exchange Standards  Lower level of Enterprise Architecture  Based on web services  Based on GJXDD  Need to validate relevant parts of GJXDM using critical reference documents  Need to align with JIEM Reference Model to support CJIS projects

17. c GJXDD & GJXDM  GJXDD – a common justice vocabulary  needs more modularity  needs more transparency  GJXDM – a common justice semantics  needs tighter sub-domain models  needs standard bindings for J2EE and.Net

18. c

19. c Software Development Process  Has implications for EA and SOA  What risks to mitigate?  What granularity to use?  How much ambiguity to tolerate?  What organizations (business processes) are appropriate?  High or low ceremony?  Agile or rigorous processes?  Traditional unified PM’s or not?

20. c Project Management Process  Standardized architectures and processes require special expertise in business process reengineering. [EA]  Emphasis on services requires special expertise in customer requirements definition. [SOA]

21. c There is a plan!  The ASCA and CTA standards fit into an overall Corrections and Justice EA and SOA strategy.  Business benefits of compliance will include faster, cheaper and more value-laden satisfaction of business needs.

22. Washington State Administrative Office of the Courts 1206 Quince St SE P O Box 41170 Olympia, WA 98504-1170 (360) 753-3365FAX: (360) 586-8869 Contact Information