SOA Baseline/Target with Summary Recommendations (doc)

Last Modified: Dec 16, 2009

Service-Oriented ArchitectureInitiative (SOA) Baseline/Target

ArchitectureWith Gap/Opportunity Analysis and

Summary Recommendations

EA Committee Endorsed

Version 1.21.2

December 16, 2009

Primary Contributors

Bill KehoeDepartment of Licensing

Frank WestrumDepartment of Health

Paul Warren DouglasDepartment of Information Services

Stephen BackholmDepartment of Social and Health Services

Jerry BritcherDepartment of Social and Health Services

Gary DubuqueDepartment of Revenue

David JenningsDepartment of Health

JoAnne KendrickDepartment of Information Services

Douglas McGregorDepartment of Licensing

Noel MorganDepartment of Transportation

Other ReviewersSOA Documenter Team

Enterprise Architecture CommitteeStatewide Stakeholders - pending

Stewards

Information Services BoardEnterprise Architecture Committee

Rob St. John, Department of Social and Health Services

Clare Donahue, University of Washington

Co-Chairs

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

1

Washington State Enterprise Architecture Program December 16, 2009Service-Oriented Architecture Initiative (SOA) Baseline/Target Architecture Documenter Team Draft Version 1.2

Table of Contents

1. Introduction................................................................................................................................ 4

1.1. Definitions........................................................................................................................... 4

2. Gap/Opportunity Analysis and Summary Recommendations....................................................4

2.1. Proposed Standards...........................................................................................................4

2.2. Summary Recommendations..............................................................................................5

2.3. Recommended Strategies..................................................................................................6

3. Baseline and Target Architectures............................................................................................6

4. Enterprise SOA Commitment and Business Case....................................................................6

5. Governance............................................................................................................................... 7

6. Funding Models......................................................................................................................... 8

6.1. Funding Model Options.......................................................................................................8

7. Enterprise SOA Roadmap.........................................................................................................9

7.1. Stage One: 2006-2008........................................................................................................9

7.2. Stage Two: 2009-2010........................................................................................................9

7.3. Stage Three: 2009-2014...................................................................................................10

8. Maturity Models....................................................................................................................... 11

8.1. Integration Maturity Model Levels.....................................................................................11

8.2. Integration Competency Center Model Levels..................................................................11

9. Collaboration and Communication..........................................................................................12

9.1. Roles and Responsibilities................................................................................................13

10. Performance Monitoring and Testing.....................................................................................14

10.1. Service Level Agreement................................................................................................14

11. Infrastructure and Technologies............................................................................................14

12. State ICC SOA Backplane.....................................................................................................15

12.1. SOA Backplane Functionality.........................................................................................15

13. Processes and Framework....................................................................................................16

14. Reference Architecture..........................................................................................................17

of 22

234

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

5


15. Education and awareness.....................................................................................................17

15.1. Skills and training............................................................................................................18

16. IT Business Transformation...................................................................................................18

17. Related Policies, Principles and Standards...........................................................................19

18. Glossary................................................................................................................................ 19

19. References............................................................................................................................ 19

20. Document Context.................................................................................................................20

21. Document History..................................................................................................................21

of 22

678

48

49

50

51

52

53

54

55

56

57

9


1. IntroductionThis document describes the enterprise SOA Baseline and Target Architectures. It identifies the state’s current environment and end goal, or what the SOA environment will look like once implemented, in the form of SOA components, methods, and policies. The document builds on the Domain architecture recommendations.

The Baseline/Target Architecture provides decision-making information. The proposed results are included in the Gap/Opportunity Analysis section which identifies recommended standards and strategies needed to complete initiative objectives and enable State Strategic IT Plan Goals and Strategies (SSITP).

1.1. Definitions Service-Oriented Architecture (SOA) – An architectural method or design style that results in and

supports shared, reusable services.

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

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

o Are loosely coupled to a new or existing application.

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

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

SOA Backplane – Supporting infrastructure such as registry/repository, middleware, enterprise service bus (ESB), and life cycle management, communications, and analytical tools. Typically managed by an Integration Competency Center (ICC).

SOA Domain – Can be defined by different boundaries like common services and consumers, yet typically has its own ICC and SOA backplane (e.g. State ICC Domain.) with service registry and repository, infrastructure, design and monitoring tools, and more.

SOA Governance – Is the structure and process for making policy and operational changes. Includes Steering Committee, Technical Advisory Group, and state ICC for change management. Operational governance can help automate life cycle management, policy management, and SOA metadata management performed by the service registry/repository.

