SOA Domain Architecture (doc)

Enterprise Service-OrientedArchitecture (SOA) Domain Document

EA Committee Endorsed

Version 2.02.0

April 15, 2009

ISB Enterprise Architecture Committee Co-Chairs

Frank Westrum, Department of HealthRob St. John, Department of Social

and Health Services

Paul Warren Douglas, Acting Enterprise Architect

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

Reviewers/Contributors:

Documenter Team

Enterprise Architecture Committee

Stewards

Paul Warren Douglas

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

2

Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0

Table of Contents

1. Summary Findings................................................................................................................................... 3

1.1. Governance....................................................................................................................................... 3

1.2. Education.......................................................................................................................................... 3

1.3. Creation and Use.............................................................................................................................. 3

1.4. Standards.......................................................................................................................................... 3

1.5. Tools and Technologies....................................................................................................................3

1.6. Reuse and Agility.............................................................................................................................. 3

1.7. Funding............................................................................................................................................. 3

1.8. Design Risks..................................................................................................................................... 3

2. Document Purpose.................................................................................................................................. 4

3. Description............................................................................................................................................... 4

4. Business Drivers...................................................................................................................................... 4

4.1. Value proposition, operational efficiencies, and cost management...................................................4

4.2. Leverage existing investments..........................................................................................................5

4.3. Application flexibility, agility, and maintenance..................................................................................5

5. Environmental Trends.............................................................................................................................. 6

5.1. Increasing need for interoperability among federal, state, local, educational, and private industry systems.................................................................................................................................................... 6

5.2. Changes in business and technical delivery channels......................................................................6

5.3. Smaller budgets, fewer resources, and organizational changes.......................................................6

5.4. SOA market and solutions are evolving, yet maturing.......................................................................7

6. Industry Trends........................................................................................................................................ 7

6.1. Public and Private Sector Examples.................................................................................................7

6.2. SOA Governance Trends................................................................................................................10

6.3. Funding Trends............................................................................................................................... 10

6.4. Education and Awareness...............................................................................................................11

7. Domain-Specific Principles....................................................................................................................11

7.1. Planned Services Principle..............................................................................................................11

7.2. Enterprise Cost Management Principle...........................................................................................11

7.3. Coordinated SOA Centers of Excellence (COE) Principle..............................................................11

7.4. Neutrality Principle.......................................................................................................................... 12

7.5. Abstraction Principle....................................................................................................................... 12

8. Associated Enterprise Architecture Disciplines......................................................................................12

9. Glossary................................................................................................................................................. 12

10. References.......................................................................................................................................... 12

11. Document History................................................................................................................................ 15

12. Document Context............................................................................................................................... 15

of 17

3

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

51

52

53

54

55

56

57

58

59

60

4

5


1. Summary FindingsThe Domain Architecture process identified best practices and industry trends. Key findings include:

1.1. Governance 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.

1.2. Education Common terminology helps educate developer teams, architecture teams, operations teams, and IT

business teams.

New skills and training help improve SOA success.

1.3. Creation and Use SOA usage is maturing in public and private sectors. SOA is an application design best practice.

Vendors are SOA-enabling products, which will eventually require agencies and businesses to adopt SOA methods.

Vendors are proposing SOA deployment for custom built or commercial off-the-shelf (COTS) solutions.

1.4. Standards

Identify and adopt mature industry standards and strategies. Evolving standards should be monitored.

Industry standards enable functionality across disparate languages, operating systems and vendors.

Industry standards for Web services cover functions like service discoverability, identification, interoperability, security and more.

1.5. Tools and Technologies

A variety of automated tools and technologies are available to measure usage, monitor performance, and support a standardized environment.

An Enterprise Service Bus (ESB) is not always required, yet commonly used to implement shared services.

1.6. Reuse and Agility

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

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

1.7. 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.

1.8. 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. Document PurposeThe Service-Oriented Architecture (SOA) Domain document provides context for the state’s baseline SOA review. It reviews industry trends needed to evolve the enterprise architecture.

of 17

6

61

62

63

64

65

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

7

8


