SOA Domain Architecture (doc)

  • 1,120 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,120
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
106
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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