2. Gap/Opportunity Analysis and Summary Recommendations2.1. Proposed Standards

The following standards should be developed, adopted to enable the summary recommendations and strategies. The standards are likely to mature as the state’s SOA-based architecture, services, and governance structure evolves:

Develop and adopt SOA Governance Standards

o Establish SOA Services Steering Committee and Technical Advisory Group

Note: These suggested governance roles and responsibilities may be new, added to existing groups, or created as needed,

of 22

101112

58

59

60

61

62

63

64

65

66

67

68

697071

7273

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

13


Develop and adopt SOA Service Design Standards

o Includes principles, service conditions, and design standards

2.2. Summary RecommendationsGovernance – The state should establish an SOA Steering Committee and Technical Advisory Group to work with the ICC to help review and recommend Tier One services. Services are guided by agency business needs.

Roles and responsibilities should be clearly defined; key stakeholders represented on governance teams, and Integration Competency Centers should coordinate and communicate.

An enterprise service registry/repository is critical for publishing and monitoring services, as well as minimizing duplicate efforts.

Change management processes, policies, and service level agreements are required.

2.2.1. Value Services are designed as application components for reuse, sharing, and improve extensibility for

legacy systems. SOA can enable the reuse and agile combination of purchased packages, legacy applications, and

services. Focus should not only be placed on maturing SOA at the Tier One level, but agencies should mature

their own application development areas to utilize SOA principles at Tier Two and Tier Three where appropriate.

SOA is an application design practice. Many SOA design styles exist and may be dependent on existing infrastructure and applications.

Some Enterprise Resource Planning (ERP) systems are adding shared modular functionality through SOA methods to leverage existing investments.

2.2.2. Design Risks Not all application modules should be services and service nesting (sub-layered, dependent services)

is discouraged to minimize complexity. Poorly designed or redundant services lead to higher costs and complexity.

2.2.3. Tools and Technologies A variety of automated tools and technologies are available to measure usage, monitor performance,

and support a standardized environment. They are expected to evolve to meet business needs. An Enterprise Service Bus (ESB) is not always required, yet commonly used to implement shared

services.

2.2.4. Communication More communication and education is needed to help agencies provide and consume Tier One

services. New skills and training will help improve SOA success.

While services are designed to be shared, the term ‘Shared Services’ is more appropriately used to define the state’s initiatives such as Desktop Management and Infrastructure Management, driven by the state’s Customer Advisory Board.

2.2.5. Funding Identify services on funded projects where possible. SOA strategies should be flexible and adaptable. Shared cost models encourage development teams to make application functionality available. Helps ensure the hosting agency’s services (also known as service provider) offered up as Tier one

have longevity for the provider and consumers lines of business.

of 22

141516

96

97

98

99

100

101

102103

104105

106

107

108

109

110111

112113114

115116

117118

119

120121

122

123

124125

126127

128

129130

131132133

134

135

136

137

138

17


2.3. Recommended Strategies Following review by the governance teams, Tier One services shall be published to the state’s service

registry.

Agency service providers and consumers should check the state SOA registry for an existing service before building or buying a new one.

The state SOA registry should have a location for agencies to post Tier Two services in order to reduce service design redundancy and promote potential Tier One service candidates.

Request for Proposals (RFP) should require proposed vendors to identify and describe the proposed solution’s SOA readiness and SOA architecture.

Acquisitions should include language to identify proposed vendor’s capabilities to loosely couple with the state’s current and future shared services.

Leverage existing investments where possible. Enterprise Resource Planning (ERP) solutions – include SOA requirements in new acquisitions.

Tier One services should have a clear business owner and service provider.

Utilize and evolve the ISB Integration Architecture Service Repository Solution Set rather than develop another document.

3. Baseline and Target Architectures

The baseline describes the current operational environment. The target architecture provides a vision of what the desired goal environment will look like and how it will function.

4. Enterprise SOA Commitment and Business Case Baseline Target

State strategic IT plan includes goals to promote common IT practices, data sharing, reuse and other SOA strategies.

X X

The state has completed a Business Case for enterprise SOA and further exploration of Tier One services.

X X

of 22

181920

139

140141

142143

144145

146147

148149

150151

152

153

154

155

156

157

158

21


5. Governance Baseline Target

The ICC Governance role and responsibility is specified in the current Integration Services Governance ISB Document Version 2.0 dated January 4, 2007.

X X

Governance is necessary to lead and support enterprise Tier One service development. SOA governance should include:

