150 likes | 314 Views
Utah Department of Technology Services April 10, 2008 Prepared by Robert Woolley. Applying the SOA RA --------------------- Utah Public Safety ESB Project. Why SOA?. Key DOJ SOA Resources. A Framework for Justice Information Sharing: Service Oriented Architecture (SOA)
E N D
Utah Department of Technology Services April 10, 2008 Prepared by Robert Woolley Applying the SOA RA---------------------Utah Public Safety ESB Project
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 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
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 84110 801-538-1072 Email: bwoolley@utah.gov