Service Oriented Architecture (SOA) Planning Design Standards · Washington Enterprise Architecture Program January 14, 2010 Service Oriented Architecture (SOA) Planning Design Standards

Service Oriented Architecture (SOA) Planning Design Standards

ISB Standards Version 1.2

January 14, 2010

Primary Contributors

Paul Warren Douglas Department of Information Services

Initiative Architect

Bill Kehoe Department of Licensing

Initiative Steward

Frank Westrum Department of Health

Initiative Steward

Stephen Backholm Department of Social and Health Services

Jerry Britcher

Department of Social and Health Services

Gary Dubuque Department of Revenue

David Jennings

Department of Health

JoAnne Kendrick Department of Information Services

Daniel Mercer

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

RFP 18-04, Exhibit S, Page 1

Washington Enterprise Architecture Program January 14, 2010 Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2

Page 2 of 14

Table of Contents 1

1. Purpose ....................................................................................................................................... 3 2

1.1. Statutory Authority ................................................................................................................ 3 3

1.2. Scope .................................................................................................................................... 3 4

1.3. Related Policies and Standards ............................................................................................ 3 5

2. Introduction .................................................................................................................................. 3 6

2.1. Definitions ............................................................................................................................. 4 7

3. Service Principles ........................................................................................................................ 4 8

4. Service Conditions and Planning Design Standards ................................................................... 5 9

4.1. The service must be modular................................................................................................ 5 10

4.1.1. Service Modeling ............................................................................................................ 5 11

4.2. The modules must be distributable. ...................................................................................... 6 12

4.3. Module interfaces must be discoverable. ............................................................................. 6 13

4.3.1. Service Naming .............................................................................................................. 7 14

4.3.2. Service Description ........................................................................................................ 7 15

4.3.3. Service Metadata ........................................................................................................... 7 16

4.4. Service modules must be swappable. .................................................................................. 8 17

4.5. Service provider modules must be shareable. ...................................................................... 8 18

5. Service Features ......................................................................................................................... 8 19

5.1. Security ................................................................................................................................. 8 20

5.2. Scalability .............................................................................................................................. 9 21

5.3. Availability ............................................................................................................................. 9 22

5.4. Performance.......................................................................................................................... 9 23

5.5. Business Continuity .............................................................................................................. 9 24

5.6. Problem Management ......................................................................................................... 10 25

5.7. Funding ............................................................................................................................... 10 26

5.8. Change Management ......................................................................................................... 10 27

6. Service Planning ........................................................................................................................ 10 28

7. Glossary ..................................................................................................................................... 11 29

8. References ................................................................................................................................ 12 30

9. Document History ...................................................................................................................... 12 31

10. Document Context ................................................................................................................... 14 32

33



Page 3 of 14

Purpose 34

These standards provide the SOA principles, service conditions, standards, and application 35 design principles to design, deploy, and maintain Tier One SOA-based enterprise services. 36

This document contains primarily conceptual and logical level standards to help service providers 37 design Tier One ready SOA-based services and enable SOA governance. Physical level design 38 standards and guidelines are expected to evolve as more Tier One services are deployed and the 39 multi-agency governance teams collaborate. 40

These standards are not a detailed guide on how to develop SOA-based services; however, 41 technical standards, guidelines, and reference architectures are expected to evolve from the 42 multi-agency SOA Steering Committee and Technical Advisory Group as more services are 43 published with the assistance of the state’s Integration Competency Center. 44

Glossary entries and References are noted in BOLD or identified by (source material). 45 References are typically full source material citations. Full definitions are in the SOA Glossary.1 46

1.1. Statutory Authority 47

The provisions of RCW 43.105.041 detail the powers and duties of the Information Services 48 Board (ISB), including the authority to develop statewide or interagency information services and 49 technical policies, standards, and procedures. 50

1.2. Scope 51

These standards apply to state of Washington executive branch agencies, agencies headed by 52 separately elected officials, and institutions of higher education (referred to as “agencies” 53 throughout this document). Academic and research applications at institutions of higher education 54 are exempt. 55

1.3. Related Policies and Standards 56

• ISB SOA Governance Standards 57 • ISB Integration Architecture Standards 58 • ISB Security Standards 59

2. Introduction 60

This document provides principles and standards to help ensure SOA-based services are 61 designed to meet agency and state business needs and are architected for Tier One enterprise 62 use. It’s intended to be use by: 63

