Download - 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
Page 2 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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.
Page 3 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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.
Page 4 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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
Page 5 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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).
Page 6 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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).
Page 7 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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.
Page 8 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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
Page 9 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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.
Page 10 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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.
Page 11 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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
Page 12 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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
Page 13 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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)
Page 14 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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
Page 15 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
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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)
Page 16 of 17
47
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
48
49
Washington State Enterprise Architecture Program April 15, 2009Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
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.
Page 17 of 17
50
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
51
52