This document is designed to provide ‘industry best practices’ for Key Issues and Decisions identified within the SOA Initiative Charter. This document assumes the reader is familiar with the Charter, its stated objectives, and the SOA Readiness Awareness Tool focus area questions.

A component of the enterprise architecture (EA) framework, this document provides information needed to bridge the baseline architecture, gap/opportunity analysis, and target architecture. It also provides information and direction for the SOA Conceptual Technical Reference Architecture (SOA-CTRA).

The SOA Domain describes services and design characteristics that support goals and vision of service-oriented computing. Related Information Services Board (ISB)Integration Architecture Standards and Solution sets and User Authentication Standards are at: http://isb.wa.gov/policies/eaprogram.aspx.

3. DescriptionThis document identifies domain-specific principles, business drivers, and environmental trends. It’s expected to support the development of the baseline architecture documentation by providing a high-level overview of public, private, and educational sector SOA trends.

Glossary entries and References are noted in BOLD or identified by (source material). References are typically full source material citations. Full definitions are in the SOA Glossary1 and the following terms are provided to help the reader.

Service-Oriented Architecture (SOA) - SOA is an architectural method or design style that results in and supports shared, reusable services.

Shared Services - Services are discrete applications that are modular, distributable, clearly defined, swappable, and sharable.

4. Business DriversStrategic business direction or priorities and industry responses include:

4.1. Value proposition, operational efficiencies, and cost management

Utah’s SOA-based GovPay service targets its goal to enhance cost savings and cost avoidance through use of Technical Architecture on a statewide basis (Utah).

Common SOA standards can be used to expose services that can be used by applications to augment their functionality, creating linked end to end services supporting an enterprise business process (ARMY-MIL).

Projects that build new business logic or accesses functionality or data from another application or domain can benefit from SOA — or at least from SOA design, which prepares for future SOA-ready enhancements (Forrester).

SOA initiatives should start with a clear understanding of what value each SOA project will target. The focus should be on creating shared services and the governance processes needed sharing services (Gartner).

SOA provides potential value for various business/application processes, yet not all modules should be services. Services should be used strategiclly in application design and nesting should be minimized (Gartner).

To maximize sharing, scope services for the entire enterprise services (Gartner).

SOA should be an application design best practice. It should be considered even if the project does not currently deliver full-blown, network-accessible services. Service-based design prepares for future loosely coupled service delivery (Forrester).

SOA infrastructure such as an Enterprise Service Bus or SOA management solutions can add value by reducing development or ongoing operation costs (Forrester).

Automated tools are available to help measure success and return on investment to track (McClean):

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

of 17

9

104

105

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

146147

148

10

11

12

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


o number of components built; o components deployed; o usage tracking; ando performance monitoring.

Q3 2007 Forrester survey data shows that flexibility leads costs savings as a driver for SOA (Forrester).

4.2. Leverage existing investments

Shared services promote reuse of enterprise resources. Enterprises with a large number of legacy systems can inject new life in these assets by exposing them as services (InfoTech).

SOA can be used when integrating a combination of purchased packages, legacy applications and services from other business units (Gartner).

SOA does not replace Enterprise resource planning (ERP) systems2 but provides the ability to more easily orchestrate cross-functional business processes by improving the integration of ERP and non-ERP systems across a network. This is achieved through “loose coupling” of business functions (services) to the existing ERP systems (ARMY-MIL). See Appendix B: Benefits of SOA - Example ERP Use Case and service illustration diagram.

4.3. Application flexibility, agility, and maintenance

Organizations seek a flexible and agile application environment to meet business needs. SOA enables components to be built around change frequency – separating business logic that is more stable from functions that are exposed to higher frequencies of change (E-SOA).

The SOA model promises a more flexible application architecture that can accommodate new and evolving business processes (ARMY-MIL).

Loose coupling, reuse, and granularity increase the ability for IT applications to respond quickly to changing business needs. Changes in operating regulations or requirements require the IT systems supporting business practices to adapt quickly and cost effectively.

Applications developed within a SOA infrastructure can adapt more rapidly to business changes because of their SOA design—rather than having a change impact the entire application, the functional change may be able to be isolated within a service. The service can be updated rather than the entire application to result in lower costs by leveraging shared services and common infrastructure services.