• Enterprise Architects 64 • Business Analysts 65 • Application Managers and Designers 66 • State’s multi-agency SOA Governance teams 67 • Service Providers and Consumers 68

69 70 71

1 Draft SOA Initiative Glossary document currently available on SOA Team Site.



Page 4 of 14

2.1. Definitions 72

• Service Oriented Architecture (SOA) - An architectural method or design style that results in 73 and supports shared2, reusable services. 74

• SOA-based Services – Are modular, swappable functions, separate from, yet connected to 75 an application via well defined interfaces to provide agility. Often referred to as ‘services’ 76 throughout this document they: 77

o Perform granular business functions such as “get customer address” or larger ones 78 such as ‘process payment.’ 79

o Are loosely coupled to a new or existing application. 80

o Have capability to perform the steps, tasks and activities of one or more business 81 processes. 82

o Can be combined to perform a set of functions - referred to as ‘service orchestration.’ 83

• State SOA Backplane - Shared, common infrastructure for lifecycle management such as a 84 services registry, policies, business analytics; routing/addressing, quality of service, 85 communication; Development Tools for security, management, and adapters. 86

• Service Providers and Consumers - In general, entities (people and organizations) offer 87 capabilities and act as service providers. Those with needs who make use of services are 88 referred to as service consumers. 89

3. Service Principles 90

The following information is provided to help the reader understand general principles for 91 planning and designing SOA-based services. Tier One SOA Planning and Design Standards are 92 provided in Section 4. 93

Service loose coupling – Reduces risk that a change in one application module will force a 94 change in another application module. 95

Loosely coupled services may be joined to create composite services, or disassembled into their 96 functional components, even if they use different system technologies 97

Service contract – Services adhere to a service contract as defined by one or more service 98 description documents and maintained via a central registry. 99

Starting from a service description (a contract), both a service consumer and a service provider 100 should have everything they need to consume or provide the service. 101

Service abstraction – Beyond what is described in the service contract, services hide their logic 102 from service consumers. 103

Service reusability – Services are not duplicated and logic is granularly divided in such a 104 manner as to promote service reuse. 105

Service composability – Collections of services are assembled to form composite services. 106 Composite services are composed of individual, unique, services that can be readily re-107 assembled, (or re-orchestrated), to assemble other composite services 108

Service componentization – Services must have well defined interfaces, must not share state, 109 and must communicate by messages. 110

Service autonomy – Services must have authoritative control over the logic they encapsulate. 111

2 While some overlap may exist for future SOA-based services that are shared, the state’s Shared Services Model is broader. See Governor’s Directive 09-02.



Page 5 of 14

Service optimization – Services must be constructed modularly, coded unambiguously, be 112 highly secure, and designed for high performance and scalability. 113

Service encapsulation – Separates the contractual interface from its implementation. The 114 internal mechanisms and data structures of a service are hidden behind a defined interface. This 115 allows for changes and improvements to the service without impacting service consumers. It also 116 allows the service to be replaced or superseded with another service that supports the same 117 interface. 118

Service provisioning – Each service shall have a provider responsible for provisioning the 119 service. Those with needs who make use of services are referred to as service consumers. 120

Service discoverability – Services must be easily identified by their purpose, and easily found 121 by other agencies. 122

Service identification – Services must be uniquely identified, secured and versioned. 123

Service metrics – Provides information for quality of service, performance, and reuse. Helps 124 agencies plan for and maintain services. 125

4. Service Conditions and Planning Design Standards 126

SOA-based application modules are constructed to meet service conditions. Planning design 127 standards are provided below in order for the service to meet the desired condition. 128

4.1. The service must be modular. 129

This enables flexibility to solve complex problems by assembling a set of small, simple 130 components that work together. 131

Rationale: Each service provider is largely autonomous, addressing one function or a set of 132 related functions. Modularity enables loose coupling and helps make components swappable 133 because a service provider can be replaced without causing unintended side effects. 134

• Services shall be designed to be loosely coupled. 135

• Service interfaces must be clearly defined and documented. 136

• Developers shall enter interface metadata or use tools to generate interface metadata that 137 specifies an explicit service contract so that another developer can find and use the service. 138

• Everything needed by the service to provide its functionality must be passed to it when it is 139 invoked (service boundary explicitness.) All access to a service must be via its exposed 140 interface. No hidden assumptions must be necessary to invoke the service. 141

