SOA Initiative Charter (doc)

Service-Oriented Architecture (SOA)Initiative Charter

ISB Approved

Version 3.03.0

Information Services BoardEnterprise Architecture Committee

Bill Kehoe, Department of LicensingFrank Westrum, Department of Health

Co-Chairs

Paul Warren Douglas, Acting Enterprise Architect

Stewards/Contributors:

Bill KehoeDepartment of Licensing

Christy RidoutDepartment of Labor & Industries

Frank WestrumDepartment of Health

Paul Warren DouglasDepartment of Information Services

Reviewers/Contributors:

Documenter Team

Enterprise Architecture Committee

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

1

Washington State Enterprise Architecture Program July 10, 2008Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0

July 10, 2008 Table of Contents

1. Document History....................................................................................................................... 3

2. Document Context...................................................................................................................... 3

3. Purpose...................................................................................................................................... 3

4. Initiative Description....................................................................................................................4

4.1. Introduction.......................................................................................................................... 4

4.2. Background.......................................................................................................................... 4

4.3. Objectives............................................................................................................................ 5

5. Key Issues or Decisions to be Addressed...................................................................................5

5.1. Related EA Committee Principles........................................................................................6

6. Deliverables and Timelines.........................................................................................................6

7. Key Stakeholders........................................................................................................................ 7

7.1. Enterprise Architecture Committee Stewards.......................................................................7

7.2. Business Sponsorship..........................................................................................................8

7.3. Documenter Team................................................................................................................8

7.4. Coordination with Related Efforts.........................................................................................9

8. Past Work on this Initiative..........................................................................................................9

9. Documenter Team Process........................................................................................................9

9.1. Time Commitment of the Documenter Team.......................................................................9

10. Document Review Process.......................................................................................................9

10.1. Key Dates......................................................................................................................... 11

10.2. Timeline............................................................................................................................ 11

11. Evolving a Single, Cohesive Enterprise Architecture..............................................................11

12. Initiative Status Reporting.......................................................................................................11

13. Initiative Sunset...................................................................................................................... 12

14. Glossary.................................................................................................................................. 12

15. References............................................................................................................................. 13

Page 2 of 18

234

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

48

49

50

5

Washington Enterprise Architecture Program July 10, 2008Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0

1. Document History

Date Version Editor Change

March 7, 2007 - October 26, 2007

1.0 – 1.6

Allen Schmidt

Bill Kehoe

Christy Ridout

Frank Westrum

Paul Warren Douglas

Conceptual Draft for EA Committee endorsement

October 31, 2007 2.0 Paul Warren Douglas Endorsed by EAC. Documenter Team Draft

April 3, 2007 2.1 Paul Warren Douglas Documenter Team Comments

May 15, 2008 2.2 Paul Warren Douglas

Ed Tolentino

Documenter Team Comments

SOA Definition

May 13, 2008 2.3 Paul Warren Douglas

Ed Tolentino


SOA Definition Edits

June 3, 2008 2.4 Christy Ridout EA Committee Comments and Endorsement

July 10, 2008 3.0 Paul Warren Douglas Approved by the Information Services Board

2. Document Context

This document currently has ISB Approved status. This status signifies the document has been endorsed by the EA Committee and approvedted by a vote of the Information Services Board. For more information about the ISB Enterprise Architecture Committee and its initiative, please visit the EA Committee website at:

http://isb.wa.gov/committees/enterprise/index.aspx

3. Purpose

(SOA) The purpose of this charter is to identify the opportunity and high-level plan for a TIER ONE Service Oriented Architecture (SOA) initiative designed to advance the state’s enterprise architecture. The document provides a description, background, expected deliverables, scope, resources, timelines, and key issues and decisions to address in order to achieve the initiative’s objectives.

Page 3 of 18

67

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

8

http://isb.wa.gov/committees/enterprise/index.aspx


The Enterprise Architecture is defined as a logically consistent set of principles, practices, policies, models, standards, and guidelines that are derived from business requirements that guide decision-making and the engineering of an organization’s information systems and technical infrastructure.

The ISB Enterprise Architecture Standards, Guidelines, and related architectural documents are available at: http://isb.wa.gov/policies/eaprogram

4. Initiative Description

4.1. Introduction

The state of Washington places a high-priority on Government accountability and efficiencies in services. Government services need to be provided from the perspective of a cohesive, single state enterprise.