2 See Appendix C useage scenario

of 17

13

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

14

15

16


5. Environmental TrendsFactors beyond the control of the enterprise organization(s) that will likely impact this domain and industry responses include:

5.1. Increasing need for interoperability among federal, state, local, educational, and private industry systems

Better decision making is based in large part on increased information available to decision makers. This is true in both the public and private arenas. Information needed for good decision making is often located outside of the agency/entity making the decision. This recognition is driving state agencies to make their data easily available to other state agencies and other external stakeholders. One of the most efficient ways to enable this is through the use of published services within a SOA operating environment.

By having data accessible through published services generates at least two positive outcomes. First, the agency having primacy over the data is not constantly having to respond to separate requests for the information through email, phone or other public disclosure request formats. Second, the data that is published to a service is kept current and available to the consumers as soon as it is needed.

5.2. Changes in business and technical delivery channels

Enterprise architectures are adopting Service-Oriented Architecture (SOA) approaches to build shared, reusable services to streamline government operations.

The term ‘shared services’ was largely driven by the desire to lower operating and capital costs, by leveraging economies of scale, standardization and elimination of duplication. Many of the examples are more correctly categorized as "centralized" initiatives; nevertheless, they have pioneered the general approach and demonstrated substantial reductions in overall costs (Gartner),

Vendors are SOA-enabling their products using various techniques, from wrapping to redesign. SOA adoption will become less of an autonomous users' decision.

As new SOA-enabled releases of packaged business applications arrive, users will gradually move to the new versions, mainly to take advantage of add-on application functionalities provided by vendors and their partners. As a result, users will have to adopt their vendors' renditions of SOA principles. Packaged-application vendors' SOA-enabling strategies will have profound implications in terms of packaging, go-to-market, partnership and delivery models (Gartner).

5.3. Smaller budgets, fewer resources, and organizational changes

State’s are required to streamline IT budgets, justify IT spending and increase service delivery and efficiency, and therefore find themselves looking at strategic methods for maintaining current technology systems and upgrading older or legacy systems in a way that both maximizes the state’s business requirements and minimizes risk to the enterprise (NASCIO).

On February 10th, 2009 Governor Gregoire directed executive cabinet agencies to move towards a "shared services" model of delivering many "back office" functions. Information technology was one area in particular that was identified in Governor Directive 09-02. The Governor called for a focus on the use of common IT infrastructure and common services for cost reduction, improved information security and enhanced information management. The current budget crisis is resulting in smaller agency IT budgets and fewer resources for new initiatives into the foreseeable future.

Building new business solutions will not require development of all the necessary software modules from scratch. Reusing common services and existing software modules will allow builds with less cost and less time on new business solutions, yet not all modules should be services (see Section 6.1, Gartner).

of 17

17

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

214

215

216

217

218

219

220

221

222

223

224

18

19


5.4. SOA market and solutions are evolving, yet maturing

Products, vendor strategies, best practices, proposed specifications, and standards for SOA are evolving (Forrester).

SOA will not go the way of earlier architectures. It will continue to affect vendor strategy and IT environments. CIOs and IT managers should start thinking seriously about how SOA will affect their IT environment (McLean).

6. Industry TrendsThis section identifies public, private, and educational industry processes and standards related to enterprise SOA implementations.

This section is intended to provide a high-level, contextual overview of SOA trends. It includes conceptual information to help guide the Target Architecture and Gap/Opportunity Analysis. Selected information will be included in the Conceptual Technical Reference Architecture.

6.1. Public and Private Sector Examples

The use of Service-Oriented Architecture (SOA) is maturing. This trend is seen across public, private, and educational sectors. According to Gartner, SOA adoption in Europe is nearly universal and moderate in North America. In 2007, SOA was used in more than 50% of large, new applications and business processes. It estimates more than 80% of large new systems will use SOA by 2010.

While many organizations are moving toward SOA, some choose not to pursue because of lack of skills and expertise, expected time and expense, and no viable business case.

Gartner recommends:

Not all modules should be services - use services sparingly in application design; Limit service nesting (sub, dependent services) and SOA-style interfaces to minimize complexity

