1

                        Primary Contributors2
                                               3
                        ...
2Washington Enterprise Architecture Program                                                                               ...
5Washington Enterprise Architecture Program                                                   January 14, 2010
 6Service-O...
9Washington Enterprise Architecture Program                                              January 14, 2010
 10Service-Orien...
12Washington Enterprise Architecture Program                                           January 14, 2010
 13Service-Oriente...
15Washington Enterprise Architecture Program                                                  January 14, 2010
 16Service-...
18Washington Enterprise Architecture Program                                                  January 14, 2010
 19Service-...
21Washington Enterprise Architecture Program                                               January 14, 2010
 22Service-Ori...
24Washington Enterprise Architecture Program                                                   January 14, 2010
 25Service...
27Washington Enterprise Architecture Program                                                     January 14, 2010
 28Servi...
30Washington Enterprise Architecture Program                                                 January 14, 2010
 31Service-O...
33Washington Enterprise Architecture Program                                             January 14, 2010
 34Service-Orien...
Upcoming SlideShare
Loading in...5
×

Download It

415

Published on

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

  • Be the first to like this

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

No notes for slide

Download It

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

×