Applying the SOA RA Utah Public Safety ESB Project Utah Department of Technology Services April 10, 2008 Prepared by Robert Woolley

Why SOA?

Key DOJ SOA Resources A Framework for Justice Information Sharing: Service Oriented Architecture (SOA) The Global Justice Reference Architecture (JRA) Web Services Service Interaction Profile

Why Create a SOA RA for Utah? Establish an abstract basis for actual SOA implementations applied to the State. Show how SOA incorporates existing topologies within State government. Establish an EA pattern that can bridge technology and business silos. Enable better alignment of technology with agency business needs in a more timely and responsive way.

SOA Addresses Business Problems Lack of Agility Slow Time to Benefit Proprietary Technologies Inconsistent Information Exchange Hard to Map Customer Needs to Capabilities Difficulty Scaling Skill Pools Business case alignment Limited Reuse Extended development time lines Higher Support Cost Higher Acquisition Cost Higher Development Cost Lack of Technical Adaptability Business Issues Financial Issues

SOA Addresses Technical Problems Incompatible solutions across agencies Different sets of standards Differing descriptions of services making service discovery difficult Differing agency asset reuse policies Differing tools and governance approaches Hard coded process flows Many complex point to point integrations Duplication of infrastructure

SOA Foundation Reference Model

SOA RA Lessons Learned Application of an abstract RA to an organization has tangible benefits, –Facilitates Technical Communication –Establishes a Basis for Working with Vendors –Establishes a Context for Business Alignment –Maintains a Vision and a Target for SOA –Establishes Reasons for Agency Resource Sharing and Technical Cooperation –Helps Integrate Point SOA Solutions into Overall EA SOA Patterns

DPS SOA ESB Pilot Project Goals –Allow Information Sharing –Create Statewide Standards –Reduce Costs Technology –Open Standards –Justice XML - NIEM –Web Services –Enterprise Service Bus and SOA

Public Safety SOA Projects 2008

Public Safety SOA Projects 2009

Replicable DPS ESB Project Practices ESB Design –Routing, brokering, transformation and protocols, error handling, audit logging, propagation strategies, and security settings. Data Services Platform Design –Taxonomies, data hierarchies, data entity descriptions, and service configuration. Security Design –Identification of roles and groups, policy definitions, deployment design, and enforcement strategies Testing

Replicable DPS ESB Work Products Deployment Methodology Detailed Infrastructure Architecture Capacity Plan Prototype Configuration and Code Environment Setup (Scripts and Procedures)‏ Operations Guide Configuration and Delivery Assets Deployment Plan

DPS ESB Lessons Learned Standardized development is essential. Skill set transfers for new technologies present time and management challenges. Quality of development tools matters. Security requires a new perspective. Initial ESB deployment and scalability can be complex and must be managed. Design points for application development with SOA and ESB are not well understood. Architecture matters.

Questions? Contact Information: Bob Woolley Chief Technologist and Strategic Planner Department of Technology Services 1 State Office Building Salt Lake City, Utah