Get documents about "soa_intiative_domain
Document Sample
Contributors:
Bill Kehoe
Department of Licensing
Frank Westrum
Department of Health
Paul Warren Douglas
Department of Information Services
Stephen Backholm
Department of Social and Health
Services
Enterprise
Jerry Britcher
Department of Social and Health Service-Oriented Architecture (SOA)
Services
Gary Dubuque
Domain Document
Department of Revenue
David Jennings EA Committee Endorsed
Department of Health
Version 2.0
JoAnne Kendrick
Department of Information Services
April 15, 2009
Douglas McGregor
Department of Licensing
Noel Morgan
Department of Transportation
Reviewers/Contributors:
Documenter Team
Enterprise Architecture Committee
Stewards
Paul Warren Douglas
Department of Information Services
ISB Enterprise Architecture
Committee Co-Chairs
Frank Westrum, Department of Health
Rob St. John, Department of Social
and Health Services
Paul Warren Douglas, Acting
Enterprise Architect
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
1 Table of Contents
2 1. Summary Findings .................................................................................................................................... 3
3 1.1. Governance ........................................................................................................................................ 3
4 1.2. Education ............................................................................................................................................ 3
5 1.3. Creation and Use................................................................................................................................ 3
6 1.4. Standards ........................................................................................................................................... 3
7 1.5. Tools and Technologies ..................................................................................................................... 3
8 1.6. Reuse and Agility................................................................................................................................ 3
9 1.7. Funding ............................................................................................................................................... 3
10 1.8. Design Risks ....................................................................................................................................... 3
11 2. Document Purpose ................................................................................................................................... 4
12 3. Description ................................................................................................................................................ 4
13 4. Business Drivers ....................................................................................................................................... 4
14 4.1. Value proposition, operational efficiencies, and cost management ................................................... 4
15 4.2. Leverage existing investments ........................................................................................................... 5
16 4.3. Application flexibility, agility, and maintenance .................................................................................. 5
17 5. Environmental Trends ............................................................................................................................... 6
18 5.1. Increasing need for interoperability among federal, state, local, educational, and private industry
19 systems...................................................................................................................................................... 6
20 5.2. Changes in business and technical delivery channels ....................................................................... 6
21 5.3. Smaller budgets, fewer resources, and organizational changes........................................................ 6
22 5.4. SOA market and solutions are evolving, yet maturing ....................................................................... 7
23 6. Industry Trends ......................................................................................................................................... 7
24 6.1. Public and Private Sector Examples .................................................................................................. 7
25 6.2. SOA Governance Trends ................................................................................................................. 10
26 6.3. Funding Trends ................................................................................................................................ 10
27 6.4. Education and Awareness ................................................................................................................ 11
28 7. Domain-Specific Principles ..................................................................................................................... 11
29 7.1. Planned Services Principle ............................................................................................................... 11
30 7.2. Enterprise Cost Management Principle ............................................................................................ 11
31 7.3. Coordinated SOA Centers of Excellence (COE) Principle ............................................................... 11
32 7.4. Neutrality Principle ............................................................................................................................ 12
33 7.5. Abstraction Principle ......................................................................................................................... 12
34 8. Associated Enterprise Architecture Disciplines ...................................................................................... 12
35 9. Glossary .................................................................................................................................................. 12
36 10. References ............................................................................................................................................ 12
37 11. Document History.................................................................................................................................. 15
38 12. Document Context ................................................................................................................................ 15
Page 2 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
39 1. Summary Findings
40 The Domain Architecture process identified best practices and industry trends. Key findings include:
41 1.1. Governance
42 Roles and responsibilities should be clearly defined; key stakeholders represented on governance
43 teams, and Integration Competency Centers should coordinate and communicate.
44 An enterprise service registry/repository is critical for publishing and monitoring services, as well as
45 minimizing duplicate efforts.
46 Change management processes, policies, and service level agreements are required.
47 1.2. Education
48 Common terminology helps educate developer teams, architecture teams, operations teams, and IT
49 business teams.
50 New skills and training help improve SOA success.
51 1.3. Creation and Use
52 SOA usage is maturing in public and private sectors. SOA is an application design best practice.
53 Vendors are SOA-enabling products, which will eventually require agencies and businesses to adopt
54 SOA methods.
55 Vendors are proposing SOA deployment for custom built or commercial off-the-shelf (COTS)
56 solutions.
57 1.4. Standards
58 Identify and adopt mature industry standards and strategies. Evolving standards should be monitored.
59 Industry standards enable functionality across disparate languages, operating systems and vendors.
60 Industry standards for Web services cover functions like service discoverability, identification,
61 interoperability, security and more.
62 1.5. Tools and Technologies
63 A variety of automated tools and technologies are available to measure usage, monitor performance,
64 and support a standardized environment.
65 An Enterprise Service Bus (ESB) is not always required, yet commonly used to implement shared
66 services.
67 1.6. Reuse and Agility
68 SOA can enable the reuse and agile combination of purchased packages, legacy applications, and
69 services.
70 Some Enterprise Resource Planning (ERP) systems are adding shared modular functionality through
71 SOA methods to leverage existing investments.
72 1.7. Funding
73 Identify services on funded projects where possible. SOA strategies should be flexible and adaptable.
74 Shared cost models encourage development teams to make application functionality available.
75 1.8. Design Risks
76 Not all application modules should be services and service nesting (sub-layered, dependent services)
77 is discouraged to minimize complexity.
78 Poorly designed or redundant services lead to higher costs and complexity.
Page 3 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
79 2. Document Purpose
80 The Service-Oriented Architecture (SOA) Domain document provides context for the state‘s baseline SOA
81 review. It reviews industry trends needed to evolve the enterprise architecture.
82 This document is designed to provide ‗industry best practices‘ for Key Issues and Decisions identified
83 within the SOA Initiative Charter. This document assumes the reader is familiar with the Charter, its stated
84 objectives, and the SOA Readiness Awareness Tool focus area questions.
85 A component of the enterprise architecture (EA) framework, this document provides information needed
86 to bridge the baseline architecture, gap/opportunity analysis, and target architecture. It also provides
87 information and direction for the SOA Conceptual Technical Reference Architecture (SOA-CTRA).
88 The SOA Domain describes services and design characteristics that support goals and vision of service-
89 oriented computing. Related Information Services Board (ISB)Integration Architecture Standards and
90 Solution sets and User Authentication Standards are at: http://isb.wa.gov/policies/eaprogram.aspx.
91 3. Description
92 This document identifies domain-specific principles, business drivers, and environmental trends. It‘s
93 expected to support the development of the baseline architecture documentation by providing a high-level
94 overview of public, private, and educational sector SOA trends.
95 Glossary entries and References are noted in BOLD or identified by (source material). References are
1
96 typically full source material citations. Full definitions are in the SOA Glossary and the following terms
97 are provided to help the reader.
98 Service-Oriented Architecture (SOA) - SOA is an architectural method or design style that results in
99 and supports shared, reusable services.
100 Shared Services - Services are discrete applications that are modular, distributable, clearly defined,
101 swappable, and sharable.
102 4. Business Drivers
103 Strategic business direction or priorities and industry responses include:
104 4.1. Value proposition, operational efficiencies, and cost management
105 Utah‘s SOA-based GovPay service targets its goal to enhance cost savings and cost avoidance
106 through use of Technical Architecture on a statewide basis (Utah).
107 Common SOA standards can be used to expose services that can be used by applications to
108 augment their functionality, creating linked end to end services supporting an enterprise business
109 process (ARMY-MIL).
110 Projects that build new business logic or accesses functionality or data from another application or
111 domain can benefit from SOA — or at least from SOA design, which prepares for future SOA-ready
112 enhancements (Forrester).
113 SOA initiatives should start with a clear understanding of what value each SOA project will target.
114 The focus should be on creating shared services and the governance processes needed sharing
115 services (Gartner).
116 SOA provides potential value for various business/application processes, yet not all modules should
117 be services. Services should be used strategiclly in application design and nesting should be
118 minimized (Gartner).
119 To maximize sharing, scope services for the entire enterprise services (Gartner).
1
Draft SOA Initiative Glossary document currently available on SOA Team Site.
Page 4 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
120 SOA should be an application design best practice. It should be considered even if the project does
121 not currently deliver full-blown, network-accessible services. Service-based design prepares for future
122 loosely coupled service delivery (Forrester).
123 SOA infrastructure such as an Enterprise Service Bus or SOA management solutions can add value
124 by reducing development or ongoing operation costs (Forrester).
125
126 Automated tools are available to help measure success and return on investment to track (McClean):
127 o number of components built;
128 o components deployed;
129 o usage tracking; and
130 o performance monitoring.
131 Q3 2007 Forrester survey data shows that flexibility leads costs savings as a driver for SOA
132 (Forrester).
133 4.2. Leverage existing investments
134 Shared services promote reuse of enterprise resources. Enterprises with a large number of legacy
135 systems can inject new life in these assets by exposing them as services (InfoTech).
136 SOA can be used when integrating a combination of purchased packages, legacy applications and
137 services from other business units (Gartner).
2
138 SOA does not replace Enterprise resource planning (ERP) systems but provides the ability to more
139 easily orchestrate cross-functional business processes by improving the integration of ERP and non-
140 ERP systems across a network. This is achieved through ―loose coupling‖ of business functions
141 (services) to the existing ERP systems (ARMY-MIL). See Appendix B: Benefits of SOA - Example
142 ERP Use Case and service illustration diagram.
143
144 4.3. Application flexibility, agility, and maintenance
145 Organizations seek a flexible and agile application environment to meet business needs. SOA
146 enables components to be built around change frequency – separating business logic that is more
147 stable from functions that are exposed to higher frequencies of change (E-SOA).
148 The SOA model promises a more flexible application architecture that can accommodate new and
149 evolving business processes (ARMY-MIL).
2
See Appendix C useage scenario
Page 5 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
150 Loose coupling, reuse, and granularity increase the ability for IT applications to respond quickly to
151 changing business needs. Changes in operating regulations or requirements require the IT systems
152 supporting business practices to adapt quickly and cost effectively.
153 Applications developed within a SOA infrastructure can adapt more rapidly to business changes
154 because of their SOA design—rather than having a change impact the entire application, the
155 functional change may be able to be isolated within a service. The service can be updated rather
156 than the entire application to result in lower costs by leveraging shared services and common
157 infrastructure services.
158 5. Environmental Trends
159 Factors beyond the control of the enterprise organization(s) that will likely impact this domain and industry
160 responses include:
161 5.1. Increasing need for interoperability among federal, state, local, educational,
162 and private industry systems
163 Better decision making is based in large part on increased information available to decision makers.
164 This is true in both the public and private arenas. Information needed for good decision making is
165 often located outside of the agency/entity making the decision. This recognition is driving state
166 agencies to make their data easily available to other state agencies and other external stakeholders.
167 One of the most efficient ways to enable this is through the use of published services within a SOA
168 operating environment.
169 By having data accessible through published services generates at least two positive outcomes.
170 First, the agency having primacy over the data is not constantly having to respond to separate
171 requests for the information through email, phone or other public disclosure request formats. Second,
172 the data that is published to a service is kept current and available to the consumers as soon as it is
173 needed.
174 5.2. Changes in business and technical delivery channels
175 Enterprise architectures are adopting Service-Oriented Architecture (SOA) approaches to build
176 shared, reusable services to streamline government operations.
177 The term ‗shared services‘ was largely driven by the desire to lower operating and capital costs, by
178 leveraging economies of scale, standardization and elimination of duplication. Many of the examples
179 are more correctly categorized as "centralized" initiatives; nevertheless, they have pioneered the
180 general approach and demonstrated substantial reductions in overall costs (Gartner),
181 Vendors are SOA-enabling their products using various techniques, from wrapping to redesign. SOA
182 adoption will become less of an autonomous users' decision.
183 As new SOA-enabled releases of packaged business applications arrive, users will gradually move to
184 the new versions, mainly to take advantage of add-on application functionalities provided by vendors
185 and their partners. As a result, users will have to adopt their vendors' renditions of SOA principles.
186 Packaged-application vendors' SOA-enabling strategies will have profound implications in terms of
187 packaging, go-to-market, partnership and delivery models (Gartner).
188 5.3. Smaller budgets, fewer resources, and organizational changes
189 State‘s are required to streamline IT budgets, justify IT spending and increase service delivery and
190 efficiency, and therefore find themselves looking at strategic methods for maintaining current
191 technology systems and upgrading older or legacy systems in a way that both maximizes the state‘s
192 business requirements and minimizes risk to the enterprise (NASCIO).
193 On February 10th, 2009 Governor Gregoire directed executive cabinet agencies to move towards a
194 "shared services" model of delivering many "back office" functions. Information technology was one
Page 6 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
195 area in particular that was identified in Governor Directive 09-02. The Governor called for a focus on
196 the use of common IT infrastructure and common services for cost reduction, improved information
197 security and enhanced information management. The current budget crisis is resulting in smaller
198 agency IT budgets and fewer resources for new initiatives into the foreseeable future.
199 Building new business solutions will not require development of all the necessary software modules
200 from scratch. Reusing common services and existing software modules will allow builds with less cost
201 and less time on new business solutions, yet not all modules should be services (see Section 6.1,
202 Gartner).
203 5.4. SOA market and solutions are evolving, yet maturing
204 Products, vendor strategies, best practices, proposed specifications, and standards for SOA are
205 evolving (Forrester).
206 SOA will not go the way of earlier architectures. It will continue to affect vendor strategy and IT
207 environments. CIOs and IT managers should start thinking seriously about how SOA will affect their
208 IT environment (McLean).
209 6. Industry Trends
210 This section identifies public, private, and educational industry processes and standards related to
211 enterprise SOA implementations.
212 This section is intended to provide a high-level, contextual overview of SOA trends. It includes conceptual
213 information to help guide the Target Architecture and Gap/Opportunity Analysis. Selected information will
214 be included in the Conceptual Technical Reference Architecture.
215 6.1. Public and Private Sector Examples
216 The use of Service-Oriented Architecture (SOA) is maturing. This trend is seen across public, private, and
217 educational sectors. According to Gartner, SOA adoption in Europe is nearly universal and moderate in
218 North America. In 2007, SOA was used in more than 50% of large, new applications and business
219 processes. It estimates more than 80% of large new systems will use SOA by 2010.
220 While many organizations are moving toward SOA, some choose not to pursue because of lack of skills
221 and expertise, expected time and expense, and no viable business case.
222 Gartner recommends:
223 Not all modules should be services - use services sparingly in application design;
224 Limit service nesting (sub, dependent services) and SOA-style interfaces to minimize complexity
225 and maximize performance;
226 Service Conditions (see Glossay) help organizations identify and plan for SOA-based services;
227 Federated SOA should be evaluated;
228 Demand full disclosure (metadata) regarding SOA service implementations – avoide designing
229 SOA applications that will become increasingly complex and nested; and
230 Use "governance" tools to monitor large or complex SOA applications at runtime (service
231 components);
232 There are different methods and models for implementing SOA across a multi-organizational enterprise.
233 Examples include:
234 6.1.1. Private Industry
235 Synovus Financial - provides commercial and retail banking, as well as investment services, to 35
236 banks throughout the southeast U.S. Synovus partnered with two other organizations to deliver a new
237 Secure Value Payment (SVP) Program using SOA techniques. Synovus credits its success to SOA's
238 reliance on industry standards, which enables adoption across disparate languages, operating
239 systems and vendors (CIO).
Page 7 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
240 T-Mobile – Designed is SOA architecture into four layers: applications, access, consumption, and
241 support (CIO).
242 Starwood Hotels and Resorts Worldwide Inc. is replacing its legacy room-reservation system with an
243 SOA-based one. The company, which controls 750 properties around the world, is migrating its
244 reservation and Preferred Guest applications away from a legacy mainfraim system to an SOA-based
245 system (Zdnet).
246 Verizon‘s IT Workbench project that supports SOA design went operational in 2004 and helped the
247 company slash its IT budget by eliminating redundant systems inherited from the merger of Bell
248 Atlantic and GTE, which spawned Verizon (CW).
249 Citigroup‘s SOA governance structure is federated. Its Governance model defines the service
250 portfolio, policies, change management, risk management, and conflict resolution, its Target
251 architecture using a layered approach. The business services layer includes identity management
252 Citigroup found there was no one-size-fits-all for its SOA governance. Citigroup created a top-down
253 and bottom-up enterprise SOA governance model to manage the lifecycle and definitions of business
254 services, allowing for cross-domain information sharing and transactions.
255 Motorola has 180 services utilizing an SOA framework. They are refining their SOA architecture with
256 maturing service orchestration, common nomenclature, governance guidelines, and an ROI model.
257 (Zdnet). Public Sector
258 Federal Government – In June 2008, the Office of Management and Budget (OMB) published the
259 Practical Guide to Federal Service Oriented Architecture (PGFSOA) v1.1. The document provides a
260 and comprehensive roadmap for SOA planning, implementation, and governance. For example, it
261 provides direction for establishing a Service-based Target Architecture (see Apendix C). It
262 recommends adopting a model-based architecture and pattern-based design (PGFSOA, Gartner).
263 Army - SOA directly
264 supports its vision of
265 enterprise-level
266 processes and
267 services that optimize
268 investment and build
269 enhanced capability
270 portfolios. SOA does
271 not replace ERP
272 systems but provides
273 the ability to more
274 easily orchestrate
275 cross-functional
276 business processes
277 by improving the
278 integration of ERP
279 and non-ERP
280 systems across a
281 network. This is achieved through ―loose coupling‖ of business functions (services) as opposed to the
282 ―tightly coupled‖ ERP approach (ARMY-MIL).
283 Department of Defense – DOD designed and implemented its SOA roadmap through three parallel
284 efforts: Created blueprints for Target Architecture Solution Sets; Developed SOA test and production
285 environments; and Prototyped and incrementally deployed IT services that leverage existing
286 infrastructure and systems. Successful pilots included technical standards, SOA processes, service
287 registry, and service catalog.
288 Defense and Veterans Affairs – Plan migrate their electronic health record systems to a service-
289 oriented architecture to enhance the interoperability of outpatient clinical data (GHT).
Page 8 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
290 Arizona – The state is implementing SOA projects designed to streamline state services with common
291 business processes to reduce or eliminate redundancy including:
292 o Department of Health Services Electronic Verifcation of Vital Events ( EVVE) system will
293 interface with 15 states to verify birth and death records and includes and ESB.
294 o Arizona Health Care Cost Containment System (AHCCCS) – Health-e Medicaid Health
295 Information Exchange & Electronic Health Record Utility (HIE/HER). The core system
296 was acquired from Massachutes and is in production. Phase one implemented
297 September 2008 and encludes an ESB. Phases II and III will expand the system to
298 private organaztions and hospitals.
299 Iowa –The State of Iowa SOA Governance Model is based on a hybrid federated model, with a
300 combination of agency-based and centralized IT groups using a shared infrastructure Statewide
301 functions are centralized, Review and governance is shared between the state and agencies; and
302 agencies have some federated responsibilities (IOWA).
303 o Iowa created a statewide steering committee for communication, project coordination,
304 conflict resolution, priority setting, and resource allocation.
305 o Funding responsibilities are shared among agencies and its statewide steering
306 committee.
307 Massachusetts – The Commonwealth of Massachusetts implemented an SOA-based integration
308 solution for its 15 statewide Health and Human Services Organizations (MA, Gartner).
309 Utah – The state of Utah implemented its GovPay payment processing solution using SOA. GovPay
310 is the state‘s online payment handling environment for any Utah Web site that collects payment for
311 services or products. Utah GovPay:
312 o enables existing applications to accept payments;
313 o accepts credit cards and/or electronic checks;
314 o provides a secure environment for accepting payments;
315 o does not require users to leave the Utah.Gov Web site; and,
316 o supports reconciliation with the State accounting system by tracking FINET codes per
317 transaction.
Page 9 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
318 Texas - The Texas Health & Human Services Commission is implementing an SOA-based approach
319 to create a common, shared identity management solution (TX-HHSC).
320 Washington State - completed its identity management initiative in June 2008 that resulted in
321 leveraging and enhancing existing authentication services and future strategy to add SOA-based
322 federated IdM with higher education. The initiative also identified the potential opportunity for a future
323 statewide shared authorization service (ISB-EA).
324 6.2. SOA Governance Trends
325 Governance is a set of processes, tools, and organizational structure that allows for oversight of the
326 IT operation and is essential for enterprise SOA (CIO). Governance is needed to ensure that an
327 organization‘s SOA program is effectively planned and executed using defined standards, methods
328 and procedures. Without governance, SOA will be fragmented, and ineffective (NASCIO, InfoTech,
329 Gartner, Forrester).
330 Integration competency centers (ICC), centers of excellence and other centralized/federated functions
331 are critical to the success of enterprise SOA investments (Gartner).
332 SOA Governance is needed to oversee IT projects and decisions in order to avoid possible disruption
333 or duplication. Implementing an enterprise service repository and registry to manage services, data
334 types, and descriptions is key. SOA governace teams should represent key stakeholders across IT
335 and business areas (InfoTech).
336 Service interface design is the single most important factor for getting SOA right. It is the fulcrum of
337 the SOA-based architecture, the center point around which SOA revolves (Forrester).An enterprise
338 service layer can contain Business Activity Monitoring (BAM) technologies that include governance
339 rules to incorporate and assure polices, service level agreements, interfaces
340 Gartner‘s Key Issues for Governance Technologies 2008 report includes:
341 Registries/repositories, policy management and SOA validation technologies interoperate,
342 integrate and federate to enforce SOA governance strategies.
343 IT and SOA governance organizations leverage SOA governance technologies to enforce
344 policies.
345 Vendors provide technologies that help the enforcement of SOA governance strategies.
346 One of the greatest challenges is managing application logic and data in SOA service components
347 that are spread out over multiple business units (Gartner).
348 SOA governance includes well-defined and consistently applied processes and policies for service
349 planning, design, development, integration, change, deployment, and operation (Forrester).
350 SOA requires more investment in IT governance, business process governance and application
351 integration best practices than non-SOA approaches. Moreover, long-standing government policies
352 and business practices in budgeting, procurement, enterprise management, software operation and
353 security can also limit reuse, collaboration and shared services — some of the main benefits that
354 SOA offers (Gartner).
355 6.3. Funding Trends
356 Development teams are often reluctant to make its application functionality available as a service if
357 the service consumers don‘t share the cost associated with building and supporting the service
358 (Burton).
359 Find services on funded projects. Even in hard times, solution delivery projects (can) still get funded.
360 Funded projects are the street-level foundation for SOA investments, so assess your portfolio of
361 funded projects to identify which have an opportunity to build or use services (Forrester).
362 Nearly one-third of the total organizations that are pursuing SOA are using an enterprise service bus
363 (Gartner).
Page 10 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
364 6.4. Education and Awareness
365 Proliferation of poorly designed, redundant services causes IT chaos that may exceed the costs and
366 complexity of the systems being replaced (Gartner).
367 New skills are needed. Developers need to learn more than just the wizards. Architecture teams,
368 operations teams, and (IT) business teams all need training and new skills (NASCIO).
369 According to September 2008 Gartner Group worldwide survey, the top three reasons enterprises
370 aren‘t planning to use SOA within the next 12 months are: Lack of internal SOA expertise; No
371 perceived business value; and Lack of skill sets.
372 7. Domain-Specific Principles
373 This section defines principles that influence decisions made in this domain. The SOA domain-specific
374 principles are in addition to the state‘s over-arching EA principles at:
375 http://isb.wa.gov/committees/enterprise/architecture/overarchingprinciples.doc.
376 Principles are statements that express what the enterprise values or deems important. The Domain-
377 specific Principles listed below represent the strategic and operational responses to the business drivers,
378 environmental trends, and industry trends identified within this document, and may evolve as the state‘s
379 baseline and target architectures are documented
380 7.1. Planned Services Principle
381 SOA-based analysis and design methods should be included early in the planning stages.
382 Rationale: Shared services promote reuse of government resources, minimize system duplication, and
383 reduce the number of disparate solutions.
384 Implications: Agencies/entities should review the state‘s common enterprise solutions and repositories
385 early in the planning, scoping, and requirements gathering stages of each applicable project. Acquisitions
386 should include language to identify proposed vendor‘s capabilities to loosely couple with the state‘s
387 current and future shared services. Business process analysts should work with application development
388 teams early in the design process.
389 7.2. Enterprise Cost Management Principle
390 Agencies should leverage the state’s investments.
391 Rationale: The state has significant investments in applications, infrastructure, education. and has
392 established a state Integration Competency Center (ICC).
393 Implications: Agencies should leverage and build upon existing state and agency enterprise service
394 infrastructure solutions and applications. Portfolios and repositories should be reviewed before building or
395 buying new applications or components.
396 7.3. Coordinated SOA Centers of Excellence (COE) Principle
397 State and agency SOA COE/Integration Competency Centers (ICC) should communicate,
398 coordinate, and collaborate.
399 Rationale: Promotes education and reuse. Minimizes duplication, development and maintenance efforts.
400 Implications: Requires a coordinated set of governance practices, communication, and collaboration. The
401 Department of Information Services manages the state‘s ICC and is responsible for provisioning the
402 shared service (using a shared services model, i.e. incorporates a multi-agency governance process for
403 change management.) Individual agencies may form an organizational unit similar to an ICC to support
404 system integration within each agency (ISB EA).
Page 11 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
405 7.4. Neutrality Principle
406 Agency architects should design and implement interfaces between Tier One and Tier Two
407 using technologies that provide for modular, scalable, vendor neutral approaches.
408 Rationale: Promotes service interface stability, reduces duplication of effort, reduces vendor influence,
409 reduces change control efforts
410 Implications: Provides for Agencies to utilize the best of breed solutions that best suits their business
411 needs. The state should review standards and strategies required to implement SOA. Some ‗mature‘
412 industry standards may need to be accepted, while others are monitored as they evolve. Reduces or
413 eliminates vendor lock-in, wherein agencies are tied to long term relationships with escalating support
414 and upgrade costs. Allows agencies to tactically implement local solutions that best suit their business
415 needs while participating in a coordinated statewide effort to participate in shared services.
416 7.5. Abstraction Principle
417 Agency architects should provide abstracted service interfaces to Tier One for those services
418 offered from within the Agency’s environment.
419 Rationale: System platforms and applications will change over time, therefore providing an abstracted,
420 layered, interface that isolates the state from agency changes.
421 Implications: Assumes a shared Tier One registry of agency services that are available to other agencies
422 through Tier One Assumes a common standard of service interface abstraction. Assumes a long-term
423 Service Level Agreement between agencies and Tier One to provide ongoing support (by the agency) for
424 prior versions of services, until a given service version sunsets at an agreed future date.
425 8. Associated Enterprise Architecture Disciplines
426 The SOA initiative is related to existing and future domains and components of the state‘s enterprise
427 architecture.
428 ISB EA Integration Architecture Standards and Solution Sets; ISB Identity Management User
429 Authentication Standards; and ISB Networking Standards.
430 9. Glossary
431 NOTE: THE FOLLOWING TERMS SHOULD BE INCORPORATED INTO THE GLOBAL SOA GLOSSARY:
432 SERVICE CONDITIONS Service-oriented architecture (SOA) is a style of application
433 architecture. According to Gartner, an application is SOA-based
434 service when it meets these five conditions:
435 1. It is modular.
436 2. The modules are distributable.
437 3. Software developers write or generate interface metadata that
438 specifies an explicit contract so that another developer can find
439 and use the service.
440 4. The interface of a service is separate from the implementation
441 (code and data) of the service provider.
442 5. The service is shareable — that is, designed and deployed in
443 a manner that enables them to be invoked successively by
444 disparate consumers.
445 10. References
446 ARMY-MIL Service Oriented Architecture (SOA) Overview, United States
447 Army at: http://www.army.mil/armyBTKC/focus/sa/soa.htm
Page 12 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
448 AZ Arizona Service Oriented Architecture (SOA) – Governance,
449 Government Information Technology Agency at:
450 http://www.azgita.gov/soa/governance.htm
451 CIO SOA Consortium and CIO Magazine Announce Winners of SOA
452 Case Study Competition, CIO (Sep 2008) at: http://www.soa-
453 consortium.org/contest-winners.htm
454 Security Predictions: Top Three Trends Affecting Enterprise Risk
455 Management, CIO Magazine, Dec 2008
456 How SOA Really Works, CIO, Aug 2005
457 Burton Service-Oriented Architecture: Developing the Enterprise
458 Roadmap, Burton Group, Jul 2006
459 CW Verizon's IT Workbench SOA lets the company use Web
460 services to integrate disparate systems, Computerworld, (Apr
461 2005)
462 DOD Progress with SOA and Federated Architecture, Department of
463 Defense, retrieved Jan 2009 at:
464 http://www.defenselink.mil/faq/questions.aspx
465 E-SOA Enterprise SOA, Service-Oriented Architecture Best Practices,
466 Krafzig, Banke, Slama, 2005
467 ERL Service-Oriented Architecture (SOA): Concepts, Technology,
468 and Design, Thomas Erl, July 2005
469 Gartner Service-Oriented Architecture Overview and Guide to SOA
470 Research, Gartner Group, Jan 2008
471 2008 SOA User Survey: Adoption Trends and Characteristics,
472 Gartner Group, Jan 2008
473 Applied SOA: Transforming Fundamental Principles Into Best
474 Practices, Gartner Group, Apr 2007
475 Key Issues for SOA Governance Technologies, 2008, Gartner,
476 Feb 2008
477 Findings: Some Organizations Are Sitting on the SOA Sidelines,
478 Gartner, Jun 2008
479 Five Principles of SOA in Business and IT, Gartner, Feb 2008.
480 Hype Cycle for Application Architecture, Gartner Group, July
481 2008
482 Hype Cycle for Government Transformation, 2008, Gartner, June
483 2008
484 Q&A: Is SOA Another 'Meltdown' Waiting to Happen, Gartner,
485 Jan 2008
486 MA, Gartner Commonwealth of Massachusetts, Executive Office of Health
487 and Human Services, Massimo Pezzini, Gartner (April 2008).
488 Forrester Building Interoperability and TBD Into Your SOA Platform
489 Strategy, Forrester, Oct 2008
490 Pursuing SOA In Hard Times, Forrester Research Service, Nov
491 2008
492 SOA Comptency Planning and Educational Resources,
493 Forrester, June 2007
Page 13 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
494 The Scope And Focus Of SOA Governance, Forrester, June
495 2006
496 Topic Overview: Service-Oriented Architecture, Forrester, June
497 2008
498 GHT DOD, Veterans Affairs will use SOA to increase EHR
499 interoperability, Government Health IT, Nov 2008
500 InfoTech Strategy & Planning, Set the Stage for SOA Governance, Dec
501 2008
502 IOWA IT Enterprise Service-Oriented Architecture, SOA Governance
503 Model, Jun 2006
504 ISB EA Washington State Information Services Board Service Design
505 Standards at: http://isb.wa.gov/policies/eaprogram.aspx
506 McLean CIO Position the Enterprise for SOA, InfoTech McLean Report,
507 retrieved Jan 2009
508 SOA Success Depends on Infrastructure Fundamentals, McLean
509 Report, retrieved Jan 2009
510 MSFT-IAM Microsoft Framework for Identity and Access Management, IAM:
511 Solution Overview,
512 NASCIO National Association of Chief Information Officers, Enterprise
513 Architecture Tool Kit v 3, October 2003
514 Service Oriented Architecture: an Enabler of the Agile
515 Enterprise, NASCIO, May 2006
516 State IT Legacy System Modernization: A Tool-kit for Asset
517 Management and Stakeholder Communication, NASCIO, (Mar
518 2009).
519 OASIS Reference Architecture for Service Oriented Architecture Version
520 1.0, OASIS, (Draft 1, Apr 2008)
521 PGFSOA Practical Guide to Service Oriented Architecture (PGFSOA) v1.1
522 Federal Chief Information Officers Council (June 2008) at:
523 http://www.whitehouse.gov/omb/e-gov/pgfsoa.aspx
524 Symantec Symantec Internet Security Threat Report, (March 07)
525 SGRG SOA Governance Resource Guide, soagovvsource.com,
526 retrieved Jan 2009.
527 TX-HHSC Identity Management Initiative at Health & Human Services
528 Commission, State of Texas, retrieved Jan 2009
529 UTAH GovPay System for Online Payment Handling and Web
530 Standards, Utah (2007) at:
531 http://dts.utah.gov/egov/webstandards/resources/utWebStandard
532 s051707AD.pdf
533 Zdnet Starwood moves to SOA, Zdnet, (July 20005)
534
535
536
Page 14 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
537 11. Document History
Date Version Editor Change
March 13, 2009 1.0 Paul Warren Douglas, Documenter Team initial draft
Documenter Team,
Stewards
March 17, 2009 1.1 Documenter Team Edits - Revised document based on Mar 16
Paul Warren Douglas DT meeting suggestions.
March 24 -31 1.2 EA Committee comments. Added new Section 1 Summary
2009 Documenter Team edits Findings and DT modified for clarity
and endorsement - and readability.
Paul Warren Douglas
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 comments Summary Findings 1.3 vendor SOA
Paul Warren Douglas proposed readiness, and 1.4 Web
services industry standards
April 15, 2009 2.0 Paul Warren Douglas EA Committee Endorsement
538 12. Document Context
539 This document is within the scope of state‘s Enterprise Architecture Service-Oriented Architecture
540 Initiative. The Service-Oriented Architecture (SOA) initiative will define a statewide Enterprise Architecture
541 (EA) to help guide decision-making and implementation of SOA solutions. This document is defined as a
542 deliverable within the Initiative Charter adopted on July 10, 2008 by the Information Services Board (ISB).
543 The charter is available at: http://dis.wa.gov/enterprise/enterprisearch/soa_initiative.aspx
544 Enterprise Architecture Service Oriented Architecture stewards:
545 Bill Kehoe, Department of Licensing
546 Frank Westrum, Department of Health
547 Initiative Architects:
548 Paul Warren Douglas, Department of Information Services
549 Documenter Team
550 This document has EA Committe Endorsed status. This status signifies the document has been endorsed
551 by the EA Committee. For more information about the ISB Enterprise Architecture Committee and its
552 initiative, please visit the EA Committee website at: http://isb.wa.gov/committees/enterprise/index.aspx.
553 Appendix A: Documenter Team
554 This document was developed through the enterprise architecture Shared Services for SOA initiative,
555 chartered July 10, 2008. The Documenter Team members are listed in the Charter Appendix A at:
556 http://dis.wa.gov/enterprise/enterprisearch/soa_initiative.aspx
557
Page 15 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
558 Appendix B: Benefits of SOA - Example ERP Use Case
559
560 Example ERP and SOA services
561 Diagram and use case from the US Army at: http://www.army.mil/armyBTKC/focus/sa/soa.htm:
562 Example Use Case:
563 A COTS Software application processes customer orders by using an ERP application (Service 3). This
564 ERP application does not have the capability to handle credit card transactions but a trust has been
565 established with a Third-Party service (Service 1) that does this quite effectively. This is an example of
566 Service Orchestration: multiple services have joined together to execute a business process.
567 The SOA design pattern allows for easy re-use of existing functionality in multiple applications. For
568 instance, an entirely new COTS application could be designed to handle membership applications. While
569 this new application would have no need to update the Legacy System database (Service 2), it would
570 require credit card validation and could re-use the ―Credit Check‖ (Service 1) function to achieve this with
571 very little programming.‖ (ARMY-MIL at: http://www.army.mil/armyBTKC/focus/sa/soa.htm)
572
573
Page 16 of 17
Washington State Enterprise Architecture Program April 15, 2009
Enterprise Service-Oriented Architecture (SOA) Domain Document EA Committee Endorsed Version 2.0
574 Appendix C: Example Service-Based Target Architecture
575
576 Example Service-Based Target Architecture
577 Diagram and architectural overview from the Federal Guide for Service Oriented Archtiecture (PGFSOA)
578 at: http://www.whitehouse.gov/omb/e-gov/pgfsoa.aspx
579 Example Architectural Overview:
580 According to the PGFSOA, the target architecture should incorporate a layered services architecture. A
581 layered service model is used to define and constrain the dependencies between services and to identify
582 the set of policies that apply to each service layer.
583 The layered model accommodates the following layers:
584 1. Underlying Layer used to bring in resource APIs and provide access to legacy systems.
585 2. Utility Layer for highly reused services (this may include enterprise services provided by a parent
586 service unit).
587 3. Core Business Services to transform and access business information.
588 4. Process Services to orchestrate an assembly of lower order services.
589 5. Solution Layer that includes composite applications.
590
591
Page 17 of 17