SOA Services Steering Committee X

Composed of State Agency CIOs. Include business leaders where possible for areas such as Data Services.

X

Articulates the business needs that shape and control the overall SOA strategy, services offering, and supporting infrastructure.

X

Works with state’s Integration Competency Center (ICC) to: Ensure services meet SOA Governance Standards and SOA

Service Design Standards.

X

Ensure service providers and consumers are utilizing the state’s Backplane for Tier Once service integration and messaging rather than building point to point solutions.

X

Plan for potential service candidates that enhance business solutions.

X

Help develop and evolve the SOA standards and guidelines to recommend for statewide adoption.

X

SOA Services Technical Advisory Group: X

Composed of state agency architects. X

Reports to the Services Steering Committee. X

Answers technical architecture questions as defined and chartered by SOA Services Steering Committee.

X

State agencies’ business needs should drive Tier One SOA Strategy. As a result, the SOA governance bodies composed of agency representatives should lead by answering the following governance

of 22

222324

159

25


5. Governance Baseline Target

questions:

What services should be built? X

How will agencies find and re-use existing services? X

How will change management work for existing services and supporting infrastructure?

X

What standards and policies should be created for Tier One SOA services and infrastructure?

X

Who will enforce defined standards and policies? X

At what granularity level will Tier One services exist? X

What constitutes a Tier One service? X

6. Funding ModelsFunding models are an important part of ensuring the longevity and stability of Tier One services. Monetary costs associated with building and maintaining Tier One SOA services should be addressed.

6.1. Funding Model Options Baseline Target

Enterprise-based X X

Project-based X X

IT or individual line of business X X

Charge back X X

Provide a monetary reward from a central fund for an accepted Tier One service. This will give agencies incentive to offer up Tier One compliant services for others to use.

X

Cost recovery models exist to support centralized functionality such as the ICC.

X

When services are developed within an agency, funding comes from the agency’s budget. The concern is if funding is no longer available.

X

of 22

262728

160

161

162

163

29


6.1. Funding Model Options Baseline Target

The Core Service Principle is one way to address this issue. If an agency develops a SOA service to support their core business, they will be more likely to maintain that service since core businesses of agencies are fairly stable.

X

Shift support of a service to a central support agency (such as the ICC). With this model, it is key to ensure business expertise on the details that exists within the program agencies are well communicated with the central support agency. While the technical skill may exist within an ICC, the business knowledge remains with the program agency.

X

Mechanism for supporting ongoing maintenance and operations costs X

7. Enterprise SOA Roadmap Baseline Target

7.1. Stage One: 2006-2008 The ISB adopted the Integration Architecture Standards and

Solution Sets. X X

The state established an Integration Competency Center (ICC). X X

Chief Integration Architect hired and ICC staffed with State Architects to assist agencies and maintain the state’s integration infrastructure and SOA Backplane.

X X

7.2. Stage Two: 2009-2010 The state ICC establishes maturity roadmap and communication

plan.

X In Progress

The state ICC will reach Maturity Level 3 (Globally Defined) and stabilize as a Best Practices Model.

X In Progress

Develop recommendations for a statewide Service Oriented Architecture (SOA) roadmap, reference framework, and program requirements to assist in education, identification, creation, and use of shared services (SSITP).

X X

The state ICC SOA Backplane consists of middleware, service registry and repository, Enterprise Service Bus and messaging

X X

of 22

303132

164

33


7. Enterprise SOA Roadmap Baseline Target

technologies that support the integration profiles for system to system integration.

7.3. Stage Three: 2009-2014 Baseline Target

Enterprise SOA will take time to mature, grow, and provide a return-on-investment. With the proper commitment and investment, the state can expect to see an estimate of 10-15 services at the Tier One level over the next 5-7 years.

Evolve statewide Service Oriented Architecture (SOA) roadmap, reference framework, and program requirements to assist in education, identification, creation, and use of shared services (SSITP).

X

X

Service providers and consumers will utilize more services. X

Funding models will evolve to build and sustain SOA-based services.

X

The state ICC will evolve to Maturity Level 4 (Quantitatively Managed) and establish itself as a Shared Services Model.

X

The state ICC will provide services and service orchestrations in compliance with state SOA standards.

X

of 22

343536

165

37


8. Maturity Models

There are 5 Maturity Model Levels as well as 5 Integration Competency Center Model Levels defined by industry best practices.

Baseline Target

8.1. Integration Maturity Model Levels1. Awareness

There is awareness that problems exist but the organization has taken little action regarding Infrastructure Development.