and maximize performance; Service Conditions (see Glossay) help organizations identify and plan for SOA-based services; Federated SOA should be evaluated; Demand full disclosure (metadata) regarding SOA service implementations – avoide designing

SOA applications that will become increasingly complex and nested; and Use "governance" tools to monitor large or complex SOA applications at runtime (service

components);

There are different methods and models for implementing SOA across a multi-organizational enterprise. Examples include:

6.1.1. Private Industry

Synovus Financial - provides commercial and retail banking, as well as investment services, to 35 banks throughout the southeast U.S. Synovus partnered with two other organizations to deliver a new Secure Value Payment (SVP) Program using SOA techniques. Synovus credits its success to SOA's reliance on industry standards, which enables adoption across disparate languages, operating systems and vendors (CIO).

T-Mobile – Designed is SOA architecture into four layers: applications, access, consumption, and support (CIO).

Starwood Hotels and Resorts Worldwide Inc. is replacing its legacy room-reservation system with an SOA-based one. The company, which controls 750 properties around the world, is migrating its reservation and Preferred Guest applications away from a legacy mainfraim system to an SOA-based system (Zdnet).

Verizon’s IT Workbench project that supports SOA design went operational in 2004 and helped the company slash its IT budget by eliminating redundant systems inherited from the merger of Bell Atlantic and GTE, which spawned Verizon (CW).

of 17

20

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

21

22


Citigroup’s SOA governance structure is federated. Its Governance model defines the service portfolio, policies, change management, risk management, and conflict resolution, its Target architecture using a layered approach. The business services layer includes identity management

Citigroup found there was no one-size-fits-all for its SOA governance. Citigroup created a top-down and bottom-up enterprise SOA governance model to manage the lifecycle and definitions of business services, allowing for cross-domain information sharing and transactions.

Motorola has 180 services utilizing an SOA framework. They are refining their SOA architecture with maturing service orchestration, common nomenclature, governance guidelines, and an ROI model. (Zdnet). Public Sector

Federal Government – In June 2008, the Office of Management and Budget (OMB) published the Practical Guide to Federal Service Oriented Architecture (PGFSOA) v1.1. The document provides a and comprehensive roadmap for SOA planning, implementation, and governance. For example, it provides direction for establishing a Service-based Target Architecture (see Apendix C). It recommends adopting a model-based architecture and pattern-based design (PGFSOA, Gartner).

Army - SOA directly supports its vision of enterprise-level processes and services that optimize investment and build enhanced capability portfolios. SOA does not replace ERP systems but provides the ability to more easily orchestrate cross-functional business processes by improving the integration of ERP and non-ERP systems across a network. This is achieved through “loose coupling” of business functions (services) as opposed to the “tightly coupled” ERP approach (ARMY-MIL).

Department of Defense – DOD designed and implemented its SOA roadmap through three parallel efforts: Created blueprints for Target Architecture Solution Sets; Developed SOA test and production environments; and Prototyped and incrementally deployed IT services that leverage existing infrastructure and systems. Successful pilots included technical standards, SOA processes, service registry, and service catalog.

Defense and Veterans Affairs – Plan migrate their electronic health record systems to a service-oriented architecture to enhance the interoperability of outpatient clinical data (GHT).

Arizona – The state is implementing SOA projects designed to streamline state services with common business processes to reduce or eliminate redundancy including:

o Department of Health Services Electronic Verifcation of Vital Events ( EVVE) system will interface with 15 states to verify birth and death records and includes and ESB.

o Arizona Health Care Cost Containment System (AHCCCS) – Health-e Medicaid Health Information Exchange & Electronic Health Record Utility (HIE/HER). The core system was acquired from Massachutes and is in production. Phase one implemented September 2008 and encludes an ESB. Phases II and III will expand the system to private organaztions and hospitals.

of 17

23

271

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

316

317

318

319

320

24

25


Iowa –The State of Iowa SOA Governance Model is based on a hybrid federated model, with a combination of agency-based and centralized IT groups using a shared infrastructure Statewide functions are centralized, Review and governance is shared between the state and agencies; and agencies have some federated responsibilities (IOWA).

o Iowa created a statewide steering committee for communication, project coordination, conflict resolution, priority setting, and resource allocation.

