1

1
Primary Contributors
2

Paul Warren Douglas3
Department of Information Services
Initiative Architect4
5
Bill Kehoe
Department of Licensing6
Initiative Steward7

Frank Westrum8
Department of Health9
Initiative Steward
10
Stephen Backholm11
Department of Social and Health Services
12
Jerry Britcher13
Department of Social and Health Services

Gary Dubuque
14 Service Oriented Architecture (SOA)
Department of Revenue15 Planning Design Standards
David Jennings16
Department of Health
17 ISB Standards
JoAnne Kendrick
Department of Information Services18 Version 1.21.2
19
Daniel Mercer
Labor and Industries20 January 14, 2010

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-Chairs2

................................................................................................................ 10 497.................................................................................................................................................................................................1......... 5 32 4...................................................... 10 486............................................................................................5......................................................... References..........................................................1......................................................................................................................................................................................... Funding......3.......... 4 294................................ Service Modeling.............. Statutory Authority...... Related Policies and Standards.. Service Description.........................8..... Performance.................. Service Principles....................................................................................... Purpose.................................................8 395.................... Service provider modules must be shareable........ 10 46 5.................. The modules must be distributable.................1.....................................4...3.....................1.......2.. 11 508......... 9 43 5......... 9 45 5......................................................................................3.......7.3................. Change Management.................................................................... 7 37 4........ 14 53 5 Page 2 of 14 6 ................................1..................... 8 41 5..........................................................2 21 Table of Contents 221..................................................... Service Conditions and Planning Design Standards................5..............................................................3................................... 4 283........... 5 31 4............................................................................ 3 262......................... Service Metadata............................1................................. 3Washington Enterprise Architecture Program January 14........................................................................................................................................ 3 24 1...... Module interfaces must be discoverable.............................................................. Scalability............... Problem Management..........................................................................3...8 38 4...................... 12 519................................ 3 27 2...... 12 5210............................2........................................................... 9 44 5.................................. Service Planning..........................................................1... 3 25 1.............2..................................................6 34 4................................................... 10 47 5.........................4...... Document History.................... Glossary.......... 7 36 4............... Definitions........................................... Service Naming................................... The service must be modular................................................................................................................................................................................................................. Service Features................................................ 7 35 4...................................................................................... 2010 4Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1...................... Security................................................................2............. 3 23 1....................... Availability.............................................................. 8 40 5.................................... Scope................................ 9 42 5....................................................................................................................... Document Context........................ Service modules must be swappable.............................................6 33 4..............5 30 4...6...............3.................... Introduction................... Business Continuity..................

711. 10 Page 3 of 14 11 . Purpose 55These standards provide the SOA principles. agencies headed by 73separately elected officials. 57This document contains primarily conceptual and logical level standards to help service providers 58design Tier One ready SOA-based services and enable SOA governance.105.3.2. and maintain Tier One SOA-based enterprise services. Physical level design 59standards and guidelines are expected to evolve as more Tier One services are deployed and the 60multi-agency governance teams collaborate. standards. 61These standards are not a detailed guide on how to develop SOA-based services. and procedures. Academic and research applications at institutions of higher education 75are exempt.1. Statutory Authority 68The provisions of RCW 43. 761. however. Full definitions are in the SOA Glossary.041 detail the powers and duties of the Information Services 69Board (ISB). standards. and application 56design principles to design. service conditions. guidelines. Scope 72These standards apply to state of Washington executive branch agencies.2 54 1. 65Glossary entries and References are noted in BOLD or identified by (source material). and reference architectures are expected to evolve from the 63multi-agency SOA Steering Committee and Technical Advisory Group as more services are 64published with the assistance of the state’s Integration Competency Center. It’s intended to be use by: 84  Enterprise Architects 85  Business Analysts 86  Application Managers and Designers 87  State’s multi-agency SOA Governance teams 88  Service Providers and Consumers 89 90 91 91 Draft SOA Initiative Glossary document currently available on SOA Team Site. 66References are typically full source material citations. 7Washington Enterprise Architecture Program January 14. 62technical standards. Related Policies and Standards 77  ISB SOA Governance Standards 78  ISB Integration Architecture Standards 79  ISB Security Standards 80 2. deploy. and institutions of higher education (referred to as “agencies” 74throughout this document).1 671. 2010 8Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1. Introduction 81This document provides principles and standards to help ensure SOA-based services are 82designed to meet agency and state business needs and are architected for Tier One enterprise 83use. including the authority to develop statewide or interagency information services and 70technical policies.