X X

2. ManagedAwareness and action occur in response to issues. Action is either system or department specific.

X X

3. Globally DefinedInfrastructure development is part of the IT charter. Processes and solutions exist to measure and improve.

X X

4. Quantitatively ManagedInfrastructure managed as an enterprise asset and well-developed processes exist and are enforced.

X X

5. Globally OptimizedInfrastructure Development is a strategic initiative. Issues are either prevented or corrected at the source and best-in-class solution architecture is implemented.

X X

8.2. Integration Competency Center Model Levels1. Project Silos

The technology, processes and organization are independent. Projects are optimized.

The Integration Competency Center Model is presently positioned at Project Silos.

X

2. Best PracticesThe technology is recommended, the processes are defined and the organization is distributed to leverage knowledge.

The State Integration Competency Center is currently at the maturity model Level 2, meaning the there is some awareness of the ICC and it is being leveraged for specific projects or systems.

X

3. Technology Standards X

of 22

383940

166

41


8. Maturity Models

There are 5 Maturity Model Levels as well as 5 Integration Competency Center Model Levels defined by industry best practices.

Baseline Target

The technology is standardized, processes are defined and the organization is distributed to provide consistency.

4. Shared ServiceThe technology is shared, the processes are defined and the organization is hybrid to provide resource optimization.

X

5. Central ServiceThe technology is automatic, processes are dynamic and organization is invisible to provide innovation and efficiency.

As the ICC and SOA mature within the State, the maturity model is expected to move towards Level 5 and provide services as a Shared Service.

X

The SOA environment supports mechanisms and tools for self monitoring.

X

o The mechanisms and tools provide the ability to monitor both use and capacity.

X

o Monitoring capacity meet historical and planning purpose requirements.

X

9. Collaboration and Communication Baseline Target

The Integration Competency Center provides tools for integration and SOA collaboration and communication. These tools include a library of integration patterns, a service registry and repository and Integration Technology site.

X X

Collaboration and communication among state agencies related to SOA services is ad hoc.

X

Some agency providers and consumers may have point-to-point services in production.

X

State agencies do not have good visibility as to what services are available for use and integration.

X

of 22

424344

167

45


9. Collaboration and Communication Baseline Target

State Agency Awareness - An enterprise plan and communication model exist to implement and govern shared services.

X

Communication is important to establish a clear understanding of how to utilize SOA services, and to grow agency and staff support for both the development and use of existing services

X

Communication channels and processes are in place to enable the multi-agency enterprise to share services.

X

Tier One data standards play an important role in helping define interfaces and service descriptions. The state must have a defined and enforced Tier One data standards process.

X

Business and IT Communication - Private and public sector best practices have been identified to engage and educate the business community and agencies.

X

9.1. Roles and Responsibilities Baseline Target

The state Integration Competency Center (ICC) Enables collaboration and coordination X X

Manages the state SOA backplane X X

Provisions and maintains the state SOA service repository X X

Ensures compliance to the Change and Configuration Management processes as defined by the SOA Governance Standards

X X

Consults with agencies to design and implement agency to agency interfaces

X X

10. Performance Monitoring and Testing Baseline Target

The state ICC participates in service integration testing in support of agency’s service deployments

X X

of 22

464748

168

169

170

49


The state ICC is responsible for monitoring the integration layer X X

Some agency providers and consumers may have point-to-point services in production.

X

10.1. Service Level AgreementThe state ICC works with agencies to ensure integration layer compliance for:

Availability requirements X X

Responsiveness requirements X X

Compliance to SLA agreements for services consumed. X X

11. Infrastructure and Technologies Baseline Target

The state ICC domain has established a statewide enterprise-level SOA Backplane including:

Tier Two SOA programs and initiatives already exist. Conceptually, the Tier One SOA framework will connect the Tier Two architectures.

To get to this point, some basic infrastructure must be created first. Some components of this infrastructure are:

X X

A Tier One Enterprise Service Bus – ESBs contain not only the transport capacity, but also the ability to transform data. The ability to transform data within the ESB alleviates redundant development for transforming data for consumers of a particular data set

X X

State ICC Service Registry and Repository – These tools provide the framework for housing and vending the Tier One services. They also provide the mechanisms for operational governance of the services (e.g. without meeting pre-established criteria, a service is not made available through the Registry)

X X

12. State ICC SOA Backplane

of 22

505152

171

172

173

53


12.1. SOA Backplane Functionality Baseline Target

Message Routing A routing service is the key component for moving a