• Business analysts and architects shall collaborate to ensure business processes are unique, 142 well defined, and documented, and that service candidates are capable of meeting business 143 needs and changes. 144

4.1.1. Service Modeling 145

• Each service must exist within the context of at least one business process; a service plays a 146 specific role in accomplishing a business process that achieves demonstrable business 147 value. 148

• The service provider must maintain models for business processes, as well as those for 149 structure and behavior to indicate the roles and functions of each service (See ISB 150 Integration Architecture Service Modeling Standards.) 151



Page 6 of 14

• The description of each service shall include the business process model(s) for which the 152 service was designed. This description may be maintained manually and shall be available 153 on the state’s service repository for Tier One services. 154

• The description of each service shall include a contextual summary that establishes the name 155 of the service and a brief (single paragraph) description of the real world effect of using the 156 service. 157

4.2. The modules must be distributable. 158

Service components are able to run on disparate computers and communicate with each 159 other by sending messages over a network at runtime. 160

Rationale: Services are typically spread out over multiple physical locations. A service may be 161 used by multiple consumers. SOA applications are inherently distributed applications. 162

• The service provider shall be responsible for creating a Service Contract for each service 163 and negotiating with each service consumer. Service contracts shall be posted on the state 164 ICC SOA Services Registry to communicate information about the service. 165

• Service providers and consumers shall follow the ISB Integration Architecture Standards at: 166 http://isb.wa.gov/policies/eaprogram.aspx for service integration and messaging. Service 167 interfaces shared between two or more agencies in the state enterprise shall conform to one 168 or more state’s service interaction profiles. Service consumers that interact with an interface 169 should likewise conform to that interface’s profile. 170

4.3. Module interfaces must be discoverable. 171

Services must be clearly defined and documented. Software developers write or 172 generate interface metadata that specifies an explicit service contract, so other 173 developers can find and use the service. 174

Rationale: Developers write or generate technical interface descriptions (interface metadata) so 175 that another developer can find and use the service. 176

• Service providers shall use the ISB Service Repository Solution Set Standards at: 177 http://isb.wa.gov/policies/eaprogram.aspx that provide functional and supporting features for 178 the state ICC SOA Services Registry. 179

• Tier One services shall be published on the state ICC service registry. The state’s ICC 180 service registry is an online catalog that contains the names and information about each 181 service, including associated attributes like metadata. 182

• Once designated as Tier One, services shall be registered in the state ICC SOA Services 183 Registry in order to enable discovery, minimize redundancy of duplicate services, and 184 maximize reuse. 185

• Software interface definitions shall be maintained in the state’s ICC SOA Services Registry 186 so they are available to application developers. 187

• The Service Contract indicates when a Service Level Agreement is required; the service 188 has security related requirements; and lists other key service attributes. 189

• Agency Providers with Tier Two services that are likely candidates for adoption by other 190 agencies shall review these standards before registering services in the state ICC Service 191 Registry. Agencies are encouraged to publish services for reuse. In order to be designated as 192 Tier One, these services shall meet the SOA Planning Design Standards and follow the SOA 193 Governance Standards which establish requirements for qualifying Tier Two candidates. 194


http://isb.wa.gov/policies/eaprogram.aspx

http://isb.wa.gov/policies/eaprogram.aspx


Page 7 of 14

4.3.1. Service Naming 195

• Services must be unambiguously named based upon their purpose and to best represent the 196 task in what is known as the real world effect. Services usually map to a business task. 197

• The name of the service must encapsulate the essential aspects of the real world effect of the 198 service; that is, the name of the service must represent what the service accomplishes (in 199 business terms), rather than how the service works. 200

o For example “verify zip code, verify correct address” are representations of services 201 based or named after the real world effect and are easily understood by business 202 and technical staff. 203

• The name shall not indicate the underlying information system that implements the service, 204 nor the agency or organization that provisions the service, nor any technical details about 205 how the implementation works. 206

• Notes: 207

o Service naming and other details are included in the Service Contract. 208

o Additional service naming conventions may be developed by the multi-agency 209 governance teams (see SOA Governance Standards.) 210

4.3.2. Service Description 211

• Services shall contain a complete description of the real world effect of the service (that is, 212 what the service accomplishes.) 213

• Services shall contain a list and brief (single paragraph) description of each of the actions 214 that can be performed on the service. 215