o Funding responsibilities are shared among agencies and its statewide steering committee.

Massachusetts – The Commonwealth of Massachusetts implemented an SOA-based integration solution for its 15 statewide Health and Human Services Organizations (MA, Gartner).

Utah – The state of Utah implemented its GovPay payment processing solution using SOA. GovPay is the state’s online payment handling environment for any Utah Web site that collects payment for services or products. Utah GovPay:

o enables existing applications to accept payments;

o accepts credit cards and/or electronic checks;

o provides a secure environment for accepting payments;

o does not require users to leave the Utah.Gov Web site; and,

o supports reconciliation with the State accounting system by tracking FINET codes per transaction.

Texas - The Texas Health & Human Services Commission is implementing an SOA-based approach to create a common, shared identity management solution (TX-HHSC).

Washington State - completed its identity management initiative in June 2008 that resulted in leveraging and enhancing existing authentication services and future strategy to add SOA-based federated IdM with higher education. The initiative also identified the potential opportunity for a future statewide shared authorization service (ISB-EA).

6.2. SOA Governance Trends

Governance is a set of processes, tools, and organizational structure that allows for oversight of the IT operation and is essential for enterprise SOA (CIO). Governance is needed to ensure that an organization’s SOA program is effectively planned and executed using defined standards, methods

of 17

26

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

27

28


and procedures. Without governance, SOA will be fragmented, and ineffective (NASCIO, InfoTech, Gartner, Forrester).

Integration competency centers (ICC), centers of excellence and other centralized/federated functions are critical to the success of enterprise SOA investments (Gartner).

SOA Governance is needed to oversee IT projects and decisions in order to avoid possible disruption or duplication. Implementing an enterprise service repository and registry to manage services, data types, and descriptions is key. SOA governace teams should represent key stakeholders across IT and business areas (InfoTech).

Service interface design is the single most important factor for getting SOA right. It is the fulcrum of the SOA-based architecture, the center point around which SOA revolves (Forrester).An enterprise service layer can contain Business Activity Monitoring (BAM) technologies that include governance rules to incorporate and assure polices, service level agreements, interfaces

Gartner’s Key Issues for Governance Technologies 2008 report includes:

Registries/repositories, policy management and SOA validation technologies interoperate, integrate and federate to enforce SOA governance strategies.

IT and SOA governance organizations leverage SOA governance technologies to enforce policies.

Vendors provide technologies that help the enforcement of SOA governance strategies.

One of the greatest challenges is managing application logic and data in SOA service components that are spread out over multiple business units (Gartner).

SOA governance includes well-defined and consistently applied processes and policies for service planning, design, development, integration, change, deployment, and operation (Forrester).

SOA requires more investment in IT governance, business process governance and application integration best practices than non-SOA approaches. Moreover, long-standing government policies and business practices in budgeting, procurement, enterprise management, software operation and security can also limit reuse, collaboration and shared services — some of the main benefits that SOA offers (Gartner).

6.3. Funding Trends

Development teams are often reluctant to make its application functionality available as a service if the service consumers don’t share the cost associated with building and supporting the service (Burton).

Find services on funded projects. Even in hard times, solution delivery projects (can) still get funded. Funded projects are the street-level foundation for SOA investments, so assess your portfolio of funded projects to identify which have an opportunity to build or use services (Forrester).

Nearly one-third of the total organizations that are pursuing SOA are using an enterprise service bus (Gartner).

6.4. Education and Awareness

Proliferation of poorly designed, redundant services causes IT chaos that may exceed the costs and complexity of the systems being replaced (Gartner).

New skills are needed. Developers need to learn more than just the wizards. Architecture teams, operations teams, and (IT) business teams all need training and new skills (NASCIO).

According to September 2008 Gartner Group worldwide survey, the top three reasons enterprises aren’t planning to use SOA within the next 12 months are: Lack of internal SOA expertise; No perceived business value; and Lack of skill sets.

of 17

29

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

30

31


7. Domain-Specific PrinciplesThis section defines principles that influence decisions made in this domain. The SOA domain-specific principles are in addition to the state’s over-arching EA principles at: http://isb.wa.gov/committees/enterprise/architecture/overarchingprinciples.doc.