message across the enterprise service bus – from its entry point to its exit point.

X X

Transaction Management (similar to many database transaction functions)

X X

Listeners X X

Multi level undo/redoo A method that tells how many levels of undo/redo it wants. X X

Coalescing of transactions Provide methods to merge transactions. X X

Aggregation Provide the ability to gather data or transactions from disparate

sources and return a single data set or responseX X

Nested transactions Provide the methods for one transaction to execute other

transactions.X X

Transformation Facilitation of the transformation of data formats and values,

including transformation services between the formats of the sending application and the receiving application

X X

Transforming messages conditionally, based on a non-centralized policy

X X

Message Brokering Modify service messages in runtime to mediate between different

systems

X X

Reroute service requests in runtime based on content checking rules such as service version

X X

Create new protocol conversion mechanisms with the Open API X X

Set exception based routing and automate runtime exception handling to route messages to available services and provide exception response messages

X X

Throttle messages to allow only a specific number of messages to X X

of 22

545556

57


12.1. SOA Backplane Functionality Baseline Target

reach the service in a specific period of time

Transport Management Support for various MEPs (Message Exchange Patterns) (for

example: synchronous request/response, asynchronous request/response, send-and-forget, publish/subscribe)

X X

Queuing, holding messages if applications temporarily become unavailablethe

X X

Security a standardized security-model to authorize, authenticate and audit

use of the ESB

X X

13. Processes and Framework Baseline Target

The ICC is responsible for defining the strategic and operational processes and framework to support the integration infrastructure, including middleware, registry/repository, adapters, message transport, data repositories and related integration tools.

X X

The ICC is responsible for collecting from service providers and providing to service consumers all metadata and documentation associated to any service registered in the service registry/repository

X X

The SOA Steering Committee is responsible for defining the strategic and operational processes and framework to support Tier One SOA services

X

Tier One elements are in place to address SOA strategic planning, design guidance, SOA implementation and maintenance, service granularity, service interoperability, service identification, and sustainable support.

X

14. Reference ArchitectureBaseline Target

Reference architecture for integration is provided in the Conceptual Integration Technical Reference Architecture ISB

X X

of 22

585960

174

175

176

61


Document Version 4.0 dated September 14, 2006.

Conceptual Technical Reference Architecture complete and published.

X

Expected to evolve over time, yet contains Business Drivers, Environmental Trends, and Principles for Decision-Making, key Target Architecture components, state ICC and SOA Backplane features including state service registry information, and Glossary to promote common terminology.

X

15. Education and awareness Baseline Target

The SOA initiative has resulted in the development of a SOA Glossary for common terminology.

X X

The state ICC has established a multi-agency user group and Integration Technology Forum SharePoint Site.

X X

Common terminology – SOA Glossary developed. Expected to evolve and be updated by SOA Technical Advisory Group.

X X

State Agency Awareness - An enterprise plan and communication model exist to implement and govern shared services. SOA Steering Committee, SOA Technical Advisory Group, state ICC, and service providers all play a role in helping provide education and awareness.

X

15.1. Skills and training The state Integration Competency Center is highly skilled and

continues to seek training in integration and Service Oriented Architecture.

X X

Training and communication are critical to the successful SOA environment.o Application development that incorporates or builds Tier One

services is a new skill set that developers will need to acquire.

X

16. IT Business TransformationBaseline Target

State agencies currently share a variety of services through a collection of methods.

X

of 22

626364

177

178

65


16. IT Business TransformationBaseline Target

IT Business planning, project management, and procurement include identification and do not fully use Tier One shared services.

X

Risk mitigation strategies are not yet defined when adding shared services to existing business process functions or legacy applications.

X

Fiscal benefits are need to be identified to invest in developing Tier One SOA shared services.

X

Potential services candidates (short-term and long-term) are not yet identified and prioritized.

X

IT business processes are not yet being transformed from stand alone, replicated processes into highly leveraged shared services.

X

IT Business planning, project management, and procurement include identification and use of Tier One shared services.

X

Risk mitigation strategies are defined when adding shared services to existing business process functions or legacy applications.

X

Fiscal benefits are identified to invest in developing Tier One SOA shared services. X

Potential services candidates (short-term and long-term) are identified and prioritized.

X

IT business processes are being transformed from stand alone, replicated processes into highly leveraged shared services.

X

17. Related Policies, Principles and Standards State Integration Architecture Standards and Service Interaction Profiles, Service Modeling

Standards, Service Repository Solution Set, and Service Governance.