• Services shall contain a list and brief (single paragraph) description of the principal 216 information and entities involved in interaction with the service via its actions. 217

• Services shall contain a list of the principal metadata categories and values for the service (a 218 future version of these standards or related guidelines may specify a standard set of 219 metadata categories for services, based on experience implementing the integration 220 architecture.) 221

• All aspects of the description must be free of any implementation details or dependencies. 222 The description shall not refer to particular databases or systems in the description of the real 223 world effect; rather, the description must describe the business effects of the service. 224

4.3.3. Service Metadata 225

• Each service interface must have a complete definition that captures its semantic meaning. 226 Each attribute must identify its data type and other parameters that specify the range of its 227 values. 228

• Each service interface must have a set of metadata categories and values, as appropriate, to 229 define the context of the element. 230

• The metadata for a service must include the service provider that owns and governs the 231 structure of the service and the current version of the service and messages. 232

• The name of each service interface must encapsulate the meaning of the service in a way 233 free of any reference to implementation detail. 234

• Each exposed class and service interface must include an identifier in service’s registered 235 metadata. 236



Page 8 of 14

4.4. Service modules must be swappable. 237

The service module can be replaced by another module that offers the same service 238 without disrupting modules that used the previous module. This is accomplished by 239 separating the interface design from the module that implements the service. 240

