Your SlideShare is downloading. ×
Service-Oriented Architecture (SOA) Governance Standards
Service-Oriented Architecture (SOA) Governance Standards
Service-Oriented Architecture (SOA) Governance Standards
Service-Oriented Architecture (SOA) Governance Standards
Service-Oriented Architecture (SOA) Governance Standards
Service-Oriented Architecture (SOA) Governance Standards
Service-Oriented Architecture (SOA) Governance Standards
Service-Oriented Architecture (SOA) Governance Standards
Service-Oriented Architecture (SOA) Governance Standards
Service-Oriented Architecture (SOA) Governance Standards
Service-Oriented Architecture (SOA) Governance Standards
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

Service-Oriented Architecture (SOA) Governance Standards

719

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
719
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
61
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 3 Bill Kehoe Department of Licensing4 5 Frank Westrum Department of Health6 7 Paul Warren Douglas Department of Information Services8 9 Stephen Backholm 10 Department of Social and Health Services Modified: Dec 16, 2009 11 Jerry Britcher 12 Department of Social and Health Services 13 Gary Dubuque Department of Revenue 14 David Jennings15 Service-Oriented Architecture (SOA) Department of Health 16 Governance Standards JoAnne Kendrick 17 Department of Information Services 18 EA Committee Endorsed Daniel Mercer Labor and Industries 19 Version 1.2 Douglas McGregor 20 Department of Licensing 21 December 16, 2009 Noel Morgan Department of Transportation Gary J. Prohaska University of Washington Bill Yock University of Washington Other Reviewers SOA Documenter Team 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 Enterprise Architecture Program December 16, 2009 3Service-Oriented Architecture (SOA) Governance Standards EA Committee Endorsed—Version 1.2 22 Table of Contents 231. Purpose......................................................................................................................................3 24 1.1. Statutory Authority................................................................................................................3 25 1.2. Scope...................................................................................................................................3 26 1.3. Related Policies and Standards...........................................................................................3 272. Introduction ................................................................................................................................3 28 2.1. Definitions.............................................................................................................................3 293. Roles and Responsibilities..........................................................................................................4 30 3.1. SOA Steering Committee.....................................................................................................4 31 3.2. SOA Technical Advisory Group ...........................................................................................5 32 3.3. Change Management ..........................................................................................................5 33 3.3.1. Service Provider ............................................................................................................5 34 3.3.2. Infrastructure..................................................................................................................6 35 3.4. Configuration Management..................................................................................................6 36 3.5. Quality Assurance ...............................................................................................................6 37 3.5.1. Assurance of Real World Effect.....................................................................................6 38 3.5.2. Standards Conformance................................................................................................7 39 3.6. Service Level Agreement.....................................................................................................7 40 3.7. Service Reuse .....................................................................................................................7 414. State ICC Domain ......................................................................................................................8 425. Glossary......................................................................................................................................9 436. References...............................................................................................................................10 447. Document History.....................................................................................................................10 458. Document Context....................................................................................................................11 46 47 48 4 Page 2 of 11
  3. 5Washington Enterprise Architecture Program December 16, 2009 6Service-Oriented Architecture (SOA) Governance Standards EA Committee Endorsed—Version 1.2 49 1.Purpose 50These standards are designed to enable service-oriented architecture (SOA) governance teams 51to help agencies plan, design, and maintain Tier One SOA-based services for enterprise use. 52This document does not suggest which services agencies should provide to one another. These 53governance issues should be addressed by individual projects or system implementation 54initiatives. 55SOA standards and guidelines are expected to evolve as more SOA-based services are deployed 56and the multi-agency governance teams collaborate. 57Glossary entries and References are noted in BOLD or identified by (source material). 58References are typically full source material citations. Full definitions are in the SOA Glossary.1 591.1.Statutory Authority 60The provisions of RCW 43.105.041 detail the powers and duties of the Information Services 61Board (ISB), including the authority to develop statewide or interagency information services and 62technical policies, standards, and procedures. 631.2.Scope 64These standards apply to state of Washington executive branch agencies, agencies headed by 65separately elected officials, and institutions of higher education (referred to as “agencies” 66throughout this document). Academic and research applications at institutions of higher education 67are exempt. 681.3.Related Policies and Standards 69 • ISB SOA Planning Design Standards 70 • ISB Integration Architecture Standards 71 • ISB Security Standards 72 2.Introduction 73This document provides principles and standards to help ensure SOA-based services are 74designed to meet agency and state business needs and are architected for Tier One enterprise 75use. It’s intended to be use by: 76 • State’s multi-agency SOA Governance teams 77 • State Integration Competency Center (ICC) 78 • Service Providers and Consumers 792.1.Definitions 80• Service-Oriented Architecture (SOA) - SOA is an architectural method or design style that 81 results in and supports shared, reusable services. 82• SOA-based Services – Are modular, swappable functions, separate from, yet connected to 83 an application via well defined interfaces to provide agility. Often referred to as ‘services’ 84 throughout this document they: 85 o Perform granular business functions such as “get customer address” or larger ones 86 such as ‘process payment.’ 71 8 Page 3 of 11
  4. 9Washington Enterprise Architecture Program December 16, 2009 10Service-Oriented Architecture (SOA) Governance Standards EA Committee Endorsed—Version 1.2 87 o Are loosely coupled to a new or existing application. 88 o Have capability to perform the steps, tasks and activities of one or more business 89 processes. 90 o Can be combined to perform a set of functions - referred to as ‘service orchestration.’ 91• State SOA Backplane – Shared, common infrastructure for lifecycle management, 92 registry/repository, policies, business analytics for service metrics; Routing/Addressing, 93 naming, quality of service, communication; Development Tools for security, management, 94 and adapters. 95• Service Providers and Consumers - In general, entities (people and organizations) offer 96 capabilities and act as service providers. Those with needs who make use of services are 97 referred to as service consumers. 98 3.Roles and Responsibilities 99This section establishes the roles of the state’s SOA Steering Committee, SOA Technical 100Advisory Group (SOA TAG), state and agency Integration Competency Centers, and service 101Providers and Consumers for the governance of Tier One SOA-based services. 102The multi-agency SOA governance teams with business and technical representation noted 103below are expected to collaborate and coordinate with the state’s ICC and Information Service 104Board (ISB) policy staff to update the related SOA Planning Design Standards as services, 105technology, and state business needs evolve. 1063.1.SOA Steering Committee 107The SOA Steering Committee provides the strategy and leadership to approve as delegated by 108the ISB and recommend Tier One services for enterprise use and ensure they are implemented in 109ways to achieve targeted benefits. Key responsibilities include: 110 • Approves Tier One services as delegated by ISB or recommends those that require 111 approval 112 • Provides leadership to ensure implementation of Tier One services 113 • Approves and endorses recommended strategies for services 114 • Exercises authority to make decisions, resolve issues and remove barriers 115 • Ensures funding models are identified and sustainable 116 • Ensures proposed services are properly vetted 117 • Articulates the business needs that shape the overall SOA strategy, services offering, 118 and supporting infrastructure. 119 • Ensures Change Management policies and process are defined and followed 120 • Ensures the needs of consumer, provider agencies, and other stakeholders are satisfied 121 by each service 122 • Partners with state’s Integration Competency Center (ICC) to: 123 • Ensure services meet SOA Governance Standards and SOA Planning Design 124 Standards. 125 • Ensure service providers and consumers are utilizing the state’s Backplane for Tier 126 Once service integration and messaging rather than building point to point solutions. 11 Page 4 of 11
  5. 12Washington Enterprise Architecture Program December 16, 2009 13Service-Oriented Architecture (SOA) Governance Standards EA Committee Endorsed—Version 1.2 127 • Plan for potential service candidates that enhance business solutions. 128 • Help develop and evolve SOA standards and guidelines to recommend for statewide 129 adoption. 130Committee membership shall consist of state agency CIOs and business representatives from 131service providers and consumers. 1323.2.SOA Technical Advisory Group 133The enterprise SOA Technical Advisory Group (SOA TAG) makes recommendations to the SOA 134Steering Committee, partners with the state ICC, and agencies’ service providers and consumers 135to ensure services are: 136 • Tier One ready – Support multi-agency use with minimized risk and impact. Designed to 137 meet SOA Planning Design Standards. Are architected and tested to ensure security, 138 scalability, availability, performance, business continuity, problem and change 139 management, and sustained funding. 140 • Designed to meet ISB standards 141 • Provider is defined and has capability and capacity 142 • Service level agreements are complete 143 • Ensure Change Management process meet Tier One technical requirements 144 • Services and service contracts are published on state SOA registry/repository 145 • Used where possible and best fit for purchasing new or upgrading legacy applications 146SOA TAG membership shall consist of state agency architects, application developers, and 147business representatives or analysts to represent service providers and consumers. 1483.3.Change Management 149Change management standards define the way in which the state and agencies will manage and 150maintain new or acquired services, changes to service interfaces and design (both public and 151private), and the state shared service infrastructure. Change management includes the 152management of the initial deployment of a service. 153Change management is the responsibility of the service provider, stakeholders, the SOA Steering 154Committee, SOA Technical Advisory Group, and state and agency Integration Competency 155Centers (ICC). 1563.3.1.Service Provider 157Each service shall have an agency responsible for provisioning the service. This agency is called 158the “service provider.” The provider may represent the interests of several agencies through a 159program office or similar organizational unit; however, there is a single entity responsible for 160provisioning the service. 161The provider is responsible for the implementation and proper functioning of the service. The 162service provider shall follow established change management processes subject to the review 163and approval/endorsement of the multi-agency governance teams for Tier One services. 164The provider is responsible for identifying a group of stakeholders of the service. This should 165primarily include agencies responsible for current or planned consumer systems that use (or will 166use) the service, but may also include other stakeholders. 14 Page 5 of 11
  6. 15Washington Enterprise Architecture Program December 16, 2009 16Service-Oriented Architecture (SOA) Governance Standards EA Committee Endorsed—Version 1.2 167The provider shall consult with the stakeholder group when considering changes to a service’s 168real world effect or interface. This consultation shall begin with a notification, using the service 169repository’s notification capabilities (described in [Service Repository Solution Set]) and other 170appropriate mechanisms. 171. 1723.3.2.Infrastructure 173The state’s Integration Competency Center (ICC) will not typically be the provider of a service, yet 174will manage changes to the state SOA Backplane with supporting shared infrastructure. 175The ICC shall be responsible for notifying users of the infrastructure about planned changes, 176consulting with users, and coordinating with users’ project schedules. 1773.4.Configuration Management 178The provider of a service is responsible for assigning version labels to each new version of a 179service, according to the following convention. 180A version label has four parts: a major version number, a minor version number, a point version 181number, and a build number. For example, version 1.2.3.4 has major version number 1, minor 182version number 2, point version number 3, and the build number is 4. 183A point version increment indicates a cosmetic change to a service interface that has no impact 184on the behavior of the service or the interaction of consumers with the service. An example 185would be correcting or adding documentation to the interface description. 186A minor version increment indicates a change to the interface that has very minor or no impact on 187existing consumer implementations. That is, the new service interface is backwards compatible 188with previous versions. 189A major version increment indicates a change to the interface, or policies associated with use of 190the service, that has significant impact on existing consumer implementations. 191The service provider is responsible to ensure version updates are posted to the service repository 192to reflect the new version and all service consumers are notified of any changes. 1933.5.Quality Assurance 194Mechanisms are necessary to ensure that services reliably achieve their advertised real world 195effect, and that each service conforms to the [SOA Planning Design Standards.] 1963.5.1.Assurance of Real World Effect 197The provider of a service is responsible for assuring the quality of the service, in particular making 198sure the service properly achieves the stated real world effect. The ICC can assist the provider 199in fulfilling this responsibility (for example, by providing a version of the infrastructure platform 200dedicated to testing and service metrics for Tier One services utilizing the state Backplane), but 201the final responsibility rests with the provider . 202Providers shall consider providing tools to assist consumers in testing consumer systems that use 203the service. These tools could include: 204 • Providing a standalone implementation of the service interface(s) that a consumer can 205 use in developing a consumer system, including basic testing. 206 • Deploying the service in a test environment managed by the ICC to support more 207 sophisticated testing and to test performance. 17 Page 6 of 11
  7. 18Washington Enterprise Architecture Program December 16, 2009 19Service-Oriented Architecture (SOA) Governance Standards EA Committee Endorsed—Version 1.2 2083.5.2.Standards Conformance 209Services identified in the state’s service registry/repository or deployed on the state’s SOA 210backplane or integration infrastructure must conform to all Information Services Board standards. 211The SOA Technical Advisory Group (TAG) and state ICC shall be responsible for ensuring that 212any service deployed on the state’s shared, common SOA backplane, state ICC Domain Service 213Registry or integration infrastructure conforms to ISB standards. 2143.6.Service Level Agreement 215When establishing a service-level agreement for a service, the parties (provider and consumer(s)) 216shall consider addressing the following issues in the agreement: 217 • Availability requirements (with what probability is the service available for interaction; 218 provisions for negotiations and notifications for outages) 219 • Responsiveness requirements (how quickly does the service respond, both 220 synchronously and asynchronously) 221 • Impacts, risks to enterprise and agency services, data stores, and systems. 222 • Privacy requirements (what restrictions are there on what the parties may do with 223 information that they obtain as part of the service interaction) 224 • Change management processes 225 • Funding model or cost model 226The provider of a private service shall negotiate change management processes with consumers 227of the service 228 • Under what conditions (including how often) a provider may change the service’s 229 interface 230 • How far in advance of a proposed change the provider must notify consumers of the 231 intent to change 232 • How to resolve disputes between consumers regarding the viability or desirability of a 233 change to the interface 234 • How the partners will fund and implement system changes that result from the interface 235 change 2363.7.Service Reuse 237Services and interfaces fall under the Enterprise Architecture Commonality Principle. Services 238and interfaces shall be designated as Tier One common assets upon demonstration of a clear 239business case; once designated as common, a business case is required for an agency to invest 240in and provide a duplicate service or interface. 241It is within the role of state and agency ICC’s to promote the reuse of services and interfaces. 242Processes for developing and defining Tier One services for reuse should be defined by the SOA 243Steering Committee, SOA TAG and state ICC as the services architecture and service metrics 244are documented. 245Providers can attach policies to services that govern their reuse, and incorporate these policies 246into the service-level agreement associated with the service. For instance, a provider can 247prevent users from “repackaging” a service (simply wrapping the service interface with another 248service that the user provides) and changing the conditions of use (for instance, by charging 249users for access to the service.) 20 Page 7 of 11
  8. 21Washington Enterprise Architecture Program December 16, 2009 22Service-Oriented Architecture (SOA) Governance Standards EA Committee Endorsed—Version 1.2 250 4.State ICC Domain 251The state’s Integration Competency Center (ICC) is maintained and operated by the Department 252of Information Services. The state ICC provides people, processes, and resources to ensure 253enterprise efficiencies and help agencies meet business and technical needs. It uses a 254collaborative approach to provide shared-services based solutions for agencies and multi-agency 255applications. 256The state ICC Domain model maximizes collaboration and communication among the state ICC 257and agencies. The state’s ICC also supports the state SOA backplane with service registry, 258infrastructure, and system integration. 259The state ICC is a key to the delivery of quality and reliable enterprise SOA and service 260integration services, and is an important facilitator of an enterprise approach to SOA and 261integration. 262The main objective of the ICC is to improve the efficiency and effectiveness of SOA-based 263services and system integration activities, through close coordination of shared SOA backplane 264and integration infrastructure with system implementation projects. This coordination is the 265responsibility of a team of skilled technical staff that has two principal roles: 266 • The state ICC maintains and monitors the state’s SOA backplane and integration 267 infrastructure. 268 • The state ICC SOA development support function helps agency project team in the 269 design and build of their services and integration connections (adapters) into the 270 integration infrastructure. 271 • The ICC may assist agencies/service provider s assemble and maintain service 272 documentation (service metadata) for the application interactions. The development 273 function also includes ensuring that agencies and projects are aware of available shared 274 integration infrastructure and how to use it to accomplish project objectives. 275The state ICC will maintain a single statewide registry/repository of Tier One SOA-based services 276and system interfaces. 277The ICC and multi-agency SOA TAG works with service providers to ensure service models are 278consistent in format and content across the enterprise, ensures that each model contains proper, 279consistent metadata, owner agency identified as accountable for the service, and ensures that 280models reflect the reuse of existing services to meet the needs of new projects. 281Service reuse is more likely to occur when services are posted to the state’s registry/repository. 282Service publication helps, minimize redundancy and promote collaboration and coordination. 283Service metrics will provide quality of service, performance, and reuse information for 284investment, design, deployment, and maintenance planning. 285The state’s ICC is responsible for provisioning state SOA backplane. The SOA backplane will 286include mechanisms for lifecycle management such as registry/repository, policies, and service 287orchestration; business analytics for service metrics, development tools for security, 288management, and adapters; and communications for routing, naming, quality of service, and 289transformation. 290Individual agencies may form an organizational unit similar to an ICC to support SOA services 291within an agency. The state’s ICC may serve as a resource and consultant to agency ICC as 292needed. 23 Page 8 of 11
  9. 24Washington Enterprise Architecture Program December 16, 2009 25Service-Oriented Architecture (SOA) Governance Standards EA Committee Endorsed—Version 1.2 293 5.Glossary 294REAL WORLD EFFECT The actual, desired result of the service (e.g. ‘Get 295 customer information.) SOA-based services are 296 designed to meet business needs. A service consumer 297 is a participant that interacts with a service in order to 298 realize the real world effect produced by a capability to 299 address a consumer need. 300SERVICE CONDITIONS Service-oriented architecture (SOA) is a style of 301 application architecture. According to Gartner, an 302 application is SOA-based service when it meets these 303 five conditions: 304 1. It is modular. 305 2. The modules are distributable. 306 3. Software developers write or generate interface 307 metadata that specifies an explicit contract so that 308 another developer can find and use the service. 309 4. The interface of a service is separate from the 310 implementation (code and data) of the service provider. 311 5. The service is shareable — that is, designed and 312 deployed in a manner that enables them to be invoked 313 successively by disparate consumers. 314 315SERVICE METRICS Monitoring services provides audit, logging, charge- 316 back, financial reporting for investments, design, 317 deployment, maintenance planning, and other purposes 318 via metrics such as: 319 Quality of Service (QoS) and Performance 320  Number of requests 321  Number of failed requests 322  Number of successful requests 323  Service time 324  Maximum response time 325  Last response time 326 Reuse Metrics 327 • Number of services deployed 328 • Number of consumer applications deployed 329 • Number of services and number of consumers 330 • Number of services shared by applications 331 332TIER ONE Statewide Enterprise Architecture business processes, 333 data, or technologies that are common among the 334 majority or to all state agencies. 335 Tier Definitions: 336  Tier One: Across/among agency systems 337  Tier Two: Within an agency 338  Tier Three: Sub- agency level 339 These three different tiers depend on the degree to 340 which they should be common, and what other entities 26 Page 9 of 11
  10. 27Washington Enterprise Architecture Program December 16, 2009 28Service-Oriented Architecture (SOA) Governance Standards EA Committee Endorsed—Version 1.2 341 with which they should be common. A description of the 342 state’s Tiers is available at: http://isb.wa.gov/committees/ 343 enterprise/concepts/ 344 6.References 345OASIS Reference Architecture Foundation for Service Oriented 346 Architecture 1.0, OASIS Committee Draft 2 (Authoritative 347 PDF), Oct. 14, 2009 348OPEN GROUP SOA Governance Framework, Technical Standard, The 349 Open Group, Aug 2009. 350Service Repository Solution Set Washington State Department of Information Services, 351 Enterprise Architecture Program (2006). Service 352 Repository Solution Set, Information Services Board. 353SMG Washington State Information Services Board, 354 Enterprise Architecture Committee (2006). Service 355 Modeling Standards, Information Services Board 356SOA Design Standards Washington State Department of Information Services, 357 Enterprise Architecture Program (2009). SOA Design 358 Standards, Information Services Board. 359 360 7.Document History Date Version Editor Change July 10, 2009 1.0 Paul Douglas Initial Draft, based on ISB Integration Jerry Britcher Architecture Governance and SOA Noel Morgan Target Architecture findings JoAnne Kendrick Documenter Team Sept 3 to Oct 23, 1.0 Paul Douglas Moved Purpose up and Document 2009 Context to back Documenter Team Added Statutory Authority to align with other ISB standards Updates State ICC Domain section – similar to ISB Integration Architecture Governance Standards Oct 5 DT meeting comments. Oct 14 EA Committee preview Aligned governance roles with SOA Baseline/Target. Aligned governance roles Shared Services Model at: http://dis.wa.gov/news/ publications/ 29 Page 10 of 11
  11. 30Washington Enterprise Architecture Program December 16, 2009 31Service-Oriented Architecture (SOA) Governance Standards EA Committee Endorsed—Version 1.2 Date Version Editor Change WA_shared_services_model.pdf Dec7, 15, 2009 1.2 Paul Douglas Added Service Metrics concepts and Glossary entry Documenter Team Edits for clarity and consistency Added OASIS and Open Group to References Clarified Change Management responsibilities Clarified Governance roles including SOA Steering Committee approves Tier One services (as delegated) or recommends those that require ISB approval Dec 16, 2009 1.2 Endorsed by EAC Adopted by ISB 361 362 8.Document Context 363This document is within the scope of state’s Service-Oriented Architecture (SOA) initiative. The 364Target Architecture is a deliverable within the Initiative Charter adopted on July 10, 2008 by the 365Information Services Board (ISB) and available at: 366http://dis.wa.gov/enterprise/enterprisearch/soa_initiative.aspx. 367The SOA Initiative is designed to enable State Strategic IT Plan Goals. 368Initiative Stewards: 369• Bill Kehoe, Department of Licensing 370• Frank Westrum, Department of Health 371Initiative Architect: 372• Paul Warren Douglas, Department of Information Services 373Documenter Team: 374• Documenter Team consisted of 27 multi-agency subject matter experts representing 11 375 agencies. 376 32 Page 11 of 11

×