Your SlideShare is downloading. ×
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
SOA Baseline/Target with Summary Recommendations (doc)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

SOA Baseline/Target with Summary Recommendations (doc)

756

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
756
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
63
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 1 Primary Contributors2 Last Modified: Dec 16, 2009 Bill Kehoe3 Department of Licensing 4 Frank Westrum Department of Health5 Paul Warren Douglas6 Department of Information Services Stephen Backholm 7 Service-Oriented Architecture Department of Social and Health Services8 Initiative (SOA) Baseline/Target Jerry Britcher9 Architecture Department of Social and Health Services 10 With Gap/Opportunity Analysis and Gary Dubuque11 Summary Recommendations Department of Revenue 12 David Jennings Department of Health 13 JoAnne Kendrick 14 Department of Information Services EA Committee Endorsed Douglas McGregor 15 Version 1.2 Department of Licensing 16 Noel Morgan 17 December 16, 2009 Department of Transportation 18 Other Reviewers SOA Documenter Team 19 Enterprise Architecture Committee Statewide Stakeholders - pending Information Services Board Enterprise Architecture Committee Rob St. John, Department of Social and Health Services Clare Donahue, University of Washington Co-Chairs 1
  • 2. 2Washington State Enterprise Architecture Program December 16, 2009 3Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 4 20Table of Contents 211. Introduction................................................................................................................................4 22 1.1. Definitions..........................................................................................................................4 232. Gap/Opportunity Analysis and Summary Recommendations....................................................4 24 2.1. Proposed Standards..........................................................................................................4 25 2.2. Summary Recommendations.............................................................................................5 26 2.3. Recommended Strategies.................................................................................................6 273. Baseline and Target Architectures............................................................................................6 284. Enterprise SOA Commitment and Business Case....................................................................6 295. Governance...............................................................................................................................7 306. Funding Models.........................................................................................................................8 31 6.1. Funding Model Options......................................................................................................8 327. Enterprise SOA Roadmap.........................................................................................................9 33 7.1. Stage One: 2006-2008.......................................................................................................9 34 7.2. Stage Two: 2009-2010.......................................................................................................9 35 7.3. Stage Three: 2009-2014 ................................................................................................10 368. Maturity Models.......................................................................................................................11 37 8.1. Integration Maturity Model Levels....................................................................................11 38 8.2. Integration Competency Center Model Levels.................................................................11 399. Collaboration and Communication .........................................................................................12 40 9.1. Roles and Responsibilities...............................................................................................13 4110. Performance Monitoring and Testing.....................................................................................13 42 10.1. Service Level Agreement...............................................................................................14 4311. Infrastructure and Technologies............................................................................................14 4412. State ICC SOA Backplane ....................................................................................................14 45 12.1. SOA Backplane Functionality .......................................................................................15 4613. Processes and Framework....................................................................................................16 4714. Reference Architecture..........................................................................................................16 5 Page 2 of 22
  • 3. 6Washington State Enterprise Architecture Program December 16, 2009 7Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 8 4815. Education and awareness.....................................................................................................17 49 15.1. Skills and training...........................................................................................................17 5016. IT Business Transformation...................................................................................................17 5117. Related Policies, Principles and Standards...........................................................................18 5218. Glossary................................................................................................................................18 5319. References...........................................................................................................................20 5420. Document Context.................................................................................................................21 5521. Document History .................................................................................................................22 56 57 9 Page 3 of 22
  • 4. 10Washington State Enterprise Architecture Program December 16, 2009 11Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 12 58 1.Introduction 59This document describes the enterprise SOA Baseline and Target Architectures. It identifies the state’s 60current environment and end goal, or what the SOA environment will look like once implemented, in the 61form of SOA components, methods, and policies. The document builds on the Domain architecture 62recommendations. 63The Baseline/Target Architecture provides decision-making information. The proposed results are 64includedin the Gap/Opportunity Analysis section which identifies recommended standards and strategies 65needed to complete initiative objectives and enable State Strategic IT Plan Goals and Strategies (SSITP). 661.1. Definitions 67 • Service-Oriented Architecture (SOA) – An architectural method or design style that results in and 68 supports shared, reusable services. 69 • SOA-based Services – Are modular, swappable functions, separate from, yet connected to an 70 application via well defined interfaces to provide agility. Often referred to as ‘services’ throughout this 71 document they: 72 o Perform granular business functions such as “get customer address” or larger ones such as 73 ‘process payment.’ 74 o Are loosely coupled to a new or existing application. 75 o Have capability to perform the steps, tasks and activities of one or more business processes. 76 o Can be combined to perform a set of functions - referred to as ‘service orchestration.’ 77 • SOA Backplane – Supporting infrastructure such as registry/repository, middleware, enterprise 78 service bus (ESB), and life cycle management, communications, and analytical tools. Typically 79 managed by an Integration Competency Center (ICC). 80 • SOA Domain – Can be defined by different boundaries like common services and consumers, yet 81 typically has its own ICC and SOA backplane (e.g. State ICC Domain.) with service registry and 82 repository, infrastructure, design and monitoring tools, and more. 83 • SOA Governance – Is the structure and process for making policy and operational changes. Includes 84 Steering Committee, Technical Advisory Group, and state ICC for change management. Operational 85 governance can help automate life cycle management, policy management, and SOA metadata 86 management performed by the service registry/repository. 87 2.Gap/Opportunity Analysis and Summary Recommendations 882.1. Proposed Standards 89The following standards should be developed, adopted to enable the summary recommendations and 90strategies.The standards are likely to mature as the state’s SOA-based architecture, services, and 91governance structure evolves: 92• Develop and adopt SOA Governance Standards 93 o Establish SOA Services Steering Committee and Technical Advisory Group 13 Page 4 of 22
  • 5. 14Washington State Enterprise Architecture Program December 16, 2009 15Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 16 94Note: These suggested governance roles and responsibilities may be new, added to existing groups, or 95created as needed, 96• Develop and adopt SOA Service Design Standards 97 o Includes principles, service conditions, and design standards 982.2. Summary Recommendations 99Governance – The state should establish an SOA Steering Committee and Technical Advisory Group to 100work with the ICC to help review and recommend Tier One services. Services are guided by agency 101business needs. 102• Roles and responsibilities should be clearly defined; key stakeholders represented on governance 103 teams, and Integration Competency Centers should coordinate and communicate. 104• An enterprise service registry/repository is critical for publishing and monitoring services, as well as 105 minimizing duplicate efforts. 106• Change management processes, policies, and service level agreements are required. 1072.2.1.Value 108• Services are designed as application components for reuse, sharing, and improve extensibility for 109 legacy systems. 110• SOA can enable the reuse and agile combination of purchased packages, legacy applications, and 111 services. 112• Focus should not only be placed on maturing SOA at the Tier One level, but agencies should mature 113 their own application development areas to utilize SOA principles at Tier Two and Tier Three where 114 appropriate. 115• SOA is an application design practice. Many SOA design styles exist and may be dependent on 116 existing infrastructure and applications. 117• Some Enterprise Resource Planning (ERP) systems are adding shared modular functionality through 118 SOA methods to leverage existing investments. 1192.2.2.Design Risks 120• Not all application modules should be services and service nesting (sub-layered, dependent services) 121 is discouraged to minimize complexity. 122• Poorly designed or redundant services lead to higher costs and complexity. 1232.2.3.Tools and Technologies 124• A variety of automated tools and technologies are available to measure usage, monitor performance, 125 and support a standardized environment. They are expected to evolve to meet business needs. 126• An Enterprise Service Bus (ESB) is not always required, yet commonly used to implement shared 127 services. 1282.2.4.Communication 129• More communication and education is needed to help agencies provide and consume Tier One 130 services. New skills and training will help improve SOA success. 131• While services are designed to be shared, the term ‘Shared Services’ is more appropriately used to 132 define the state’s initiatives such as Desktop Management and Infrastructure Management, driven by 133 the state’s Customer Advisory Board. 1342.2.5.Funding 135• Identify services on funded projects where possible. SOA strategies should be flexible and adaptable. 17 Page 5 of 22
  • 6. 18Washington State Enterprise Architecture Program December 16, 2009 19Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 20 136• Shared cost models encourage development teams to make application functionality available. 137• Helps ensure the hosting agency’s services (also known as service provider) offered up as Tier one 138 have longevity for the provider and consumers lines of business. 1392.3. Recommended Strategies 140• Following review by the governance teams, Tier One services shall be published to the state’s service 141 registry. 142• Agency service providers and consumers should check the state SOA registry for an existing service 143 before building or buying a new one. 144• The state SOA registry should have a location for agencies to post Tier Two services in order to 145 reduce service design redundancy and promote potential Tier One service candidates. 146• Request for Proposals (RFP) should require proposed vendors to identify and describe the proposed 147 solution’s SOA readiness and SOA architecture. 148• Acquisitions should include language to identify proposed vendor’s capabilities to loosely couple with 149 the state’s current and future shared services. 150• Leverage existing investments where possible. Enterprise Resource Planning (ERP) solutions – 151 include SOA requirements in new acquisitions. 152• Tier One services should have a clear business owner and service provider. 153• Utilize and evolve the ISB Integration Architecture Service Repository Solution Set rather than 154 develop another document. 155 3.Baseline and Target Architectures 156The baseline describes the current operational environment. The target architecture provides a vision of 157what the desired goal environment will look like and how it will function. 4.Enterprise SOA Commitment and Business Baseline Target Case • State strategic IT plan includes goals to promote common IT practices, X X data sharing, reuse and other SOA strategies. • The state has completed a Business Case for enterprise SOA and X X further exploration of Tier One services. 158 21 Page 6 of 22
  • 7. 22Washington State Enterprise Architecture Program December 16, 2009 23Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 24 159 5.Governance Baseline Target • The ICC Governance role and responsibility is specified in the X X current Integration Services Governance ISB Document Version 2.0 dated January 4, 2007. Governance is necessary to lead and support enterprise Tier One service development. SOA governance should include: X • SOA Services Steering Committee • Composed of State Agency CIOs. Include business leaders X where possible for areas such as Data Services. • Articulates the business needs that shape and control the X overall SOA strategy, services offering, and supporting infrastructure. • Works with state’s Integration Competency Center (ICC) to: X • Ensure services meet SOA Governance Standards and SOA Service Design Standards. • Ensure service providers and consumers are utilizing the X state’s Backplane for Tier Once service integration and messaging rather than building point to point solutions. • Plan for potential service candidates that enhance business X solutions. • Help develop and evolve the SOA standards and guidelines to X recommend for statewide adoption. • SOA Services Technical Advisory Group: X • Composed of state agency architects. X • Reports to the Services Steering Committee. X • Answers technical architecture questions as defined and X chartered by SOA Services Steering Committee. State agencies’ business needs should drive Tier One SOA Strategy. As a result, the SOA governance bodies composed of agency representatives should lead by answering the following governance questions: 25 Page 7 of 22
  • 8. 26Washington State Enterprise Architecture Program December 16, 2009 27Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 28 5.Governance Baseline Target • What services should be built? X • How will agencies find and re-use existing services? X • How will change management work for existing services and X supporting infrastructure? • What standards and policies should be created for Tier One X SOA services and infrastructure? • Who will enforce defined standards and policies? X • At what granularity level will Tier One services exist? X • What constitutes a Tier One service? X 160 161 6.Funding Models 162Funding models are an important part of ensuring the longevity and stability of Tier One services. 163Monetary costs associated with building and maintaining Tier One SOA services should be addressed. 6.1. Funding Model Options Baseline Target • Enterprise-based X X • Project-based X X • IT or individual line of business X X • Charge back X X • Provide a monetary reward from a central fund for an accepted Tier X One service. This will give agencies incentive to offer up Tier One compliant services for others to use. • Cost recovery models exist to support centralized functionality such as X the ICC. • When services are developed within an agency, funding comes from X the agency’s budget. The concern is if funding is no longer available. • The Core Service Principle is one way to address this issue. If an X agency develops a SOA service to support their core business, they will be more likely to maintain that service since core businesses of 29 Page 8 of 22
  • 9. 30Washington State Enterprise Architecture Program December 16, 2009 31Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 32 6.1. Funding Model Options Baseline Target agencies are fairly stable. • Shift support of a service to a central support agency (such as the X ICC). With this model, it is key to ensure business expertise on the details that exists within the program agencies are well communicated with the central support agency. While the technical skill may exist within an ICC, the business knowledge remains with the program agency. • Mechanism for supporting ongoing maintenance and operations costs X 164 7.Enterprise SOA Roadmap Baseline Target 7.1. Stage One: 2006-2008 • The ISB adopted the Integration Architecture Standards and X X Solution Sets. • The state established an Integration Competency Center (ICC). X X • Chief Integration Architect hired and ICC staffed with State X X Architects to assist agencies and maintain the state’s integration infrastructure and SOA Backplane. X In 7.2. Stage Two: 2009-2010 Progress • The state ICC establishes maturity roadmap and communication plan. X In • The state ICC will reach Maturity Level 3 (Globally Defined) and Progress stabilize as a Best Practices Model. X X • Develop recommendations for a statewide Service Oriented Architecture (SOA) roadmap, reference framework, and program requirements to assist in education, identification, creation, and use of shared services (SSITP). • The state ICC SOA Backplane consists of middleware, service X X registry and repository, Enterprise Service Bus and messaging technologies that support the integration profiles for system to system integration. 33 Page 9 of 22
  • 10. 34Washington State Enterprise Architecture Program December 16, 2009 35Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 36 7.Enterprise SOA Roadmap Baseline Target 7.3. Stage Three: 2009-2014 Baseline Target • Enterprise SOA will take time to mature, grow, and provide a X return-on-investment. With the proper commitment and investment, the state can expect to see an estimate of 10-15 services at the Tier One level over the next 5-7 years. • Evolve statewide Service Oriented Architecture (SOA) roadmap, X reference framework, and program requirements to assist in education, identification, creation, and use of shared services (SSITP). • Service providers and consumers will utilize more services. X • Funding models will evolve to build and sustain SOA-based X services. • The state ICC will evolve to Maturity Level 4 (Quantitatively X Managed) and establish itself as a Shared Services Model. • The state ICC will provide services and service orchestrations in X compliance with state SOA standards. 165 37 Page 10 of 22
  • 11. 38Washington State Enterprise Architecture Program December 16, 2009 39Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 40 166 8.Maturity Models There are 5 Maturity Model Levels as well as 5 Integration Competency Baseline Target Center Model Levels defined by industry best practices. 8.1. Integration Maturity Model Levels 1. Awareness X X There is awareness that problems exist but the organization has taken little action regarding Infrastructure Development. 2. Managed Awareness and action occur in response to issues. Action is either X X system or department specific. 3. Globally Defined Infrastructure development is part of the IT charter. Processes and X X solutions exist to measure and improve. 4. Quantitatively Managed Infrastructure managed as an enterprise asset and well-developed X X processes exist and are enforced. 5. Globally Optimized Infrastructure Development is a strategic initiative. Issues are either X X prevented or corrected at the source and best-in-class solution architecture is implemented. 8.2. Integration Competency Center Model Levels 1. Project Silos The technology, processes and organization are independent. Projects are optimized. X • The Integration Competency Center Model is presently positioned at Project Silos. 2. Best Practices The technology is recommended, the processes are defined and the organization is distributed to leverage knowledge. • The State Integration Competency Center is currently at the X maturity model Level 2, meaning the there is some awareness of the ICC and it is being leveraged for specific projects or systems. 3. Technology Standards X The technology is standardized, processes are defined and the 41 Page 11 of 22
  • 12. 42Washington State Enterprise Architecture Program December 16, 2009 43Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 44 8.Maturity Models There are 5 Maturity Model Levels as well as 5 Integration Competency Baseline Target Center Model Levels defined by industry best practices. organization is distributed to provide consistency. 4. Shared Service X The technology is shared, the processes are defined and the organization is hybrid to provide resource optimization. 5. Central Service The technology is automatic, processes are dynamic and organization is invisible to provide innovation and efficiency. • As the ICC and SOA mature within the State, the maturity model is X expected to move towards Level 5 and provide services as a Shared Service. • The SOA environment supports mechanisms and tools for self X monitoring. o The mechanisms and tools provide the ability to monitor both X use and capacity. o Monitoring capacity meet historical and planning purpose X requirements. 167 9.Collaboration and Communication Baseline Target • The Integration Competency Center provides tools for integration X X and SOA collaboration and communication. These tools include a library of integration patterns, a service registry and repository and Integration Technology site. • Collaboration and communication among state agencies related to X SOA services is ad hoc. • Some agency providers and consumers may have point-to-point X services in production. • State agencies do not have good visibility as to what services are X available for use and integration. 45 Page 12 of 22
  • 13. 46Washington State Enterprise Architecture Program December 16, 2009 47Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 48 9.Collaboration and Communication Baseline Target • State Agency Awareness - An enterprise plan and communication X model exist to implement and govern shared services. • Communication is important to establish a clear understanding of X how to utilize SOA services, and to grow agency and staff support for both the development and use of existing services • Communication channels and processes are in place to enable X the multi-agency enterprise to share services. • Tier One data standards play an important role in helping define X interfaces and service descriptions. The state must have a defined and enforced Tier One data standards process. • Business and IT Communication - Private and public sector best X practices have been identified to engage and educate the business community and agencies. 168 9.1. Roles and Responsibilities Baseline Target The state Integration Competency Center (ICC) • Enables collaboration and coordination X X • Manages the state SOA backplane X X • Provisions and maintains the state SOA service repository X X • Ensures compliance to the Change and Configuration X X Management processes as defined by the SOA Governance Standards • Consults with agencies to design and implement agency to X X agency interfaces 169 170 10.Performance Monitoring and Testing Baseline Target • The state ICC participates in service integration testing in support X X of agency’s service deployments 49 Page 13 of 22
  • 14. 50Washington State Enterprise Architecture Program December 16, 2009 51Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 52 • The state ICC is responsible for monitoring the integration layer X X • Some agency providers and consumers may have point-to-point X services in production. 10.1. Service Level Agreement The state ICC works with agencies to ensure integration layer compliance for: • Availability requirements X X • Responsiveness requirements X X • Compliance to SLA agreements for services consumed. X X 171 11.Infrastructure and Technologies Baseline Target The state ICC domain has established a statewide enterprise-level SOA Backplane including: X X Tier Two SOA programs and initiatives already exist. Conceptually, the Tier One SOA framework will connect the Tier Two architectures. To get to this point, some basic infrastructure must be created first. Some components of this infrastructure are: • A Tier One Enterprise Service Bus – ESBs contain not only the X X transport capacity, but also the ability to transform data. The ability to transform data within the ESB alleviates redundant development for transforming data for consumers of a particular data set • State ICC Service Registry and Repository – These tools provide X X the framework for housing and vending the Tier One services. They also provide the mechanisms for operational governance of the services (e.g. without meeting pre-established criteria, a service is not made available through the Registry) 172 173 12.State ICC SOA Backplane 53 Page 14 of 22
  • 15. 54Washington State Enterprise Architecture Program December 16, 2009 55Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 56 12.1. SOA Backplane Functionality Baseline Target • Message Routing  A routing service is the key component for moving a X X message across the enterprise service bus – from its entry point to its exit point. • Transaction Management (similar to many database transaction X X functions) • Listeners X X • Multi level undo/redo o A method that tells how many levels of undo/redo it wants. X X Coalescing of transactions • Provide methods to merge transactions. X X Aggregation • Provide the ability to gather data or transactions from disparate X X sources and return a single data set or response Nested transactions • Provide the methods for one transaction to execute other X X transactions. Transformation • Facilitation of the transformation of data formats and values, X X including transformation services between the formats of the sending application and the receiving application • Transforming messages conditionally, based on a non-centralized X X policy Message Brokering X X • Modify service messages in runtime to mediate between different systems • Reroute service requests in runtime based on content checking X X rules such as service version • Create new protocol conversion mechanisms with the Open API X X • Set exception based routing and automate runtime exception X X handling to route messages to available services and provide exception response messages • Throttle messages to allow only a specific number of messages to X X reach the service in a specific period of time 57 Page 15 of 22
  • 16. 58Washington State Enterprise Architecture Program December 16, 2009 59Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 60 12.1. SOA Backplane Functionality Baseline Target Transport Management • Support for various MEPs (Message Exchange Patterns) (for X X example: synchronous request/response, asynchronous request/response, send-and-forget, publish/subscribe) • Queuing, holding messages if applications temporarily become X X unavailablethe Security X X • a standardized security-model to authorize, authenticate and audit use of the ESB 174 13.Processes and Framework Baseline Target • The ICC is responsible for defining the strategic and operational X X processes and framework to support the integration infrastructure, including middleware, registry/repository, adapters, message transport, data repositories and related integration tools. • The ICC is responsible for collecting from service providers and X X providing to service consumers all metadata and documentation associated to any service registered in the service registry/repository • The SOA Steering Committee is responsible for defining the strategic X and operational processes and framework to support Tier One SOA services • Tier One elements are in place to address SOA strategic planning, X design guidance, SOA implementation and maintenance, service granularity, service interoperability, service identification, and sustainable support. 175 176 14.Reference Architecture Baseline Target • Reference architecture for integration is provided in the X X Conceptual Integration Technical Reference Architecture ISB Document Version 4.0 dated September 14, 2006. 61 Page 16 of 22
  • 17. 62Washington State Enterprise Architecture Program December 16, 2009 63Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 64 • Conceptual Technical Reference Architecture complete and X published. • Expected to evolve over time, yet contains Business Drivers, X Environmental Trends, and Principles for Decision-Making, key Target Architecture components, state ICC and SOA Backplane features including state service registry information, and Glossary to promote common terminology. 177 15.Education and awareness Baseline Target • The SOA initiative has resulted in the development of a SOA Glossary X X for common terminology. • The state ICC has established a multi-agency user group and X X Integration Technology Forum SharePoint Site. • Common terminology – SOA Glossary developed. Expected to evolve X X and be updated by SOA Technical Advisory Group. • State Agency Awareness - An enterprise plan and communication X model exist to implement and govern shared services. SOA Steering Committee, SOA Technical Advisory Group, state ICC, and service providers all play a role in helping provide education and awareness. 15.1. Skills and training X X • The state Integration Competency Center is highly skilled and continues to seek training in integration and Service Oriented Architecture. • Training and communication are critical to the successful SOA X environment. o Application development that incorporates or builds Tier One services is a new skill set that developers will need to acquire. 178 16.IT Business Transformation Baseline Target • State agencies currently share a variety of services through a X collection of methods. • IT Business planning, project management, and procurement include X identification and do not fully use Tier One shared services. 65 Page 17 of 22
  • 18. 66Washington State Enterprise Architecture Program December 16, 2009 67Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 68 16.IT Business Transformation Baseline Target • Risk mitigation strategies are not yet defined when adding shared X services to existing business process functions or legacy applications. • Fiscal benefits are need to be identified to invest in developing Tier X One SOA shared services. • Potential services candidates (short-term and long-term) are not yet X identified and prioritized. • IT business processes are not yet being transformed from stand X alone, replicated processes into highly leveraged shared services. • IT Business planning, project management, and procurement include X identification and use of Tier One shared services. • Risk mitigation strategies are defined when adding shared services to X existing business process functions or legacy applications. • Fiscal benefits are identified to invest in developing Tier One SOA shared services. X • Potential services candidates (short-term and long-term) are identified X and prioritized. • IT business processes are being transformed from stand alone, X replicated processes into highly leveraged shared services. 179 180 181 17.Related Policies, Principles and Standards 182• State Integration Architecture Standards and Service Interaction Profiles, Service Modeling 183 Standards, Service Repository Solution Set, and Service Governance. 184• State IT Security Standards 185• State Data Standards 186• Principle: Agency developed Tier One services should only be developed around agency core 187 business services. 188 18.Glossary 189REAL WORLD EFFECT The actual, desired result of the service (e.g. ‘Get customer 190 information.) SOA-based services are designed to meet 191 business needs. A service consumer is a participant that 69 Page 18 of 22
  • 19. 70Washington State Enterprise Architecture Program December 16, 2009 71Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 72 192 interacts with a service in order to realize the real world effect 193 produced by a capability to address a consumer need. 194SERVICE CONDITIONS Service-oriented architecture (SOA) is a style of application 195 architecture. According to Gartner, an application is SOA-based 196 service when it meets these five conditions: 197 1. It is modular. 198 2. The modules are distributable. 199 3. Software developers write or generate interface metadata that 200 specifies an explicit contract so that another developer can find 201 and use the service. 202 4. The interface of a service is separate from the implementation 203 (code and data) of the service provider. 204 5. The service is shareable — that is, designed and deployed in 205 a manner that enables them to be invoked successively by 206 disparate consumers. 207 208SERVICE METRICS Monitoring services provides audit, logging, charge-back, 209 financial reporting for investments, design, deployment, 210 maintenance planning, and other purposes via metrics such as: 211 Quality of Service (QoS) and Performance 212  Number of requests 213  Number of failed requests 214  Number of successful requests 215  Service time 216  Maximum response time 217  Last response time 218 Reuse Metrics 219 • Number of services deployed 220 • Number of consumer applications deployed 221 • Number of services and number of consumers 222 • Number of services shared by applications 223 224SERVICE ORIENTED ARCHITECTURE SOA is an architectural method or design style that results in and 225 supports shared, reusable services. 226SOA-BASED SERVICES Are modular, swappable functions, separate from, yet connected 227 to an application via well defined interfaces to provide agility. 228 Often referred to as ‘services’ throughout this document they: 229 • Perform granular business functions such as “get customer 230 address” or larger ones such as ‘process payment.’ 231 • Are loosely coupled to a new or existing application. 232 • Have capability to perform the steps, tasks and activities of 233 one or more business processes. 73 Page 19 of 22
  • 20. 74Washington State Enterprise Architecture Program December 16, 2009 75Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 76 234 • Can be combined to perform a set of functions - referred to 235 as ‘service orchestration.’ 236SERVICE PROVIDERS AND CONSUMERS Entities (people and organizations) offer capabilities and act as 237 service providers. Those with needs who make use of services 238 are referred to as service consumers. 239STATE SOA BACKPLANE Shared, common infrastructure for lifecycle management, 240 registry/repository, policies, business analytics for service 241 metrics; Routing/Addressing, naming, quality of service, 242 communication; Development Tools for security, management, 243 and adapt. 244TIER ONE Statewide Enterprise Architecture business processes, data, or 245 technologies that are common among the majority or to all state 246 agencies. 247 Tier Definitions: 248  Tier One: Across/among agency systems 249  Tier Two: Within an agency 250  Tier Three: Sub- agency level 251 These three different tiers depend on the degree to which they 252 should be common, and what other entities with which they 253 should be common. A description of the state’s Tiers is available 254 at: http://isb.wa.gov/committees/enterprise/concepts/ 255 19. References 256Erl Erl, Thomas. Service-Oriented Architecture: Concepts, 257 Technology, and Design. Prentice-Hall, 2005. 258DKD Krafzig, Banke, Slama, Enterprise SOA, Service-Oriented 259 Architecture Best Practices, Prentice-Hall, 2005 260Gartner Gartner Group Research Service, retrieved 2007 261 Building a Service-Oriented Architecture Business Case: 262 Effective Communication is the First Step, Gartner, March 2007 263Forrester Forrester Research Service, retrieved 2007 264 SOA Repositories: Crucial to SOA Governance Success, Oct 265 2006. 266InfoTech Strategy & Planning, Set the Stage for SOA Governance, Dec 267 2008. 268NASCIO National Association of Chief Information Officers, Enterprise 269 Architecture Tool Kit v 3, October 2003. 270SOA-RM Reference Model for Service Oriented Architectures, Working 271 Draft 11. OASIS, 2005. 272SSITP 2008-2014 Washington State Strategic Information Technology 273 Plan, Strategy 10, Nov 2008. 77 Page 20 of 22
  • 21. 78Washington State Enterprise Architecture Program December 16, 2009 79Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 80 274 20.Document Context 275This document is within the scope of state’s Service-Oriented Architecture (SOA) initiative. The Baseline 276and Target Architectures are deliverables within the Initiative Charter adopted on July 10, 2008 by the 277Information Services Board (ISB) and available at: 278http://dis.wa.gov/enterprise/enterprisearch/soa_initiative.aspx. 279Initiative Stewards: 280• Bill Kehoe, Department of Licensing 281• Frank Westrum, Department of Health 282Initiative Architect: 283• Paul Warren Douglas, Department of Information Services 284Documenter Team: 285• Documenter Team consisted of 27 multi-agency subject matter experts representing 11 agencies. 286• Baseline/Target Architecture Co-Leads: Jerry Britcher, Department of Social and Health Services; 287 JoAnne Kendrick, Department of Information Services. 81 Page 21 of 22
  • 22. 82Washington State Enterprise Architecture Program December 16, 2009 83Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture EA Committee Endorsed Version 1.2 84 288 21.Document History Date Version Editor Change May 18, 2009 1.0 Paul Warren Douglas, Initial Draft - Jerry Britcher, DSHS and Jerry Britcher, JoAnne JoAnne Kendrick, DIS agree to co-lead Kendrick document with EA Program. Documenter Team Aug to Oct 12, 1.1 Documenter Team Baseline and Target enhanced and 2009 revised by co-leads and documenter team SOA Steering Committee and SOA Technical Advisory Group details added Target synchronized with SOA Readiness Awareness Tool Documenter team additions and revisions. Oct -Nov, 1.2 Documenter Team EAC suggested revisions to add 2009 matrices for readability and easy comparison purposes. Moved Governance to section 5. Moved Document Context to section 19. Added example to Services definition. Format changes for readability. Refining/synchronizing SOA-based Services definition with current documents. Dec 8, 2009 1.2 Paul Warren Douglas Synchronized Glossaries with draft Standards documents Dec 16, 2009 1.2 Paul Warren Douglas EA Committee Endorsed 289 85 Page 22 of 22

×