Rationale: This separates the implementation (the service provider module's code and data) from 241 the interface metadata. A copy of the interface metadata is accessible to other developers 242 separately from the code that implements the provider component. 243

This makes it possible for the consumer developer to use the service without having a copy of the 244 provider software module. It also enables multiple development teams to create interchangeable 245 provider modules. 246

The consumer and the provider can use disparate programming languages, application servers 247 and operating systems. 248

• Services that make functionality or information available to other services shall do so through 249 separate well defined interfaces. 250

• Services shall be designed so that modules may be replaced without affecting the 251 consumers. 252

• Services that use functionality or information provided by other systems or services shall 253 access that functionality or information in a way that minimizes dependencies on those other 254 systems’ implementation details. 255

• Services shall avoid service nesting, where possible, to minimize service dependencies and 256 reduce risk. 257

4.5. Service provider modules must be shareable. 258

Services must be designed and deployed in a way that enables them to be invoked 259 successively by disparate applications in support of diverse business activities. 260

Rationale: Multiple agencies, departments or separate agencies and entities can use same 261 service. This service condition ensures each provider module in an SOA application can be 262 invoked successively by disparate consumers. 263

Developers can write different consumer application modules that use the same service as long 264 as they conform to the conditions specified in the interface contract. 265

• The service shall be posted on the state ICC registry once designated as Tier One. The 266 service provider is responsible to ensure the service follows the SOA governance standards 267 process. 268

• The portfolio of Tier One services shall be made available on the state’s ICC services 269 registry. Service providers are responsible to ensure changes follow the SOA Governance 270 Standards and Consumers are made aware of all changes. 271

5. Service Features 272

The following sections describe service design features, which are similar to application design. 273 Services shall be tested to ensure they meet the following design features: 274

5.1. Security 275

• Each service shall be designed to ensure provider and consumer security. 276

• Services shall have the ability to be audited (also see Service Metrics.) 277



Page 9 of 14

• Vulnerability testing shall occur before services are deployed. 278

• Services that interface with legacy systems shall also ensure the systems are not exposed to 279 vulnerable security threats or breaches. 280

5.2. Scalability 281

• Service providers shall architect the service so it is scalable to meet current and future 282 consumer needs. 283

• The provider shall identify the service capability, capacity, expected number of users, and 284 how many transactions per minute. 285

• Services shall be designed to handle the number of users per each Service Level 286 Agreement and architected to be scalable to several times the number identified in its 287 current configuration. 288

• The service component architecture shall be highly available, and fully redundant to allow for 289 the addition of resources without system downtime. The service must also enable scalability 290 of backend applications through load balancing. 291

5.3. Availability 292

Service provider shall strive to make the service(s) available per agreed upon Service Level 293 Agreement (SLA). Scheduled maintenance periods shall be identified in each SLA and service 294 contract. Service maintenance is performed when necessary (hardware and software upgrades, 295 software patches, faulty hardware replacement, etc.) 296

• The service provider shall coordinate with agency consumers in advance of scheduled 297 maintenance that will affect agencies or users in accordance with the Service Level 298 Agreement. 299

• The service provider’s technical and operational support staff shall monitor availability and 300 performance of the service. 301

• Service monitoring and automated alerting and logging shall be implemented when possible 302 to monitor each service as well as report state and utilization. 303

5.4. Performance 304

• Service performance must be monitored and reviewed to plan for the addition of resources 305 before performance is significantly impacted. 306

• Agency consumers, including backend applications must be monitored for increased server 307 utilization. 308

• Service providers and consumers shall ensure adequate testing at initial deployment and 309 every time a change is made in the system. 310

5.5. Business Continuity 311

• The service shall be implemented as fault tolerant, with appropriate hardware, and software. 312

• The service provider shall perform full-system backups for onsite and off-site storage on a 313 scheduled basis. 314

• Business continuity information shall also be included within the service contract, as well as 315 services that require an SLA between the provider and consumers. 316



Page 10 of 14

5.6. Problem Management 317

• The service provider shall be responsible for problem management and shall ensure minimal 318 impact to service consumers. 319

• Provides automated triggers or scheduled problem management through use of monitoring 320 tools. 321

• The service provider shall notify agencies of all events that have or may have an adverse 322 affect on service delivery to customers. 323

• The service provider shall notify agency consumers of all failed processes. 324

• The service provider shall provide seamless integration of processes that ensure agency 325 consumer problem resolution satisfaction by tracking, alerting, escalating and solving 326 problems. 327

• The service provider shall provide help assistance for consumers via an online knowledge 328 base or Customer Service Representatives shall be available to assist by telephone. 329

5.7. Funding 330

Funding models are an important part of ensuring longevity and stability of Tier One services. 331

• The business owner/service provider is responsible to ensure funding models associated with 332 building and maintaining Tier One SOA services are identified. 333

• Service providers and consumers shall know how much the business unit that operates an 334 SOA service will charge another business unit that has an application that consumes the 335 SOA service. 336

• Funding models shall be identified in service contracts and included in Service Level 337 Agreements. 338

5.8. Change Management 339

• All changes to the service must follow the SOA Governance Standards. Changes shall be 340 managed to promote or provide stability and minimize the impact of the changes to the 341 agencies. 342

• Changes shall be planned and communicated with agency consumers and the SOA 343 governance teams for statewide changes. 344

6. Service Planning 345

• Tier One services shall have a clear business owner and service provider. 346

• Agencies shall check the state’s ICC Doman Service Registry to share or reuse existing SOA 347 services before building or buying new services. 348

• SOA-based services must support interoperability and portability and as much as reasonably 349 possible be independent of any specific vendor’s proprietary product. 350

• Where applicable, Request for Proposals (RFP) shall require proposed vendors to identify 351 and describe proposed solution’s SOA readiness and SOA architecture. 352

• SOA-based acquisitions shall include language for vendor to identify its architecture and 353 potential to loosely couple with the state’s shared infrastructure and services where 354 applicable. 355

• Nesting of services, (the use of recursive or sub-layered, dependent services), shall be 356 discouraged in order to minimize complexity and increase maintainability. 357



Page 11 of 14

7. Glossary 358

NESTING Practice of making successive service calls to other 359 functions or dependent services. Nested SOA-based 360 services is discouraged due to complexity, 361 maintainability, availability, and performance. 362

SERVICE CONTRACT Contains a list of the functional and non-functional 363 service attributes, such as: header with Name, Version, 364 Owner, Responsibility Assignment, Service Type, what 365 the service accomplishes, Operations, and Invocation, 366 and Non-Functional such as security, Quality of services, 367 Semantics, SLA, and Process. 368

STATE/STATELESS Describes the behavior of the service including its 369 specific set of instructions. Services should minimize the 370 amount of state information they manage and hold long 371 the information is held. 372

REAL WORLD EFFECT The actual, desired result of the service (e.g. ‘Get 373 customer information.’) SOA-based services are 374 designed to meet business needs. A service consumer 375 is a participant that interacts with a service in order to 376 realize the real world effect produced by a capability to 377 address a consumer need. 378

SERVICE CONDITIONS Service Oriented architecture (SOA) is a style of 379 application architecture. According to Gartner, an 380 application is SOA-based service when it meets these 381 five conditions: 382

1. It is modular. 383

2. The modules are distributable. 384

3. Software developers write or generate interface 385 metadata that specifies an explicit contract so that 386 another developer can find and use the service. 387

4. The interface of a service is separate from the 388 implementation (code and data) of the service provider. 389

5. The service is shareable - that is, designed and 390 deployed in a manner that enables them to be invoked 391 successively by disparate consumers. 392

393

SERVICE METRICS Monitoring services provides audit, logging, charge-394 back, financial reporting for investments, design, 395 deployment, maintenance planning, and other purposes 396 via metrics such as: 397

Quality of Service (QoS) and Performance 398

• Number of requests 399 • Number of failed requests 400 • Number of successful requests 401 • Service time 402 • Maximum response time 403 • Last response time 404



Page 12 of 14

Reuse Metrics 405

• Number of services deployed 406 • Number of consumer applications deployed 407 • Number of services and number of consumers 408 • Number of services shared by applications 409

TIER ONE Statewide Enterprise Architecture business processes, 410 data, or technologies that are common among the 411 majority or to all state agencies. 412

Tier Definitions: 413

Tier One: Across/among agency systems 414 Tier Two: Within an agency 415 Tier Three: Sub-agency level 416

These three different tiers depend on the degree 417 to which they should be common, and what other entities 418 with which they should be common. A description of the 419 state’s Tiers is available at: 420 http://isb.wa.gov/committees/enterprise/concepts/ 421

Also see ISB EA Over-Arching Principles, including 422 Commonality at: 423 http://isb.wa.gov/committees/enterprise/architecture/over424 archingprinciples.doc 425

8. References 426

GARTNER SOA Overview and Guide to SOA Research, April 2009 427

INTEGRATION ARCHITECTURE ISB Integration Architecture Standards and Solution Sets 428 at: http://isb.wa.gov/policies/eaprogram.aspx. 429

OASIS Reference Architecture Foundation for Service Oriented 430 Architecture 1.0, OASIS Committee Draft 2 (Authoritative 431 PDF), Oct. 14, 2009 432

OPEN GROUP SOA Governance framework, Technical Standard, The 433 Open Group, Aug 2009. 434

435

9. Document History 436

Date Version Editor Change Summary

August 31, 2009 1.0 Paul Warren Douglas, DIS

Noel Morgan, DOT

Initial Draft

September to Oct 12, 2009

1.0 Paul Warren Douglas, DIS

Noel Morgan, DOT

Revised Service Principles

Combined Service Conditions and Design Standards


http://isb.wa.gov/committees/enterprise/concepts/


Page 13 of 14

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, 2009 1.1 Paul Warren Douglas

Documenter Team

DT and EAC suggested edits. Removed physical design style references.

Clarified each standard

DT edits for clarity and readability.

Clarified SLA versus service contract

Refining/synchronizing SOA-based Services definition with current documents.

Refined 5.7 Funding

Suggested Gartner Group edits for clarity and consistency.

Dec 7, 2009 1.2 Paul Warren Douglas

DT Refinements

Added Service Metrics concepts and Glossary entry

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, 2009 1.2 Paul Warren Douglas Endorsed by EAC

Dec 30, 2009 to Jan 7, 2010

1.2 Paul Warren Douglas Stakeholder revisions for clarity and consistency

Jan 14, 2010 1.2 Paul Douglas Adopted by Information Services Board



Page 14 of 14

10. Document Context 437

This document is within the scope of state’s Service Oriented Architecture (SOA) initiative. The 438 Target Architecture is a deliverable within the Initiative Charter adopted on July 10, 2008 by the 439 Information Services Board (ISB) and available at: 440 http://dis.wa.gov/enterprise/enterprisearch/soa_initiative.aspx. 441

The SOA Initiative is designed to enable State Strategic IT Plan Goals. 442

Initiative Stewards: 443

• Bill Kehoe, Department of Licensing 444

• Frank Westrum, Department of Health 445

Initiative Architect: 446

• Paul Warren Douglas, Department of Information Services 447

Documenter Team: 448

• Documenter Team consisted of 27 multi-agency subject matter experts representing 11 449 agencies. 450

Drafting and Review Process: 451

• About 42 individuals representing 18 agencies statewide helped draft or review the SOA 452 standards, including the Documenter Team and Enterprise Architecture Committee. 453


http://dis.wa.gov/enterprise/enterprisearch/soa_initiative.aspx

Documents

Service Oriented Architecture (SOA) Planning Design Standards · Washington Enterprise Architecture Program January 14, 2010 Service Oriented Architecture (SOA) Planning Design Standards