Agency business programs provide secure and reliable services statewide, while various types of applications and technical infrastructure ensure 24/7 delivery of those government services. The systems are built using a variety of technologies and platforms, and parts of these systems perform similar functions.

The opportunity exists to identify the similar functions or ‘services’ within the enterprise which could be consolidated into a single service or services to increase efficiency, improve business agility, and reduce organizational complexity. SERVICE-ORIENTED ARCHITECTURE (SOA) separates the business, applications, and technology into loosely coupled ‘service’ layers, so that similar functions can be provided as SERVICES, and made available as reusable building blocks.

Service examples: Authentication, credit card authorizations,

The state’s Enterprise Architecture Committee created the SOA initiative to evaluate and understand this business-driven architectural evolution.

This initiative seeks to develop recommendations for an enterprise SOA roadmap, reference framework, and program requirements to assist in education, identification, creation, and use of shared services.

4.2. Background

Service-Oriented Architecture are evolving as the basic building blocks for enterprise architecture solutions. The target - enterprise agility. The Forrester Research estimates “62% of enterprises are using or will use SOA by the end of 2007, and 40% will use SOA for strategic business transformation1” NASCIO predicts that SOA promises to be a significant innovation for state government. While the concepts of SOA aren’t new, they require enterprise change.

The state’s Information Services Board (ISB) adopted EA Integration Architecture2 standards, and the state’s Enterprise Integration Service, that includes an Integration Competency Center, position the state to create shared services.

SOA Provides:

Agility. Enterprises need to match business needs with the IT infrastructure efficiently and timely.

Maintainability. SOA decouples the business services that have longer lifecycles from the technology services that have shorter lifecycles.

1 Topic Overview: Service-Oriented Architecture, by Randy Heffner, Larry Fulton, Forrester Research, June 8, 2--7 2 ISB EA Integration Architecture Standards at: http://isb.wa.gov/policies/eaprogram.aspx

Page 4 of 18

910

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

11

12

13

14


Reuse. An inventory and/or repository of useful building blocks to reduce development time and maintenance cost.

Interoperability. Services are self-contained, reusable software modules, independent of applications and computing platforms.

4.3. Objectives

The SOA Initiative objectives are associated with Discovery and Initiative Goals as described below. After reviewing the Discovery results, the EAC will either request more work on Discovery or decide whether to proceed with Initiative Goals.

Step 1: Discovery:

Develop the business case for Tier One enterprise SOA.

Create a Tier One enterprise SOA readiness assessment.

Establish common terminology and key concepts.

Step 2: Initiative Goals:

Develop a Tier One enterprise SOA strategy.

Identify program requirements to assist in education, identification, creation, and use of shared services.

Identify and refine policies and standards for SOA planning and governance

Create decision-making framework to manage SOA services.

Develop a reference architecture to help guide service design and deployment.

5. Key Issues or Decisions to be Addressed

How to utilize the Enterprise Integration Architecture/Integration Competency Center components/artifacts/services

What roles and responsibilities are required to create and maintain an SOA Services program for Tier One services?

What primary technologies enable SOA (i.e. enterprise service bus, data integration, metadata repositories and management, integration middleware, etc.)

What Web Services or messaging technologies and best practices ensure security and reliability for the deployment and consumption of shared services?

What are the risks and/or pain points of adding shared services to an existing business process function or application (e.g. potential network impacts, added governance, etc?)

How does a multi-agency enterprise identify, select, and agree upon the service to be shared?

What private and public sector best practices exist for SOA programs and resources, education, governance, and use?

Identify ISB standards, state RCWs, federal mandates, or other policies for implementing shared services, including potential impacts to business or technical services delivery models.

What are the recommended architecture review and compliance models for the SOA?

What best practices, tools, and industry standards are recommended for business and data modeling, describing, storing, etc.

Page 5 of 18

1516

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

17


How do we engage with and educate the business community and agencies? What are the private and public sector best practices?

What are the related state’s ISB security standards, and what ‘industry’ standards and best practices are needed (e.g. WS-Security) to ensure security.

5.1. Related EA Committee Principles

The Shared Services for SOA Architecture initiative will rely on the state’s EA Tier One over-arching principles3 for initiative decision-making. Other domain-specific principles may also be established during the initiative process as noted in Section 5: Key Issues or Decision to be Addressed.

Key Tier One over-arching principles include:

The Commonality Principle - Should be common where there is a clear business case; once designated as common, justification is required to deviate

The Interoperability Principle – Should enable interoperability

The Natural Boundaries Principle - Should be designed around natural boundaries.