State IT Security Standards

State Data Standards

Principle: Agency developed Tier One services should only be developed around agency core business services.

18. Glossary

of 22

666768

179

180

181

182

183

184

185

186

187

188

69


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

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

1. It is modular.

2. The modules are distributable.

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

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

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

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

Quality of Service (QoS) and Performance

Number of requests Number of failed requests Number of successful requests Service time Maximum response time Last response time

Reuse Metrics Number of services deployed Number of consumer applications deployed Number of services and number of consumers Number of services shared by applications

SERVICE ORIENTED ARCHITECTURE SOA is an architectural method or design style that results in and supports shared, reusable services.

SOA-BASED SERVICES Are modular, swappable functions, separate from, yet connected to an application via well defined interfaces to provide agility. Often referred to as ‘services’ throughout this document they: Perform granular business functions such as “get customer

address” or larger ones such as ‘process payment.’ Are loosely coupled to a new or existing application.

of 22

707172

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212213214215216217

218

219220221222

223

224

225

226

227

228

229

230

231

73


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

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

SERVICE PROVIDERS AND CONSUMERS Entities (people and organizations) offer capabilities and act as service providers. Those with needs who make use of services are referred to as service consumers.

STATE SOA BACKPLANE Shared, common infrastructure for lifecycle management, registry/repository, policies, business analytics for service metrics; Routing/Addressing, naming, quality of service, communication; Development Tools for security, management, and adapt.

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

Tier Definitions:

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

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

19. ReferencesErl Erl, Thomas. Service-Oriented Architecture: Concepts,

Technology, and Design. Prentice-Hall, 2005.

DKD Krafzig, Banke, Slama, Enterprise SOA, Service-Oriented Architecture Best Practices, Prentice-Hall, 2005

Gartner Gartner Group Research Service, retrieved 2007

Building a Service-Oriented Architecture Business Case: Effective Communication is the First Step, Gartner, March 2007

Forrester Forrester Research Service, retrieved 2007

SOA Repositories: Crucial to SOA Governance Success, Oct 2006.

InfoTech Strategy & Planning, Set the Stage for SOA Governance, Dec 2008.

NASCIO National Association of Chief Information Officers, Enterprise Architecture Tool Kit v 3, October 2003.

SOA-RM Reference Model for Service Oriented Architectures, Working Draft 11. OASIS, 2005.

of 22

747576

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248249250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

77

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


SSITP 2008-2014 Washington State Strategic Information Technology Plan, Strategy 10, Nov 2008.

20. Document ContextThis document is within the scope of state’s Service-Oriented Architecture (SOA) initiative. The Baseline and Target Architectures are deliverables within the Initiative Charter adopted on July 10, 2008 by the Information Services Board (ISB) and available at: http://dis.wa.gov/enterprise/enterprisearch/soa_initiative.aspx.

Initiative Stewards:

Bill Kehoe, Department of Licensing Frank Westrum, Department of Health

Initiative Architect:

Paul Warren Douglas, Department of Information Services

Documenter Team:

Documenter Team consisted of 27 multi-agency subject matter experts representing 11 agencies. Baseline/Target Architecture Co-Leads: Jerry Britcher, Department of Social and Health Services;

JoAnne Kendrick, Department of Information Services.

of 22

787980

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

81

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


21. Document History

Date Version Editor Change

May 18, 2009 1.0 Paul Warren Douglas, Jerry Britcher, JoAnne KendrickDocumenter Team

Initial Draft - Jerry Britcher, DSHS and JoAnne Kendrick, DIS agree to co-lead document with EA Program.

Aug to Oct 12, 2009

1.1 Documenter Team Baseline and Target enhanced and revised by co-leads and documenter team

SOA Steering Committee and SOA Technical Advisory Group details added

Target synchronized with SOA Readiness Awareness Tool

Documenter team additions and revisions.

Oct -Nov, 2009

1.2 Documenter Team EAC suggested revisions to add matrices for readability and easy comparison purposes.Moved Governance to section 5.Moved Document Context to section 19.Added example to Services definition.Format changes for readability.Refining/synchronizing SOA-based Services definition with current documents.

Dec 8, 2009 1.2 Paul Warren Douglas Synchronized Glossaries with draft Standards documents

Dec 16, 2009 1.2 Paul Warren Douglas EA Committee Endorsed

of 22

828384

288

289

85

SOA Baseline/Target with Summary Recommendations (doc)

Business

Transcript of SOA Baseline/Target with Summary Recommendations (doc)