Principles are statements that express what the enterprise values or deems important. The Domain-specific Principles listed below represent the strategic and operational responses to the business drivers, environmental trends, and industry trends identified within this document, and may evolve as the state’s baseline and target architectures are documented

7.1. Planned Services PrincipleSOA-based analysis and design methods should be included early in the planning stages.

Rationale: Shared services promote reuse of government resources, minimize system duplication, and reduce the number of disparate solutions.

Implications: Agencies/entities should review the state’s common enterprise solutions and repositories early in the planning, scoping, and requirements gathering stages of each applicable project. Acquisitions should include language to identify proposed vendor’s capabilities to loosely couple with the state’s current and future shared services. Business process analysts should work with application development teams early in the design process.

7.2. Enterprise Cost Management PrincipleAgencies should leverage the state’s investments.

Rationale: The state has significant investments in applications, infrastructure, education. and has established a state Integration Competency Center (ICC).

Implications: Agencies should leverage and build upon existing state and agency enterprise service infrastructure solutions and applications. Portfolios and repositories should be reviewed before building or buying new applications or components.

7.3. Coordinated SOA Centers of Excellence (COE) PrincipleState and agency SOA COE/Integration Competency Centers (ICC) should communicate, coordinate, and collaborate.

Rationale: Promotes education and reuse. Minimizes duplication, development and maintenance efforts.

Implications: Requires a coordinated set of governance practices, communication, and collaboration. The Department of Information Services manages the state’s ICC and is responsible for provisioning the shared service (using a shared services model, i.e. incorporates a multi-agency governance process for change management.) Individual agencies may form an organizational unit similar to an ICC to support system integration within each agency (ISB EA).

7.4. Neutrality Principle Agency architects should design and implement interfaces between Tier One and Tier Two using technologies that provide for modular, scalable, vendor neutral approaches.

Rationale: Promotes service interface stability, reduces duplication of effort, reduces vendor influence, reduces change control efforts

Implications: Provides for Agencies to utilize the best of breed solutions that best suits their business needs. The state should review standards and strategies required to implement SOA. Some ‘mature’ industry standards may need to be accepted, while others are monitored as they evolve. Reduces or eliminates vendor lock-in, wherein agencies are tied to long term relationships with escalating support and upgrade costs. Allows agencies to tactically implement local solutions that best suit their business needs while participating in a coordinated statewide effort to participate in shared services.

of 17

32

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

33

34

http://isb.wa.gov/committees/enterprise/architecture/overarchingprinciples.doc


7.5. Abstraction Principle Agency architects should provide abstracted service interfaces to Tier One for those services offered from within the Agency’s environment.

Rationale: System platforms and applications will change over time, therefore providing an abstracted, layered, interface that isolates the state from agency changes.

Implications: Assumes a shared Tier One registry of agency services that are available to other agencies through Tier One Assumes a common standard of service interface abstraction. Assumes a long-term Service Level Agreement between agencies and Tier One to provide ongoing support (by the agency) for prior versions of services, until a given service version sunsets at an agreed future date.

8. Associated Enterprise Architecture DisciplinesThe SOA initiative is related to existing and future domains and components of the state’s enterprise architecture.

ISB EA Integration Architecture Standards and Solution Sets; ISB Identity Management User Authentication Standards; and ISB Networking Standards.

9. GlossaryNOTE: THE FOLLOWING TERMS SHOULD BE INCORPORATED INTO THE GLOBAL SOA GLOSSARY:

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.

10. ReferencesARMY-MIL Service Oriented Architecture (SOA) Overview, United States

Army at: http://www.army.mil/armyBTKC/focus/sa/soa.htm

AZ Arizona Service Oriented Architecture (SOA) – Governance, Government Information Technology Agency at: http://www.azgita.gov/soa/governance.htm

CIO SOA Consortium and CIO Magazine Announce Winners of SOA Case Study Competition, CIO (Sep 2008) at: http://www.soa-consortium.org/contest-winners.htm

Security Predictions: Top Three Trends Affecting Enterprise Risk Management, CIO Magazine, Dec 2008