The Business Continuity Principle - Should be designed and implemented in a way that minimizes interruptions to service

6. Deliverables and Timelines

This section identifies the high-level work plan deliverables, and timelines to achieve the initiative Objectives identified in Section 4.4. Each enterprise initiative evolves architectural components (including policies, standards, and guidelines) in accordance with the NASCIO EA Framework and Architecture Lifecycle documented in the Enterprise Architecture Program’s Program Management Plan.

Document Description Timeline

Charter

Define the opportunities, objectives, scope, stakeholders, and documenter team members. Gain Executive Sponsorship.

July 10, 2008 - ISB

3 The Washington State EA Over-Arching Principles at: http What are the risks and/or pain points of adding shared services to an existing business process function or application?

://isb.wa.gov/committees/enterprise/architecture/index.aspx

Page 6 of 18

1819

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

20

21

22

23


Phase Document/Task Purpose Timeline

Phase I – Baseline Architecture

Baseline Artifacts, Solution Sets

Identify the state’s current SOA processes, and architecture (i.e. Integration Architecture, Integration Competency Center, policies, solution sets, initiatives, etc.)

TBD

SOA Architecture Domain

Identify principles, business drivers, and environmental trends to guide Tier One enterprise SOA decisions.

Document SOA industry standards and best practices for business, information, technology, and solution architectures.

TBD

Phase II – Target Architecture

Target Architecture Solution Set

The preferred Tier One SOA architecture, including functional and supporting features.

TBD

Phase III – Gap/Opportunity Analysis

Gap/Opportunity Analysis

Strategic analysis between Baseline and Target Architectures including: final gaps/opportunities, and recommended migration strategies.

Finalizes selected components for target architecture. Can include additional findings.

Note: Includes recommended migration strategies to ‘close the gaps’ (i.e. common authentication, standards, architectural changes), and meet initiative objectives identified in charter including:

Conceptual Technical Reference Architecture

Create Enterprise SOA Reference Architecture. Include selected domain principles, business drivers, environmental trends, target solution set features, and glossary.

TBD

Phase IV – Migration Plan

Recommended Migration Strategies

Recommended Standards and Migration Strategies to meet Initiative Objectives

TBD

Page 7 of 18

2425

173

26


7. Key Stakeholders

This section identifies key stakeholders of the initiative.

7.1. Enterprise Architecture Committee Stewards

Each initiative must have at least one steward from the Enterprise Architecture Committee.

Committee stewards can be considered as the executive sponsors of the initiative. As such, the stewards are responsible for coordinating communication with the Committee, coordinating communication with other executive stakeholders, assisting in removal of obstacles to the initiative’s progress, and assisting in making resources available to the initiative. In all of these responsibilities, the Enterprise Architecture Program will support the stewards as needed.

EA Committee Stewards

Bill Kehoe, Department of Licensing

Christy Ridout, Labor and Industries

Frank Westrum, Department of Health

Acting Enterprise Architect

Paul Warren Douglas

Documenter Team Members

See Appendix A

7.2. Business Sponsorship

State agency business service owners are key stakeholders for creating the business vision and objectives for an enterprise SOA shared services program. This initiative will seek opportunities to establish open communications channels to identify common business requirements.

Part of a successful SAO strategy is for IT to partner with process-centric business leaders who have a process mandate, and then to internalize that process partner’s business goals. Business and IT must co-articulate and execute the vision of business process improvement and the contribution of a services oriented architecture.

SOA requires architects to focus on business capabilities, rather than on applications. Business processes must be expressed in terms of capabilities that business requires, and then evaluated in terms of commonalities and synergies before considering enabling systems. SOA is not a technology. It requires strong commitment from the business sponsors to re-think their operating model and to break down the functional boundaries within the organizations.

An enterprise SOA needs collaboration between IT and lines of business that focuses on business process modeling, business strategy mapping, application integration and data standards. During this collaboration, the business community will need to focus on their business workflows, their decision support data requirements, and their analytical processes. IT will need to focus on the technical architecture, business applications, and business reporting solutions. In doing this together, they need to drive toward a process centric culture that develops collaboration among enterprises.

7.3. Documenter Team

The Documenter Team will consist of subject-matter experts and other stakeholders to assist the Enterprise Architecture Committee and Program with completing the deliverables for the initiative.

Page 8 of 18

2728

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

29


