SOA Planning Design Standards (doc)

  • 708 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
708
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
74
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 1 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 Backholm 11 Department of Social and Health Services 12 Jerry Britcher 13 Department of Social and Health Services Gary Dubuque 14 Service Oriented Architecture (SOA) Department of Revenue 15 Planning Design Standards David Jennings16 Department of Health 17 ISB Standards JoAnne Kendrick 18 Department of Information Services Version 1.2 19 Daniel Mercer 20 Labor and Industries 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
  • 2. 3Washington Enterprise Architecture Program January 14, 2010 4Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2 21 Table of Contents 22 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.............................................................................................................................4 283. Service Principles.......................................................................................................................4 294. Service Conditions and Planning Design Standards...................................................................5 30 4.1. The service must be modular. .............................................................................................5 31 4.1.1. Service Modeling...........................................................................................................5 32 4.2. The modules must be distributable. .....................................................................................6 33 4.3. Module interfaces must be discoverable. ............................................................................6 34 4.3.1. Service Naming .............................................................................................................7 35 4.3.2. Service Description........................................................................................................7 36 4.3.3. Service Metadata...........................................................................................................7 37 4.4. Service modules must be swappable. .................................................................................8 38 4.5. Service provider modules must be shareable. .....................................................................8 395. Service Features.........................................................................................................................8 40 5.1. Security................................................................................................................................8 41 5.2. Scalability.............................................................................................................................9 42 5.3. Availability............................................................................................................................9 43 5.4. Performance.........................................................................................................................9 44 5.5. Business Continuity..............................................................................................................9 45 5.6. Problem Management........................................................................................................10 46 5.7. Funding..............................................................................................................................10 47 5.8. Change Management.........................................................................................................10 486. Service Planning ......................................................................................................................10 497. Glossary....................................................................................................................................11 508. References...............................................................................................................................12 519. Document History.....................................................................................................................12 5210. Document Context..................................................................................................................13 5 Page 2 of 14 6
  • 3. 7Washington Enterprise Architecture Program January 14, 2010 8Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2 Purpose 53 54These standards provide the SOA principles, service conditions, standards, and application 55design principles to design, deploy, and maintain Tier One SOA-based enterprise services. 56This document contains primarily conceptual and logical level standards to help service providers 57design Tier One ready SOA-based services and enable SOA governance. Physical level design 58standards and guidelines are expected to evolve as more Tier One services are deployed and the 59multi-agency governance teams collaborate. 60These standards are not a detailed guide on how to develop SOA-based services; however, 61technical standards, guidelines, and reference architectures are expected to evolve from the 62multi-agency SOA Steering Committee and Technical Advisory Group as more services are 63published with the assistance of the state’s Integration Competency Center. 64Glossary entries and References are noted in BOLD or identified by (source material). 65References are typically full source material citations. Full definitions are in the SOA Glossary.1 661.1.Statutory Authority 67The provisions of RCW 43.105.041 detail the powers and duties of the Information Services 68Board (ISB), including the authority to develop statewide or interagency information services and 69technical policies, standards, and procedures. 701.2.Scope 71These standards apply to state of Washington executive branch agencies, agencies headed by 72separately elected officials, and institutions of higher education (referred to as “agencies” 73throughout this document). Academic and research applications at institutions of higher education 74are exempt. 751.3.Related Policies and Standards 76 • ISB SOA Governance Standards 77 • ISB Integration Architecture Standards 78 • ISB Security Standards 79 2.Introduction 80This document provides principles and standards to help ensure SOA-based services are 81designed to meet agency and state business needs and are architected for Tier One enterprise 82use. It’s intended to be use by: 83 • Enterprise Architects 84 • Business Analysts 85 • Application Managers and Designers 86 • State’s multi-agency SOA Governance teams 87 • Service Providers and Consumers 88 89 90 91 Draft SOA Initiative Glossary document currently available on SOA Team Site. 10 Page 3 of 14 11
  • 4. 12Washington Enterprise Architecture Program January 14, 2010 13Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2 912.1.Definitions 92• Service Oriented Architecture (SOA) - An architectural method or design style that results in 93 and supports shared2, reusable services. 94• SOA-based Services – Are modular, swappable functions, separate from, yet connected to 95 an application via well defined interfaces to provide agility. Often referred to as ‘services’ 96 throughout this document they: 97 o Perform granular business functions such as “get customer address” or larger ones 98 such as ‘process payment.’ 99 o Are loosely coupled to a new or existing application. 100 o Have capability to perform the steps, tasks and activities of one or more business 101 processes. 102 o Can be combined to perform a set of functions - referred to as ‘service orchestration.’ 103• State SOA Backplane - Shared, common infrastructure for lifecycle management such as a 104 services registry, policies, business analytics; routing/addressing, quality of service, 105 communication; Development Tools for security, management, and adapters. 106• Service Providers and Consumers - In general, entities (people and organizations) offer 107 capabilities and act as service providers. Those with needs who make use of services are 108 referred to as service consumers. 109 3.Service Principles 110The following information is provided to help the reader understand general principles for 111planning and designing SOA-based services. Tier One SOA Planning and Design Standards are 112provided in Section 4. 113Service loose coupling – Reduces risk that a change in one application module will force a 114change in another application module. 115Loosely coupled services may be joined to create composite services, or disassembled into their 116functional components, even if they use different system technologies 117Service contract – Services adhere to a service contract as defined by one or more service 118description documents and maintained via a central registry. 119Starting from a service description (a contract), both a service consumer and a service provider 120should have everything they need to consume or provide the service. 121Service abstraction – Beyond what is described in the service contract, services hide their logic 122from service consumers. 123Service reusability – Services are not duplicated and logic is granularly divided in such a 124manner as to promote service reuse. 125Service composability – Collections of services are assembled to form composite services. 126Composite services are composed of individual, unique, services that can be readily re- 127assembled, (or re-orchestrated), to assemble other composite services 128Service componentization – Services must have well defined interfaces, must not share state, 129and must communicate by messages. 130Service autonomy – Services must have authoritative control over the logic they encapsulate. 142 While some overlap may exist for future SOA-based services that are shared, the state’s Shared 15Services Model is broader. See Governor’s Directive 09-02. 16 Page 4 of 14 17
  • 5. 18Washington Enterprise Architecture Program January 14, 2010 19Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2 131Service optimization – Services must be constructed modularly, coded unambiguously, be 132highly secure, and designed for high performance and scalability. 133Service encapsulation – Separates the contractual interface from its implementation. The 134internal mechanisms and data structures of a service are hidden behind a defined interface. This 135allows for changes and improvements to the service without impacting service consumers. It also 136allows the service to be replaced or superseded with another service that supports the same 137interface. 138Service provisioning – Each service shall have a provider responsible for provisioning the 139service. Those with needs who make use of services are referred to as service consumers. 140Service discoverability – Services must be easily identified by their purpose, and easily found 141by other agencies. 142Service identification – Services must be uniquely identified, secured and versioned. 143Service metrics – Provides information for quality of service, performance, and reuse. Helps 144agencies plan for and maintain services. 145 4.Service Conditions and Planning Design Standards 146SOA-based application modules are constructed to meet service conditions. Planning design 147standards are provided below in order for the service to meet the desired condition. 1484.1.The service must be modular. 149This enables flexibility to solve complex problems by assembling a set of small, simple 150components that work together. 151Rationale: Each service provider is largely autonomous, addressing one function or a set of 152related functions. Modularity enables loose coupling and helps make components swappable 153because a service provider can be replaced without causing unintended side effects. 154• Services shall be designed to be loosely coupled. 155• Service interfaces must be clearly defined and documented. 156• Developers shall enter interface metadata or use tools to generate interface metadata that 157 specifies an explicit service contract so that another developer can find and use the service. 158• Everything needed by the service to provide its functionality must be passed to it when it is 159 invoked (service boundary explicitness.) All access to a service must be via its exposed 160 interface. No hidden assumptions must be necessary to invoke the service. 161• Business analysts and architects shall collaborate to ensure business processes are unique, 162 well defined, and documented, and that service candidates are capable of meeting business 163 needs and changes. 1644.1.1.Service Modeling 165• Each service must exist within the context of at least one business process; a service plays a 166 specific role in accomplishing a business process that achieves demonstrable business 167 value. 168• The service provider must maintain models for business processes, as well as those for 169 structure and behavior to indicate the roles and functions of each service (See ISB Integration 170 Architecture Service Modeling Standards.) 20 Page 5 of 14 21
  • 6. 22Washington Enterprise Architecture Program January 14, 2010 23Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2 171• The description of each service shall include the business process model(s) for which the 172 service was designed. This description may be maintained manually and shall be available 173 on the state’s service repository for Tier One services. 174• The description of each service shall include a contextual summary that establishes the name 175 of the service and a brief (single paragraph) description of the real world effect of using the 176 service. 1774.2.The modules must be distributable. 178Service components are able to run on disparate computers and communicate with 179each other by sending messages over a network at runtime. 180Rationale: Services are typically spread out over multiple physical locations. A service may be 181used by multiple consumers. SOA applications are inherently distributed applications. 182• The service provider shall be responsible for creating a Service Contract for each service 183 and negotiating with each service consumer. Service contracts shall be posted on the state 184 ICC SOA Services Registry to communicate information about the service. 185• Service providers and consumers shall follow the ISB Integration Architecture Standards at: 186 http://isb.wa.gov/policies/eaprogram.aspx for service integration and messaging. Service 187 interfaces shared between two or more agencies in the state enterprise shall conform to one 188 or more state’s service interaction profiles. Service consumers that interact with an interface 189 should likewise conform to that interface’s profile. 1904.3.Module interfaces must be discoverable. 191Servicesmust be clearly defined and documented. Software developers write or 192generate interface metadata that specifies an explicit service contract, so other 193developers can find and use the service. 194Rationale: Developers write or generate technical interface descriptions (interface metadata) so 195that another developer can find and use the service. 196• Service providers shall use the ISB Service Repository Solution Set Standards at: 197 http://isb.wa.gov/policies/eaprogram.aspx that provide functional and supporting features for 198 the state ICC SOA Services Registry. 199• Tier One services shall be published on the state ICC service registry. The state’s ICC 200 service registry is an online catalog that contains the names and information about each 201 service, including associated attributes like metadata. 202• Once designated as Tier One, services shall be registered in the state ICC SOA Services 203 Registry in order to enable discovery, minimize redundancy of duplicate services, and 204 maximize reuse. 205• Software interface definitions shall be maintained in the state’s ICC SOA Services Registry so 206 they are available to application developers. 207• The Service Contract indicates when a Service Level Agreement is required; the service 208 has security related requirements; and lists other key service attributes. 209• Agency Providers with Tier Two services that are likely candidates for adoption by other 210 agencies shall review these standards before registering services in the state ICC Service 211 Registry. Agencies are encouraged to publish services for reuse. In order to be designated as 212 Tier One, these services shall meet the SOA Planning Design Standards and follow the SOA 213 Governance Standards which establish requirements for qualifying Tier Two candidates. 24 Page 6 of 14 25
  • 7. 26Washington Enterprise Architecture Program January 14, 2010 27Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2 2144.3.1.Service Naming 215• Services must be unambiguously named based upon their purpose and to best represent the 216 task in what is known as the real world effect. Services usually map to a business task. 217• The name of the service must encapsulate the essential aspects of the real world effect of the 218 service; that is, the name of the service must represent what the service accomplishes (in 219 business terms), rather than how the service works. 220 o For example “verify zip code, verify correct address” are representations of services 221 based or named after the real world effect and are easily understood by business and 222 technical staff. 223• The name shall not indicate the underlying information system that implements the service, 224 nor the agency or organization that provisions the service, nor any technical details about 225 how the implementation works. 226• Notes: 227 o Service naming and other details are included in the Service Contract. 228 o Additional service naming conventions may be developed by the multi-agency 229 governance teams (see SOA Governance Standards.) 2304.3.2.Service Description 231• Services shall contain a complete description of the real world effect of the service (that is, 232 what the service accomplishes.) 233• Services shall contain a list and brief (single paragraph) description of each of the actions that 234 can be performed on the service. 235• Services shall contain a list and brief (single paragraph) description of the principal 236 information and entities involved in interaction with the service via its actions. 237• Services shall contain a list of the principal metadata categories and values for the service (a 238 future version of these standards or related guidelines may specify a standard set of 239 metadata categories for services, based on experience implementing the integration 240 architecture.) 241• All aspects of the description must be free of any implementation details or dependencies. 242 The description shall not refer to particular databases or systems in the description of the real 243 world effect; rather, the description must describe the business effects of the service. 2444.3.3.Service Metadata 245• Each service interface must have a complete definition that captures its semantic meaning. 246 Each attribute must identify its data type and other parameters that specify the range of its 247 values. 248• Each service interface must have a set of metadata categories and values, as appropriate, to 249 define the context of the element. 250• The metadata for a service must include the service provider that owns and governs the 251 structure of the service and the current version of the service and messages. 252• The name of each service interface must encapsulate the meaning of the service in a way 253 free of any reference to implementation detail. 254• Each exposed class and service interface must include an identifier in service’s registered 255 metadata. 28 Page 7 of 14 29
  • 8. 30Washington Enterprise Architecture Program January 14, 2010 31Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2 2564.4.Service modules must be swappable. 257The service module can be replaced by another module that offers the same service 258withoutdisrupting modules that used the previous module. This is accomplished by 259separating the interface design from the module that implements the service. 260Rationale: This separates the implementation (the service provider module's code and data) from 261the interface metadata. A copy of the interface metadata is accessible to other developers 262separately from the code that implements the provider component. 263This makes it possible for the consumer developer to use the service without having a copy of the 264provider software module. It also enables multiple development teams to create interchangeable 265provider modules. 266The consumer and the provider can use disparate programming languages, application servers 267and operating systems. 268• Services that make functionality or information available to other services shall do so through 269 separate well defined interfaces. 270• Services shall be designed so that modules may be replaced without affecting the 271 consumers. 272• Services that use functionality or information provided by other systems or services shall 273 access that functionality or information in a way that minimizes dependencies on those other 274 systems’ implementation details. 275• Services shall avoid service nesting, where possible, to minimize service dependencies and 276 reduce risk. 2774.5.Service provider modules must be shareable. 278Services must be designed and deployed in a way that enables them to be invoked 279successively by disparate applications in support of diverse business activities. 280Rationale: Multiple agencies, departments or separate agencies and entities can use same 281service. This service condition ensures each provider module in an SOA application can be 282invoked successively by disparate consumers. 283Developers can write different consumer application modules that use the same service as long 284as they conform to the conditions specified in the interface contract. 285• The service shall be posted on the state ICC registry once designated as Tier One. The 286 service provider is responsible to ensure the service follows the SOA governance standards 287 process. 288• The portfolio of Tier One services shall be made available on the state’s ICC services 289 registry. Service providers are responsible to ensure changes follow the SOA Governance 290 Standards and Consumers are made aware of all changes. 291 5.Service Features 292The following sections describe service design features, which are similar to application design. 293Services shall be tested to ensure they meet the following design features: 2945.1.Security 295 • Each service shall be designed to ensure provider and consumer security. 296 • Services shall have the ability to be audited (also see Service Metrics.) 32 Page 8 of 14 33
  • 9. 34Washington Enterprise Architecture Program January 14, 2010 35Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2 297 • Vulnerability testing shall occur before services are deployed. 298 • Services that interface with legacy systems shall also ensure the systems are not exposed to 299 vulnerable security threats or breaches. 3005.2.Scalability 301 • Service providers shall architect the service so it is scalable to meet current and future 302 consumer needs. 303 • The provider shall identify the service capability, capacity, expected number of users, and 304 how many transactions per minute. 305 • Services shall be designed to handle the number of users per each Service Level 306 Agreement and architected to be scalable to several times the number identified in its 307 current configuration. 308 • The service component architecture shall be highly available, and fully redundant to allow for 309 the addition of resources without system downtime. The service must also enable scalability 310 of backend applications through load balancing. 3115.3.Availability 312Service provider shall strive to make the service(s) available per agreed upon Service Level 313Agreement (SLA). Scheduled maintenance periods shall be identified in each SLA and service 314contract. Service maintenance is performed when necessary (hardware and software upgrades, 315software patches, faulty hardware replacement, etc.) 316 • The service provider shall coordinate with agency consumers in advance of scheduled 317 maintenance that will affect agencies or users in accordance with the Service Level 318 Agreement. 319 • The service provider’s technical and operational support staff shall monitor availability and 320 performance of the service. 321 • Service monitoring and automated alerting and logging shall be implemented when possible 322 to monitor each service as well as report state and utilization. 3235.4.Performance 324 • Service performance must be monitored and reviewed to plan for the addition of resources 325 before performance is significantly impacted. 326 • Agency consumers, including backend applications must be monitored for increased server 327 utilization. 328 • Service providers and consumers shall ensure adequate testing at initial deployment and 329 every time a change is made in the system. 3305.5.Business Continuity 331 • The service shall be implemented as fault tolerant, with appropriate hardware, and software. 332 • The service provider shall perform full-system backups for onsite and off-site storage on a 333 scheduled basis. 334 • Business continuity information shall also be included within the service contract, as well as 335 services that require an SLA between the provider and consumers. 36 Page 9 of 14 37
  • 10. 38Washington Enterprise Architecture Program January 14, 2010 39Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2 3365.6.Problem Management 337• The service provider shall be responsible for problem management and shall ensure minimal 338 impact to service consumers. 339• Provides automated triggers or scheduled problem management through use of monitoring 340 tools. 341• The service provider shall notify agencies of all events that have or may have an adverse 342 affect on service delivery to customers. 343• The service provider shall notify agency consumers of all failed processes. 344• The service provider shall provide seamless integration of processes that ensure agency 345 consumer problem resolution satisfaction by tracking, alerting, escalating and solving 346 problems. 347• The service provider shall provide help assistance for consumers via an online knowledge 348 base or Customer Service Representatives shall be available to assist by telephone. 3495.7.Funding 350Funding models are an important part of ensuring longevity and stability of Tier One services. 351• The business owner/service provider is responsible to ensure funding models associated with 352 building and maintaining Tier One SOA services are identified. 353• Service providers and consumers shall know how much the business unit that operates an 354 SOA service will charge another business unit that has an application that consumes the 355 SOA service. 356• Funding models shall be identified in service contracts and included in Service Level 357 Agreements. 3585.8.Change Management 359 • All changes to the service must follow the SOA Governance Standards. Changes shall be 360 managed to promote or provide stability and minimize the impact of the changes to the 361 agencies. 362 • Changes shall be planned and communicated with agency consumers and the SOA 363 governance teams for statewide changes. 364 6.Service Planning 365• Tier One services shall have a clear business owner and service provider. 366• Agencies shall check the state’s ICC Doman Service Registry to share or reuse existing SOA 367 services before building or buying new services. 368• SOA-based services must support interoperability and portability and as much as reasonably 369 possible be independent of any specific vendor’s proprietary product. 370• Where applicable, Request for Proposals (RFP) shall require proposed vendors to identify 371 and describe proposed solution’s SOA readiness and SOA architecture. 372• SOA-based acquisitions shall include language for vendor to identify its architecture and 373 potential to loosely couple with the state’s shared infrastructure and services where 374 applicable. 375• Nesting of services, (the use of recursive or sub-layered, dependent services), shall be 376 discouraged in order to minimize complexity and increase maintainability. 40 Page 10 of 14 41
  • 11. 42Washington Enterprise Architecture Program January 14, 2010 43Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2 377 7.Glossary 378NESTING Practice of making successive service calls to other 379 functions or dependent services. Nested SOA-based 380 services is discouraged due to complexity, 381 maintainability, availability, and performance. 382SERVICE CONTRACT Contains a list of the functional and non-functional 383 service attributes, such as: header with Name, Version, 384 Owner, Responsibility Assignment, Service Type, what 385 the service accomplishes, Operations, and Invocation, 386 and Non-Functional such as security, Quality of services, 387 Semantics, SLA, and Process. 388STATE/STATELESS Describes the behavior of the service including its 389 specific set of instructions. Services should minimize the 390 amount of state information they manage and hold long 391 the information is held. 392REAL WORLD EFFECT The actual, desired result of the service (e.g. ‘Get 393 customer information.’) SOA-based services are 394 designed to meet business needs. A service consumer 395 is a participant that interacts with a service in order to 396 realize the real world effect produced by a capability to 397 address a consumer need. 398SERVICE CONDITIONS Service Oriented architecture (SOA) is a style of 399 application architecture. According to Gartner, an 400 application is SOA-based service when it meets these 401 five conditions: 402 1. It is modular. 403 2. The modules are distributable. 404 3. Software developers write or generate interface 405 metadata that specifies an explicit contract so that 406 another developer can find and use the service. 407 4. The interface of a service is separate from the 408 implementation (code and data) of the service provider. 409 5. The service is shareable - that is, designed and 410 deployed in a manner that enables them to be invoked 411 successively by disparate consumers. 412 413SERVICE METRICS Monitoring services provides audit, logging, charge- 414 back, financial reporting for investments, design, 415 deployment, maintenance planning, and other purposes 416 via metrics such as: 417 Quality of Service (QoS) and Performance 418 • Number of requests 419 • Number of failed requests 420 • Number of successful requests 421 • Service time 422 • Maximum response time 423 • Last response time 44 Page 11 of 14 45
  • 12. 46Washington Enterprise Architecture Program January 14, 2010 47Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2 424 Reuse Metrics 425 • Number of services deployed 426 • Number of consumer applications deployed 427 • Number of services and number of consumers 428 • Number of services shared by applications 429TIER ONE Statewide Enterprise Architecture business processes, 430 data, or technologies that are common among the 431 majority or to all state agencies. 432 Tier Definitions: 433  Tier One: Across/among agency systems 434  Tier Two: Within an agency 435  Tier Three: Sub-agency level 436 These three different tiers depend on the degree 437 to which they should be common, and what other entities 438 with which they should be common. A description of the 439 state’s Tiers is available at: http://isb.wa.gov/committees/ 440 enterprise/concepts/ 441 Also see ISB EA Over-Arching Principles, including 442 Commonality at: http://isb.wa.gov/committees/enterprise/ 443 architecture/overarchingprinciples.doc 444 8.References 445GARTNER SOA Overview and Guide to SOA Research, April 2009 446INTEGRATION ARCHITECTURE ISB Integration Architecture Standards and Solution Sets 447 at: http://isb.wa.gov/policies/eaprogram.aspx. 448OASIS Reference Architecture Foundation for Service Oriented 449 Architecture 1.0, OASIS Committee Draft 2 (Authoritative 450 PDF), Oct. 14, 2009 451OPEN GROUP SOA Governance framework, Technical Standard, The 452 Open Group, Aug 2009. 453 454 9.Document History Date Version Editor Change Summary August 31, 2009 1.0 Paul Warren Initial Draft Douglas, DIS Noel Morgan, DOT September to Oct 1.0 Paul Warren Revised Service Principles 12, 2009 Douglas, DIS Combined Service Conditions and Noel Morgan, DOT Design Standards Documenter Team Revised and refined Design 48 Page 12 of 14 49
  • 13. 50Washington Enterprise Architecture Program January 14, 2010 51Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2 Date Version Editor Change Summary Standards Added Service Planning Section Added Glossary and Reference entries Reviewed with Gartner Group Nov 10, 2009 1.1 Paul Warren Douglas DT and EAC suggested edits. Removed physical design style Documenter Team 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 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, 2009 1.2 Paul Warren Douglas Endorsed by EAC Dec 30, 2009 to Jan 1.2 Paul Warren Douglas Stakeholder revisions for clarity and 7, 2010 consistency Jan 14, 2010 1.2 Paul Douglas Adopted by Information Services Board 455 10.Document Context 456This document is within the scope of state’s Service Oriented Architecture (SOA) initiative. The 457Target Architecture is a deliverable within the Initiative Charter adopted on July 10, 2008 by the 52 Page 13 of 14 53
  • 14. 54Washington Enterprise Architecture Program January 14, 2010 55Service Oriented Architecture (SOA) Planning Design Standards ISB Standards — Version 1.2 458Information Services Board (ISB) and available at: 459http://dis.wa.gov/enterprise/enterprisearch/soa_initiative.aspx. 460The SOA Initiative is designed to enable State Strategic IT Plan Goals. 461Initiative Stewards: 462• Bill Kehoe, Department of Licensing 463• Frank Westrum, Department of Health 464Initiative Architect: 465• Paul Warren Douglas, Department of Information Services 466Documenter Team: 467• Documenter Team consisted of 27 multi-agency subject matter experts representing 11 468 agencies. 469Drafting and Review Process: 470• About 42 individuals representing 18 agencies statewide helped draft or review the SOA 471 standards, including the Documenter Team and Enterprise Architecture Committee. 56 Page 14 of 14 57