How SOA Really Works, CIO, Aug 2005

Burton Service-Oriented Architecture: Developing the Enterprise Roadmap, Burton Group, Jul 2006

of 17

35

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

36

37


CW Verizon's IT Workbench SOA lets the company use Web services to integrate disparate systems, Computerworld, (Apr 2005)

DOD Progress with SOA and Federated Architecture, Department of Defense, retrieved Jan 2009 at: http://www.defenselink.mil/faq/questions.aspx

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

ERL Service-Oriented Architecture (SOA): Concepts, Technology, and Design, Thomas Erl, July 2005

Gartner Service-Oriented Architecture Overview and Guide to SOA Research, Gartner Group, Jan 2008

2008 SOA User Survey: Adoption Trends and Characteristics, Gartner Group, Jan 2008

Applied SOA: Transforming Fundamental Principles Into Best Practices, Gartner Group, Apr 2007

Key Issues for SOA Governance Technologies, 2008, Gartner, Feb 2008

Findings: Some Organizations Are Sitting on the SOA Sidelines, Gartner, Jun 2008

Five Principles of SOA in Business and IT, Gartner, Feb 2008.

Hype Cycle for Application Architecture, Gartner Group, July 2008

Hype Cycle for Government Transformation, 2008, Gartner, June 2008

Q&A: Is SOA Another 'Meltdown' Waiting to Happen, Gartner, Jan 2008

MA, Gartner Commonwealth of Massachusetts, Executive Office of Health and Human Services, Massimo Pezzini, Gartner (April 2008).

Forrester Building Interoperability and TBD Into Your SOA Platform Strategy, Forrester, Oct 2008

Pursuing SOA In Hard Times, Forrester Research Service, Nov 2008

SOA Comptency Planning and Educational Resources, Forrester, June 2007

The Scope And Focus Of SOA Governance, Forrester, June 2006

Topic Overview: Service-Oriented Architecture, Forrester, June 2008

GHT DOD, Veterans Affairs will use SOA to increase EHR interoperability, Government Health IT, Nov 2008

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

IOWA IT Enterprise Service-Oriented Architecture, SOA Governance Model, Jun 2006

of 17

38

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

522

523

524

525

39

40

http://www.defenselink.mil/faq/questions.aspx


ISB EA Washington State Information Services Board Service Design Standards at: http://isb.wa.gov/policies/eaprogram.aspx

McLean CIO Position the Enterprise for SOA, InfoTech McLean Report, retrieved Jan 2009

SOA Success Depends on Infrastructure Fundamentals, McLean Report, retrieved Jan 2009

MSFT-IAM Microsoft Framework for Identity and Access Management, IAM: Solution Overview,

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

Service Oriented Architecture: an Enabler of the Agile Enterprise, NASCIO, May 2006

State IT Legacy System Modernization: A Tool-kit for Asset Management and Stakeholder Communication, NASCIO, (Mar 2009).

OASIS Reference Architecture for Service Oriented Architecture Version 1.0, OASIS, (Draft 1, Apr 2008)

PGFSOA Practical Guide to Service Oriented Architecture (PGFSOA) v1.1 Federal Chief Information Officers Council (June 2008) at: http://www.whitehouse.gov/omb/e-gov/pgfsoa.aspx

Symantec Symantec Internet Security Threat Report, (March 07)

SGRG SOA Governance Resource Guide, soagovvsource.com, retrieved Jan 2009.

TX-HHSC Identity Management Initiative at Health & Human Services Commission, State of Texas, retrieved Jan 2009

UTAH GovPay System for Online Payment Handling and Web Standards, Utah (2007) at: http://dts.utah.gov/egov/webstandards/resources/utWebStandards051707AD.pdf

Zdnet Starwood moves to SOA, Zdnet, (July 20005)

of 17

41

526

527

528

529

530

531

532

533

534

535

536

537

538

539

540

541

542

543

544

545

546

547

548

549

550

551

552

553

554

555

556

557

42

43

http://dts.utah.gov/egov/webstandards/resources/utWebStandards051707AD.pdf

http://dts.utah.gov/egov/webstandards/resources/utWebStandards051707AD.pdf