The EA Committee and Program will send an open invitation for subject matter experts to participate on the multi-agency/entity Documenter Team. Documenter Team members for this initiative are expected to include agency enterprise architects, application architects, technology architects, and business solutions architects. Individuals may also be invited to participate based on their experience. The Documenter Team is listed in Appendix A.

An SOA enterprise architect is expected to be acquired to help the initiative achieve its objectives, and other Industry experts may be brought in to work on specific project deliverables.

The initiative stewards are responsible to ensure the following roles are sufficiently staffed for to complete the project objectives. This initiative should not move forward until all of the roles below are satisfied by the team membership or contracted assistance.

Note: The following draft Roles and Responsibilities matrix is subject to change following the selection of the SOA enterprise architect and program resources.

DRAFT Role4 DRAFT - Definition/Purpose

Executive Sponsors/Stewards

Communicates with key stakeholders on behalf of the initiative

Ensures the Documenter Team has adequate resources to meet its milestones

Facilitates resolution of issues that cannot be resolved within the team

SOA Enterprise Architect

Primary Subject-Matter Expert

Provides technical expertise in the initiative’s topic areas

Responsible to provide each written deliverable

(See list of deliverables and responsibilities identified within the Statement of Work)

Brings best practices and lessons-learned to the initiative

Authors artifacts (supported by Chief Enterprise Architect and Policy Advisor)

Agency Architects

Subject-Matter Experts

Represent communities of interest

Brings best practices and lessons-learned from the statewide IT community to the initiative

Project Manager Monitors and reports initiative’s progress towards milestones

Provides logistical support to Documenter Team (meeting coordination, support resources, etc.)

Facilitates team meetings and ensures maximum meeting productivity/effectiveness

Manages submission of team’s artifacts to central EA repository

Enterprise Architect Provides strategic direction to ensure the SOA enterprise architecture aligns with the state’s enterprise architecture direction and policies, and

4 The Roles and Definition/Purpose Matrix is based on the NASCIO EA Tool Kit.

Page 9 of 18

3031

214

215

216

217

218

219

220

221

222

223

224

225

226

32

33


DRAFT Role DRAFT - Definition/Purpose

other domains

Support in the identification of the correct framework artifacts, existing policies, etc.

Supports executive sponsor in communicating with the EA Committee

Authors and reviews artifacts (supported by SMEs and Policy Advisor)

Provides coordination across Documenter Teams and Domains

Policy Advisor Supports Documenter Team in creation of Compliance Components (policies, standards, guidelines) in the Technology Architecture

Through artifact review, ensures Compliance Components meet ISB form and content standards

Provides policy-oriented coordination across Documenter Teams

7.4. Coordination with Related Efforts

The Shared Services initiative will examine the relationships to other initiatives such as the Integration Architecture Standards, the Enterprise Integration Service and Integration Competency Center, and the Identity Management initiative, as well as any other related EA initiative or ISB policy.

8. Past Work on this Initiative

Some state and local agencies/entities and educational institutions have built common services and/or Web services or SOA solutions or components; however, there is not an Enterprise SOA Program to provide needed education to enable the identification, selection, and use of common services.

9. Documenter Team Process

This section identifies the expected schedule for the initiative’s activities and deliverables in the Document Process.

The Enterprise Architecture Committee and Program recognize that by its very nature, the effort to reach architectural milestones is difficult to predict. At the same time, the Committee and Program have established that the Enterprise Architecture must be in the habit of frequently producing valuable deliverables. Therefore, initiatives must practice effective project management techniques, including time boxing of objectives as needed, to remain on-track with this schedule. Schedule deviations must be communicated and coordinated with the Enterprise Architecture Committee.

The target milestone dates listed above are the EA Program’s best estimate at the outset of the Contextual pass. At the conclusion of each level of detail, the Documenter Team and EA Program will have a much better estimate as to the time required to complete the initiative.

Page 10 of 18

3435

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

36


9.1. Time Commitment of the Documenter Team

This section sets forth the expectations of the Enterprise Architecture Committee and the Enterprise Architecture Program as to what commitment of time and resources will be requested of team members.

The Documenter Team member’s time still needs to be determined for this initiative. Past initiatives averaged 3-6 hours per month. The Enterprise Architecture Program’s expected hours per week will be determined on scope and selection of deliverables.

10. Document Review Process

This section identifies the expected schedule for the initiative’s activities and deliverables in the Review Process. Note that the Review Process need not follow the Document Process sequentially; some of the Review Process milestones may occur during the Document Process timeline.

10.1. Key Dates

Key stakeholder’s meeting schedules are: TBD