Often referred to as ‘services’ 97 throughout this document they: 98 o Perform granular business functions such as “get customer address” or larger ones 99 such as ‘process payment.In general.2 922.Shared. common infrastructure for lifecycle management such as a 105 services registry. services that can be readily re- 128assembled. swappable functions. 114Service loose coupling – Reduces risk that a change in one application module will force a 115change in another application module. or disassembled into their 117functional components. separate from. Those with needs who make use of services are 109 referred to as service consumers.1. both a service consumer and a service provider 121should have everything they need to consume or provide the service. 101 o Have capability to perform the steps.’ 100 o Are loosely coupled to a new or existing application. yet connected to an 96 application via well defined interfaces to provide agility. Service Principles 111The following information is provided to help the reader understand general principles for 112planning and designing SOA-based services. quality of service. reusable services. management. services hide their logic 123from service consumers. 103 o Can be combined to perform a set of functions . 116Loosely coupled services may be joined to create composite services. tasks and activities of one or more business 102 processes. 2010 13Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1. even if they use different system technologies 118Service contract – Services adhere to a service contract as defined by one or more service 119description documents and maintained via a central registry. and adapters. 95 SOA-based Services – Are modular. 122Service abstraction – Beyond what is described in the service contract. policies. must not share state. business analytics. 120Starting from a service description (a contract).’ 104 State SOA Backplane . Definitions 93 Service Oriented Architecture (SOA) . 16 Page 4 of 14 17 . 131Service autonomy – Services must have authoritative control over the logic they encapsulate.An architectural method or design style that results in 94 and supports shared2. to assemble other composite services 129Service componentization – Services must have well defined interfaces. 124Service reusability – Services are not duplicated and logic is granularly divided in such a 125manner as to promote service reuse. entities (people and organizations) offer 108 capabilities and act as service providers. Development Tools for security. 130and must communicate by messages. the state’s Shared 15Services Model is broader. 110 3. 142 While some overlap may exist for future SOA-based services that are shared. 106 communication. 126Service composability – Collections of services are assembled to form composite services.referred to as ‘service orchestration. 127Composite services are composed of individual. (or re-orchestrated). routing/addressing. 12Washington Enterprise Architecture Program January 14. See Governor’s Directive 09-02. Tier One SOA Planning and Design Standards are 113provided in Section 4. 107 Service Providers and Consumers . unique.