11. Document History

Date Version Editor Change

March 13, 2009 1.0 Paul Warren Douglas, Documenter Team, Stewards

Documenter Team initial draft

March 17, 2009 1.1 Documenter Team Edits -Paul Warren Douglas

Revised document based on Mar 16 DT meeting suggestions.

March 24 -31 2009

1.2 EA Committee comments. Documenter Team edits and endorsement -Paul Warren Douglas

Added new Section 1 Summary Findings and DT modified for clarity and readability.

Added nationally recognized private sector examples.

Added more Governance best practices.

Changed title to Documenter Team Endorsed

April 10, 2009 1.2.1 EA Committee commentsPaul Warren Douglas

Summary Findings 1.3 vendor SOA proposed readiness, and 1.4 Web services industry standards

April 15, 2009 2.0 Paul Warren Douglas EA Committee Endorsement

12. Document ContextThis document is within the scope of state’s Enterprise Architecture Service-Oriented Architecture Initiative. The Service-Oriented Architecture (SOA) initiative will define a statewide Enterprise Architecture (EA) to help guide decision-making and implementation of SOA solutions. This document is defined as a deliverable within the Initiative Charter adopted on July 10, 2008 by the Information Services Board (ISB). The charter is available at: http://dis.wa.gov/enterprise/enterprisearch/soa_initiative.aspx

Enterprise Architecture Service Oriented Architecture stewards:

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

Initiative Architects:

Paul Warren Douglas, Department of Information Services Documenter Team

This document has EA Committe Endorsed status. This status signifies the document has been endorsed by the EA Committee. 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.

Appendix A: Documenter TeamThis document was developed through the enterprise architecture Shared Services for SOA initiative, chartered July 10, 2008. The Documenter Team members are listed in the Charter Appendix A at: http://dis.wa.gov/enterprise/enterprisearch/soa_initiative.aspx

of 17

44

558

559

560

561

562

563

564

565

566

567

568

569

570

571

572

573

574

575

576

577

45

46

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

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

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


Appendix B: Benefits of SOA - Example ERP Use Case

Example ERP and SOA services

Diagram and use case from the US Army at: http://www.army.mil/armyBTKC/focus/sa/soa.htm:

Example Use Case:

A COTS Software application processes customer orders by using an ERP application (Service 3). This ERP application does not have the capability to handle credit card transactions but a trust has been established with a Third-Party service (Service 1) that does this quite effectively. This is an example of Service Orchestration: multiple services have joined together to execute a business process.

The SOA design pattern allows for easy re-use of existing functionality in multiple applications. For instance, an entirely new COTS application could be designed to handle membership applications. While this new application would have no need to update the Legacy System database (Service 2), it would require credit card validation and could re-use the “Credit Check” (Service 1) function to achieve this with very little programming.” (ARMY-MIL at: http://www.army.mil/armyBTKC/focus/sa/soa.htm)

of 17

47

578

579

580

581

582

583

584

585

586

587

588

589

590

591

592

48

49

http://www.army.mil/armyBTKC/focus/sa/soa.htm


Appendix C: Example Service-Based Target Architecture

Example Service-Based Target Architecture

Diagram and architectural overview from the Federal Guide for Service Oriented Archtiecture (PGFSOA) at: http://www.whitehouse.gov/omb/e-gov/pgfsoa.aspx

Example Architectural Overview:

According to the PGFSOA, the target architecture should incorporate a layered services architecture. A layered service model is used to define and constrain the dependencies between services and to identify the set of policies that apply to each service layer.

The layered model accommodates the following layers:

1. Underlying Layer used to bring in resource APIs and provide access to legacy systems.

2. Utility Layer for highly reused services (this may include enterprise services provided by a parent service unit).

3. Core Business Services to transform and access business information.

4. Process Services to orchestrate an assembly of lower order services.

5. Solution Layer that includes composite applications.

of 17

50

593

594

595

596

597

598

599

600

601

602

603

604

605

606

607

608

609

610

51

52

http://www.whitehouse.gov/omb/e-gov/pgfsoa.aspx

SOA Domain Architecture (doc)

Documents

Transcript of SOA Domain Architecture (doc)