Key stakeholder meeting dates will be included in the detailed workplan developed and managed by the SOA enterprise architect.

10.2. Timeline

This section identifies the expected dates for the Review Process milestones. The timeline and review process will be identified within the detailed project workplan.

Phase I – Process Example Activity (note stakeholder group) Date

Comment/Revision Enterprise Architecture Committee review and endorsement of contextual artifacts (Charter) and Phase I Conceptual

October 2007 – June 2008

Information Services Board review of contextual and conceptual artifacts (Charter and Phase I Conceptual

July 10, 2008

Endorsement EAC – Contextual (Charter) and Phase I Conceptual

October 2007 – June 2008

ISB - Contextual (Charter) and Phase I Conceptual

July 10, 2008

Page 11 of 18

3738

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

39


11. Evolving a Single, Cohesive Enterprise Architecture

The Enterprise Architecture Committee has established the goal of having all enterprise initiatives evolve a single, cohesive Tier One SOA Enterprise Architecture for Washington State.

Members of the Documenter Team are asked to share in this goal with the Committee and the Enterprise Architecture Program. The Program will provide the coordination, leadership, and consulting expertise to ensure the achievement of this goal through development of standard architecture artifacts with standard tools and housed in a single repository. The Program will also ensure that artifacts from all initiatives are presented to the stakeholder community as a cohesive architecture, in accordance with the Program’s Communications Plan.

12. Initiative Status Reporting

The Enterprise Architecture Program will prepare an initiative status report for each Enterprise Architecture Committee meeting (every other Wednesday). The status report will contain, at a minimum:

Status of initiative versus expected timeline for each level of detail, established above

Indicator of whether this status is on track or not

If no progress has been made on the initiative in the past two weeks, the status report will indicate a reason

The Enterprise Architecture Program Director will circulate the status report for review by the Documenter Team.

13. Initiative Sunset

When the Documenter Team, Enterprise Architecture Committee, or Enterprise Architecture Program Director believe the initiative has achieved its initial objectives, the topic of closing out the initiative will be placed on the agenda of the Enterprise Architecture Committee. The initiative will be closed, or not, at the discretion of the Committee or by the Information Services Board.

14. Glossary

SERVICES Self-contained, reusable software modules that are independent of the computing platforms on which they run. Services allow a 1:1 mapping between business tasks and the exact IT components needed to execute the task. Services can be shared, and can be combined, to form complete business solutions.

An SOA service used by more than one business solution. Shared services are often classified by scope or range of influence. “Enterprise” services are shared across many business domains. “Domain” services are shared within a single business domain. “Local” services are typically confined to a single business solution

SERVICE-ORIENTED ARCHITECTURE A Service Oriented Architecture (hereafter called SOA) is an architectural framework designed to offer common services, in an agreed upon, consistent fashion, to reduce duplication of effort across an enterprise.

It is one tenet of organizational transformation and IT management focused on a long-term view blueprint (with

Page 12 of 18

4041

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

42


a plan) that describes the transitioning from current and desired operational state. SOA unifies business processes through the use of service encapsulation, loose coupling, abstraction, reusability, composability, autonomy, and discoverability.

Business services can be defined, and be implemented in a unified enterprise view that is coherent & repeatable, hence;

All functions are defined as services. This includes purely business functions, business transactions composed of lower-level functions, and system service functions.

All services are independent. They operate as "black boxes"; external components neither know nor care how they perform their function.

In the most general sense, the interfaces are virtually-usable; that is, at an architectural level, it is irrelevant whether they are local (within the system) or remote (external to the immediate system), what interconnect scheme or protocol is used to effect the invocation, or what infrastructure components are required to make the connection.

In all this, the interface is the key, and is the focus of the calling application. It defines the required parameters and the nature of the result; thus, it defines the nature of the service, not the technology used to implement it. It is the system's responsibility to effect and manage the invocation of the service, not the calling application. This allows two critical characteristics to be realized:

That the services are truly independent, and

That the services can be managed.

It is imperative to develop a stage “Architecture Management Maturity Framework” that defines what needs to be done to effectively manage the Service Oriented Architecture initiative.

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

Tier Definitions:

Tier 1: Across/among agency systems Tier 2: Within an agency Tier 3: 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/

WEB SERVICES A set of standards-based, platform-independent technologies designed to support interoperable program-

Page 13 of 18

4344

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

45

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


to-program interaction over a network. The advent of Web services has largely influenced the broad adoption of SOA. However, in the context of a Service-Oriented Architecture, Web services are just one possible communication mechanism..

15. References

Enterprise SOA Enterprise SOA, Service-Oriented Architecture Best Practices, Dirk Krafzig, Karl Banke, Dirk Slama, 2005

SOA-ERL Service-Oriented Architecture, Concepts, Technology, and Design, Thomas Erl, 2005

Gartner Gartner Group Research Service, retrieved 2007

Forrester Forrester Research Service, retrieved 2007

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

Page 14 of 18

4647

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

48


Appendix A: Documenter Team

This document was developed through the enterprise architecture Shared Services for SOA initiative, chartered (expected) January 10, 2008. The following individuals were members of the Documenter Team for this initiative, and participated in review of this document.

First Last Company Email Phone RoleBill Kehoe Department of Licensing StewardChristy Ridout Labor and Industries StewardAllen Schmidt Office of Financial

ManagementStatewide Financial Systems

Ed Tolentino Department of Information Services

Enterprise Architect

Frank Westrum Department of Health StewardPaul Douglas Department of Information

ServicesPolicy Advisor

Little Sheryl Department of Licensing Administrative Documentation SupportProgram Team

Kent Andrus Office of Financial Management

Agency Architect/Subject Matter Expert

Jerry Britcher Department of Social and Health Services


Bill Yock University of Washington Agency Architect/Subject Matter Expert

Donna Edwards Department of Information Services


Lance Calisch Department of Information Services


Darrell Davenport Department of Retirement Systems


Roger Deming Liquor Control Board Agency Architect/Subject Matter Expert

Gary Dubuque Department of Revenue Agency Architect/Subject Matter Expert

Robin Griggs Department of Licensing Agency

Page 15 of 18

4950

381

382

383

384

51


Architect/Subject Matter Expert

Bret Holtz Department of Health Agency Architect/Subject Matter Expert

David Jennings Department of Health Agency Architect/Subject Matter Expert

JoAnne Kendrick Department of Information Services

Chief Integration Officer

Chris Lamb Department of Retirement Systems


Daniel Mercer Labor and Industries Agency Architect/Subject Matter Expert

Noel Morgan Department of Transportation


Joy Paulus Department of Information Services

GIT Architect/Subject Matter Expert

Heidi Whisman Department of Ecology Agency Architect/Subject Matter Expert

Son Tran Department of Ecology Agency Architect/Subject Matter Expert

Douglas McGregor Department of Licensing Agency Architect/Subject Matter Expert

Appendix B: Review Log

The following feedback on this document was received by the Enterprise Architecture Program; the response to each contribution is noted below.

Review by whom and when

Contribution Response

Initiative Stewards and acting CEA

Renamed initiative from Common Services to Shared Services

Revised/Updated Document Context

Incorporated into Document

Page 16 of 18

5253

385

386

387

388

54


to reflect latest EA Program version

Updated Appendix A: Documenter Team

Revised expected Charter date for request for ISB adoption

EAC, enterprise architects

Clarified SOA, shared services, objectives and scope.


EAC and Initiative Stewards

Reworded intro to clarify the initiative will evaluate and understand and create recommendations, rather then implement

Objectives reordered to focus on high-level, added discovery objective “first identify if SOA strategy should be perused at the Tier One level, others moved to Key Questions section. Moved business focused objectives to Key Questions section.

Added new row section 9 Baseline to identify the state’s current artifacts, solutions, etc (i.e. Integration Architecture)

Changed target dates



Removed Shared Services from title, as service result from SOA

Edited document to remove Shared Services where needed

Revised Glossary entries and definitions

Revised Section 6 Scope and Section 9.2 Timeline and Deliverables, and aligned with initiative Objectives

Replaced Section 6 with Section 9.2



Refined Objectives based on DT comments

Revised Glossary definitions

Renamed 4.3 Business Drivers/Environmental Trends – ‘SOA Provides.’

Combined/removed duplicate Key Issues or Decisions


Page 17 of 18

5556

57


Removed bulleted Objectives in Deliverables and Timelines and created cross reference

Final DT Comments

5/13/08

Clarified Purpose section

Minor revisions in Introduction and Key Issues

SOA Glossary definition revision


EA Committee Comments

6/3/2008

Revised Objectives. Added Stepped approach including:

Step 1: Discovery Business Case, Readiness Assessment, and Glossary


Page 18 of 18

5859

389

60

Documents

SOA Initiative Charter (doc)