162 Business analysts and architects shall collaborate to ensure business processes are unique. Service Modeling 166 Each service must exist within the context of at least one business process.) 20 Page 5 of 14 21 . 1654. It also 137allows the service to be replaced or superseded with another service that supports the same 138interface. performance. 18Washington Enterprise Architecture Program January 14. as well as those for 170 structure and behavior to indicate the roles and functions of each service (See ISB Integration 171 Architecture Service Modeling Standards. 169 The service provider must maintain models for business processes. Planning design 148standards are provided below in order for the service to meet the desired condition. be 133highly secure. 150This enables flexibility to solve complex problems by assembling a set of small. and easily found 142by other agencies. simple 151components that work together. 143Service identification – Services must be uniquely identified. 1494. a service plays a 167 specific role in accomplishing a business process that achieves demonstrable business 168 value. 155 Services shall be designed to be loosely coupled. 163 well defined. 157 Developers shall enter interface metadata or use tools to generate interface metadata that 158 specifies an explicit service contract so that another developer can find and use the service. coded unambiguously. 134Service encapsulation – Separates the contractual interface from its implementation. This 136allows for changes and improvements to the service without impacting service consumers. 144Service metrics – Provides information for quality of service. No hidden assumptions must be necessary to invoke the service. 2010 19Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.1. 139Service provisioning – Each service shall have a provider responsible for provisioning the 140service. Service Conditions and Planning Design Standards 147SOA-based application modules are constructed to meet service conditions. and documented. Helps 145agencies plan for and maintain services. 159 Everything needed by the service to provide its functionality must be passed to it when it is 160 invoked (service boundary explicitness.2 132Service optimization – Services must be constructed modularly.) All access to a service must be via its exposed 161 interface. and that service candidates are capable of meeting business 164 needs and changes. and reuse. and designed for high performance and scalability. secured and versioned. Those with needs who make use of services are referred to as service consumers. The 135internal mechanisms and data structures of a service are hidden behind a defined interface.1. Modularity enables loose coupling and helps make components swappable 154because a service provider can be replaced without causing unintended side effects. The service must be modular.1. 152Rationale: Each service provider is largely autonomous. 156 Service interfaces must be clearly defined and documented. addressing one function or a set of 153related functions. 146 4. 141Service discoverability – Services must be easily identified by their purpose.

so other 194developers can find and use the service. 175 The description of each service shall include a contextual summary that establishes the name 176 of the service and a brief (single paragraph) description of the real world effect of using the 177 service. minimize redundancy of duplicate services. 200 Tier One services shall be published on the state ICC service registry. The modules must be distributable.2 172 The description of each service shall include the business process model(s) for which the 173 service was designed. 179Service components are able to run on disparate computers and communicate with 180each other by sending messages over a network at runtime.wa.gov/policies/eaprogram. Service 188 interfaces shared between two or more agencies in the state enterprise shall conform to one 189 or more state’s service interaction profiles. 1914. 206 Software interface definitions shall be maintained in the state’s ICC SOA Services Registry so 207 they are available to application developers.2. the service 209 has security related requirements. these services shall meet the SOA Planning Design Standards and follow the SOA 214 Governance Standards which establish requirements for qualifying Tier Two candidates. Agencies are encouraged to publish services for reuse. 2010 23Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1. SOA applications are inherently distributed applications. 183 The service provider shall be responsible for creating a Service Contract for each service 184 and negotiating with each service consumer. 197 Service providers shall use the ISB Service Repository Solution Set Standards at: 198 http://isb. Service consumers that interact with an interface 190 should likewise conform to that interface’s profile. 203 Once designated as Tier One. 24 Page 6 of 14 25 . services shall be registered in the state ICC SOA Services 204 Registry in order to enable discovery. Module interfaces must be discoverable. 195Rationale: Developers write or generate technical interface descriptions (interface metadata) so 196that another developer can find and use the service. The state’s ICC service 201 registry is an online catalog that contains the names and information about each service. and 205 maximize reuse. This description may be maintained manually and shall be available 174 on the state’s service repository for Tier One services. 202 including associated attributes like metadata. 210 Agency Providers with Tier Two services that are likely candidates for adoption by other 211 agencies shall review these standards before registering services in the state ICC Service 212 Registry. Service contracts shall be posted on the state 185 ICC SOA Services Registry to communicate information about the service. Software developers write or 193generate interface metadata that specifies an explicit service contract. and lists other key service attributes.aspx that provide functional and supporting features for 199 the state ICC SOA Services Registry. In order to be designated as 213 Tier One. 181Rationale: Services are typically spread out over multiple physical locations.aspx for service integration and messaging.wa.3. 22Washington Enterprise Architecture Program January 14. A service may be 182used by multiple consumers. 186 Service providers and consumers shall follow the ISB Integration Architecture Standards at: 187 http://isb. 192Servicesmust be clearly defined and documented.gov/policies/eaprogram. 1784. 208 The Service Contract indicates when a Service Level Agreement is required.

233 what the service accomplishes. 221 o For example “verify zip code. rather than how the service works. 249 Each service interface must have a set of metadata categories and values. as appropriate.2 2154. 255 Each exposed class and service interface must include an identifier in service’s registered 256 metadata. rather. nor any technical details about 226 how the implementation works. 26Washington Enterprise Architecture Program January 14. 218 The name of the service must encapsulate the essential aspects of the real world effect of the 219 service.2. 251 The metadata for a service must include the service provider that owns and governs the 252 structure of the service and the current version of the service and messages. 28 Page 7 of 14 29 . 236 Services shall contain a list and brief (single paragraph) description of the principal 237 information and entities involved in interaction with the service via its actions.3. based on experience implementing the integration 241 architecture. verify correct address” are representations of services 222 based or named after the real world effect and are easily understood by business and 223 technical staff. 225 nor the agency or organization that provisions the service. 227 Notes: 228 o Service naming and other details are included in the Service Contract.3.) 242 All aspects of the description must be free of any implementation details or dependencies. 247 Each attribute must identify its data type and other parameters that specify the range of its 248 values.) 2314. Services usually map to a business task.3. that is. 2454. the description must describe the business effects of the service. to 250 define the context of the element. 229 o Additional service naming conventions may be developed by the multi-agency 230 governance teams (see SOA Governance Standards. Service Metadata 246 Each service interface must have a complete definition that captures its semantic meaning. 2010 27Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.1. Service Description 232 Services shall contain a complete description of the real world effect of the service (that is. 224 The name shall not indicate the underlying information system that implements the service.3. 243 The description shall not refer to particular databases or systems in the description of the real 244 world effect. the name of the service must represent what the service accomplishes (in 220 business terms). Service Naming 216 Services must be unambiguously named based upon their purpose and to best represent the 217 task in what is known as the real world effect. 253 The name of each service interface must encapsulate the meaning of the service in a way 254 free of any reference to implementation detail. 238 Services shall contain a list of the principal metadata categories and values for the service (a 239 future version of these standards or related guidelines may specify a standard set of 240 metadata categories for services.) 234 Services shall contain a list and brief (single paragraph) description of each of the actions that 235 can be performed on the service.

2010 31Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1. This service condition ensures each provider module in an SOA application can be 283invoked successively by disparate consumers. It also enables multiple development teams to create interchangeable 266provider modules. 292 5.1. 279Services must be designed and deployed in a way that enables them to be invoked 280successively by disparate applications in support of diverse business activities. 273 Services that use functionality or information provided by other systems or services shall 274 access that functionality or information in a way that minimizes dependencies on those other 275 systems’ implementation details. 297  Services shall have the ability to be audited (also see Service Metrics. 267The consumer and the provider can use disparate programming languages. 271 Services shall be designed so that modules may be replaced without affecting the 272 consumers. 290 Service providers are responsible to ensure changes follow the SOA Governance Standards 291 and Consumers are made aware of all changes. 258The service module can be replaced by another module that offers the same service 259without disrupting modules that used the previous module. departments or separate agencies and entities can use same 282service.) 32 Page 8 of 14 33 . 261Rationale: This separates the implementation (the service provider module's code and data) from 262the interface metadata.5. 281Rationale: Multiple agencies. This is accomplished by 260separating the interface design from the module that implements the service. where possible. Service Features 293The following sections describe service design features. 276 Services shall avoid service nesting. The 287 service provider is responsible to ensure the service follows the SOA governance standards 288 process. Service modules must be swappable. A copy of the interface metadata is accessible to other developers 263separately from the code that implements the provider component. Security 296  Each service shall be designed to ensure provider and consumer security. application servers 268and operating systems. 264This makes it possible for the consumer developer to use the service without having a copy of the 265provider software module. 286 The service shall be posted on the state ICC registry once designated as Tier One.2 2574. to minimize service dependencies and 277 reduce risk. 269 Services that make functionality or information available to other services shall do so through 270 separate well defined interfaces. 289 The portfolio of Tier One services shall be made available on the state’s ICC services registry. 294Services shall be tested to ensure they meet the following design features: 2955. 2784.4. which are similar to application design. Service provider modules must be shareable. 284Developers can write different consumer application modules that use the same service as long 285as they conform to the conditions specified in the interface contract. 30Washington Enterprise Architecture Program January 14.

) 317  The service provider shall coordinate with agency consumers in advance of scheduled 318 maintenance that will affect agencies or users in accordance with the Service Level 319 Agreement.4. 34Washington Enterprise Architecture Program January 14. Scheduled maintenance periods shall be identified in each SLA and service 315contract. 3245. Service maintenance is performed when necessary (hardware and software upgrades. Business Continuity 332  The service shall be implemented as fault tolerant. 322  Service monitoring and automated alerting and logging shall be implemented when possible 323 to monitor each service as well as report state and utilization. capacity. and 305 how many transactions per minute. 299  Services that interface with legacy systems shall also ensure the systems are not exposed to 300 vulnerable security threats or breaches. faulty hardware replacement.2. 335  Business continuity information shall also be included within the service contract. 2010 35Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1. 3125. 316software patches. Scalability 302  Service providers shall architect the service so it is scalable to meet current and future 303 consumer needs. Performance 325  Service performance must be monitored and reviewed to plan for the addition of resources 326 before performance is significantly impacted.5. and fully redundant to allow for 310 the addition of resources without system downtime. 3315. 3015. including backend applications must be monitored for increased server 328 utilization. as well as 336 services that require an SLA between the provider and consumers.2 298  Vulnerability testing shall occur before services are deployed. 320  The service provider’s technical and operational support staff shall monitor availability and 321 performance of the service. 304  The provider shall identify the service capability. 306  Services shall be designed to handle the number of users per each Service Level Agreement 307 and architected to be scalable to several times the number identified in its current 308 configuration. 333  The service provider shall perform full-system backups for onsite and off-site storage on a 334 scheduled basis.3. and software. Availability 313Service provider shall strive to make the service(s) available per agreed upon Service Level 314Agreement (SLA). 327  Agency consumers. The service must also enable scalability 311 of backend applications through load balancing. with appropriate hardware. etc. 329  Service providers and consumers shall ensure adequate testing at initial deployment and 330 every time a change is made in the system. 36 Page 9 of 14 37 . 309  The service component architecture shall be highly available. expected number of users.

Request for Proposals (RFP) shall require proposed vendors to identify 372 and describe proposed solution’s SOA readiness and SOA architecture. 371 Where applicable. 38Washington Enterprise Architecture Program January 14. escalating and solving 347 problems. 369 SOA-based services must support interoperability and portability and as much as reasonably 370 possible be independent of any specific vendor’s proprietary product. Changes shall be 361 managed to promote or provide stability and minimize the impact of the changes to the 362 agencies. 340 Provides automated triggers or scheduled problem management through use of monitoring 341 tools. (the use of recursive or sub-layered. 367 Agencies shall check the state’s ICC Doman Service Registry to share or reuse existing SOA 368 services before building or buying new services. 345 The service provider shall provide seamless integration of processes that ensure agency 346 consumer problem resolution satisfaction by tracking. 342 The service provider shall notify agencies of all events that have or may have an adverse 343 affect on service delivery to customers. alerting.8.7. 3595. Funding 351Funding models are an important part of ensuring longevity and stability of Tier One services. 354 Service providers and consumers shall know how much the business unit that operates an 355 SOA service will charge another business unit that has an application that consumes the SOA 356 service. Service Planning 366 Tier One services shall have a clear business owner and service provider. 348 The service provider shall provide help assistance for consumers via an online knowledge 349 base or Customer Service Representatives shall be available to assist by telephone. dependent services). 352 The business owner/service provider is responsible to ensure funding models associated with 353 building and maintaining Tier One SOA services are identified. 365 6. 376 Nesting of services. Change Management 360  All changes to the service must follow the SOA Governance Standards. 373 SOA-based acquisitions shall include language for vendor to identify its architecture and 374 potential to loosely couple with the state’s shared infrastructure and services where 375 applicable. 3505. 2010 39Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1. 40 Page 10 of 14 41 . shall be 377 discouraged in order to minimize complexity and increase maintainability. 344 The service provider shall notify agency consumers of all failed processes. Problem Management 338 The service provider shall be responsible for problem management and shall ensure minimal 339 impact to service consumers.2 3375. 363  Changes shall be planned and communicated with agency consumers and the SOA 364 governance teams for statewide changes. 357 Funding models shall be identified in service contracts and included in Service Level 358 Agreements.6.

Version. Glossary 379NESTING Practice of making successive service calls to other 380 functions or dependent services. 383SERVICE CONTRACT Contains a list of the functional and non-functional 384 service attributes. an 401 application is SOA-based service when it meets these 402 five conditions: 403 1. 413 414SERVICE METRICS Monitoring services provides audit. charge- 415 back. maintenance planning. design. 405 3. designed and 411 deployed in a manner that enables them to be invoked 412 successively by disparate consumers. Quality of services. and Invocation. 399SERVICE CONDITIONS Service Oriented architecture (SOA) is a style of 400 application architecture. The service is shareable . 2010 43Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1. 388 Semantics. and Process.2 378 7. Nested SOA-based 381 services is discouraged due to complexity.g. 404 2. what 386 the service accomplishes. A service consumer is 396 a participant that interacts with a service in order to 397 realize the real world effect produced by a capability to 398 address a consumer need. and performance. 393REAL WORLD EFFECT The actual. ‘Get 394 customer information.’) SOA-based services are 395 designed to meet business needs. According to Gartner. 408 4. SLA. Services should minimize the 391 amount of state information they manage and hold long 392 the information is held. such as: header with Name. availability. Service Type. desired result of the service (e. 410 5. 416 deployment. financial reporting for investments. Operations. 389STATE/STATELESS Describes the behavior of the service including its 390 specific set of instructions. and other purposes 417 via metrics such as: 418 Quality of Service (QoS) and Performance 419  Number of requests 420  Number of failed requests 421  Number of successful requests 422  Service time 423  Maximum response time 424  Last response time 44 Page 11 of 14 45 .that is. 387 and Non-Functional such as security. 385 Owner. Software developers write or generate interface 406 metadata that specifies an explicit contract so that 407 another developer can find and use the service. 42Washington Enterprise Architecture Program January 14. 382 maintainability. The modules are distributable. The interface of a service is separate from the 409 implementation (code and data) of the service provider. Responsibility Assignment. It is modular. logging.

0.gov/committees/enterprise/concepts/ 442 Also see ISB EA Over-Arching Principles. 431 data. DOT Design Standards 48 Page 12 of 14 49 . DIS Noel Morgan. 2009 453OPEN GROUP SOA Governance framework. April 2009 448INTEGRATION ARCHITECTURE ISB Integration Architecture Standards and Solution Sets 449 at: http://isb. DOT September to Oct 1. 2009 Douglas.wa. References 447GARTNER SOA Overview and Guide to SOA Research.wa. 14. 46Washington Enterprise Architecture Program January 14. Document History Date Version Editor Change Summary August 31. 433 Tier Definitions: 434  Tier One: Across/among agency systems 435  Tier Two: Within an agency 436  Tier Three: Sub-agency level 437 These three different tiers depend on the degree 438 to which they should be common.gov/policies/eaprogram.doc 446 8. 2010 47Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1. Technical Standard. Aug 2009.gov/committees/enterprise/architecture/over 445 archingprinciples. OASIS Committee Draft 2 (Authoritative 452 PDF).0 Paul Warren Initial Draft Douglas. The 454 Open Group. or technologies that are common among the 432 majority or to all state agencies. and what other entities 439 with which they should be common. 2009 1.0 Paul Warren Revised Service Principles 12.aspx.wa. A description of the 440 state’s Tiers is available at: 441 http://isb. 450OASIS Reference Architecture Foundation for Service Oriented 451 Architecture 1. including 443 Commonality at: 444 http://isb. 455 456 9. DIS Combined Service Conditions and Noel Morgan. Oct.2 425 Reuse Metrics 426  Number of services deployed 427  Number of consumer applications deployed 428  Number of services and number of consumers 429  Number of services shared by applications 430TIER ONE Statewide Enterprise Architecture business processes.

2009 1.2 Paul Warren Douglas Stakeholder revisions for clarity and 7.2 Paul Douglas Adopted by Information Services Board 52 Page 13 of 14 53 . 2009 1. Removed physical design style Documenter Team references.2 Paul Warren Douglas Added Service Metrics concepts and Glossary entry DT Refinements Minor edits for clarity and consistency Added OASIS and Open Group to References Clarified Service Contract is posted on central registry to provide information about the service Dec 16. 2010 1.50Washington Enterprise Architecture Program January 14. 2009 to Jan 1. 2010 51Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1. Clarified each standard DT edits for clarity and readability.1 Paul Warren Douglas DT and EAC suggested edits.7 Funding Suggested Gartner Group edits for clarity and consistency. 2010 consistency Jan 14. Dec 7. Refined 5.2 Paul Warren Douglas Endorsed by EAC Dec 30.2 Date Version Editor Change Summary Documenter Team Revised and refined Design Standards Added Service Planning Section Added Glossary and Reference entries Reviewed with Gartner Group Nov 10. Clarified SLA versus service contract Refining/synchronizing SOA-based Services definition with current documents. 2009 1.

Document Context 458This document is within the scope of state’s Service Oriented Architecture (SOA) initiative.gov/enterprise/enterprisearch/soa_initiative. 56 Page 14 of 14 57 . 471Drafting and Review Process: 472 About 42 individuals representing 18 agencies statewide helped draft or review the SOA 473 standards.aspx. Department of Health 466Initiative Architect: 467 Paul Warren Douglas. Department of Information Services 468Documenter Team: 469 Documenter Team consisted of 27 multi-agency subject matter experts representing 11 470 agencies. 2008 by the 460Information Services Board (ISB) and available at: 461http://dis. 462The SOA Initiative is designed to enable State Strategic IT Plan Goals. including the Documenter Team and Enterprise Architecture Committee. Department of Licensing 465 Frank Westrum. 54Washington Enterprise Architecture Program January 14.wa. The 459Target Architecture is a deliverable within the Initiative Charter adopted on July 10. 463Initiative Stewards: 464 Bill Kehoe.2 457 10. 2010 55Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.