Your SlideShare is downloading. ×
1


                    Primary Contributors:2

                               Bill Kehoe3
                  Department of...
2Washington State Enterprise Architecture Program           September 17, 2008
 3State Enterprise Service-Oriented Archite...
6




35            1.Document History
      Date                      Version    Editor                 Change


      Ju...
8




61          4.Introduction
62The  state of Washington places a high-priority on Government accountability and effici...
10




 99For  example, the opportunity may exist for a common, shared, reusable central service for credit
100card  servi...
12




137    and support for agencies that want to move in the direction of SOA but do not understand
138    how to get s...
14




175   Identify program requirements to assist in education, identification, creation, and use
176   of shared servi...
16Washington State Enterprise Architecture Program           September 17, 2008
 17State Enterprise Service-Oriented Archi...
21Washington State Enterprise Architecture Program           September 17, 2008
 22State Enterprise Service-Oriented Archi...
26Washington State Enterprise Architecture Program        September 17, 2008
 27State Enterprise Service-Oriented Architec...
Upcoming SlideShare
Loading in...5
×

SOA Business Case (doc)

647

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
647
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
61
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "SOA Business Case (doc)"

  1. 1. 1 Primary Contributors:2 Bill Kehoe3 Department of Licensing 4 Frank Westrum5 Department of Health 6 Christy Ridout Department of Labor & Industries7 Paul Warren Douglas 8 Department of Information Services 9 State Enterprise Service-Oriented Stewards/Contributors: 10 Architecture (SOA) Business Case 11 Reviewers: 12 EA Committee Endorsed Documenter Team 13 Enterprise Architecture Committee Version 2.1 14 15 September 17, 2008 16 17 Information Services Board Enterprise Architecture Committee Bill Kehoe, Department of Licensing Frank Westrum, Department of Health Co-Chairs Paul Warren Douglas, Acting Enterprise Architect 1
  2. 2. 2Washington State Enterprise Architecture Program September 17, 2008 3State Enterprise Service-Oriented Architecture (SOA) Business Case EA Committee Endorsed—Version 2.1 4 18Table of Contents 191. Document History.......................................................................................................................3 202. Document Context......................................................................................................................3 213. Document Purpose.....................................................................................................................3 224. Introduction.................................................................................................................................4 235. Business Benefits.......................................................................................................................4 246. Recommended Solution and Alternatives Considered................................................................5 25 6.1. Alternative One:..................................................................................................................5 26 Do not proceed with the SOA Initiative as a Tier One Enterprise Initiative............................5 27 6.2. Alternative Two:..................................................................................................................5 28 Proceed with the SOA Initiative as a Tier One Enterprise Initiative........................................5 29 6.3. Alternative Three:................................................................................................................6 30 Delay moving forward with the SOA Initiative and a Tier One Enterprise Initiative...............6 317. Recommendation........................................................................................................................6 328. Glossary......................................................................................................................................8 339. References.................................................................................................................................9 34 5 Page 2 of 10
  3. 3. 6 35 1.Document History Date Version Editor Change June 18, 2008 1.0 Ed Tolentino Initial Draft September 15, 2008 2.0 Bill Kehoe Revised document September 17, 2008 2.1 Paul Warren Douglas EA Committee edits and Endorsement 36 2.Document Context 37This document is within the scope of state’s Enterprise Architecture Identity Management 38Initiative. The Service-Oriented Architecture (SOA) initiative will define a statewide Enterprise 39Architecture (EA) to help guide decision-making and implementation of SOA solutions. This 40document is defined as a deliverable within the Initiative Charter adopted on July 10, 2008 by the 41Information Services Board (ISB). The charter is available at: 42http://dis.wa.gov/enterprise/enterprisearch/soa_initiative.aspx 43Enterprise Architecture Service Oriented Architecture stewards: 44• Bill Kehoe, Department of Licensing 45• Christy Ridout, Department of Labor and Industries 46• Frank Westrum, Department of Health 47Initiative Architect: 48• Paul Warren-Douglas, Department of Information Services 49This document has EA Committee Endorsed status. This status signifies the document has been 50endorsed by the EA Committee. For more information about the ISB Enterprise Architecture 51Committee and its initiative, please visit the EA Committee website at: 52http://isb.wa.gov/committees/enterprise/index.aspx. 53 3.Document Purpose 54This purpose of this document is to provide the business case for a statewide enterprise SOA 55initiative. 56This document can be used to: 57 • Provide increased understanding of the objectives and purpose of the Enterprise 58 Architecture Committee SOA initiative 59 • Identify the business proposition and business value of SOA as an enterprise initiative 60 within the State of Washington. 7
  4. 4. 8 61 4.Introduction 62The state of Washington places a high-priority on Government accountability and efficiencies in 63services. Government services need to be provided from the perspective of a cohesive, single 64state enterprise. Service Oriented Architecture will enable the goals and strategies identified in 65the ISB approved State Strategic IT Plan (see Appendix D.) 66Agency business programs provide secure and reliable services statewide, while various types of 67applications and technical infrastructure ensure 24/7 delivery of those government services. The 68systems are built using a variety of technologies and platforms, and parts of these systems 69perform similar functions. 70The opportunity exists to identify the similar business functions or ‘services’ within the enterprise 71which could be consolidated into a single service or services that more than one agency can 72share to increase efficiency, improve business agility, and reduce organizational complexity. 73 5.Business Benefits 74SERVICE-ORIENTEDARCHITECTURE (SOA) separates the business, applications, and technology into 75loosely coupled ‘service’ layers, so that similar functions can be provided as common, shared 76SERVICES, and made available as reusable building blocks. 77COST EFFICIENCIES – Lower maintenance cost resulting from transformed business processes from 78siloed, replicated processes into highly leveraged, common shared services. If agencies can 79access a shared service, the savings in development, on-going maintenance, licenses, testing, 80and training is substantial in comparison to having individual agencies develop the same service. 81As the state develops more common services, agency implementations should be accelerated as 82they utilize more and more common, shared services. 83BUSINESS EFFECTIVENESS – The foundation of SOA is business processes and defining those 84common business processes that can be shared. SOA develops common services based on 85business processes that can be shared and standardized by one or more entities. SOA is 86centered on the identification, streamlining, and increased efficiency of business processes 87creating savings in staff time and improving customer service. 88EDUCATION / TRAINING – The complexity of training on a common, shared service is greatly reduced 89versus the education and training associated with multiple services in multiple agencies. Areas 90such as contract management, auditing, reporting, reconciliation are all reduced with a common, 91shared service. 92REDUCE BUSINESS RISK - SOA improves security due to the application of standard security 93principles, reduces on-going maintenance, and can provide for business continuity and disaster 94recovery based on the need to the customers accessing the service. 95For example, today multiple state and local governments accept credit cards over the counter, 96phone, and via the Internet. Each agency has contacted with a service provider and has built an 97interface from their service delivery channels to their provider. Each agency is also required to 98provide the on-going maintenance, and licensing associated with the service. 9
  5. 5. 10 99For example, the opportunity may exist for a common, shared, reusable central service for credit 100card services - build it once. The value to the state as an enterprise is contained in the savings 101for each agency in the development, maintenance, enhancements costs. 102 6.Recommended Solution and Alternatives Considered 1036.1.Alternative One: 104Do not proceed with the SOA Initiative as a Tier One Enterprise Initiative 105• The rationale for not proceeding with a statewide SOA program and the identification and 106 development of common Tier One services is that the SOA program would not provide the 107 state efficiencies and benefits that is assumed and that individual agency efforts should stand 108 alone. 109• This implication of doing nothing is that the state would not take advantage of SOA best 110 practices being developed in individual agencies and at the national level. This would 111 prevent the state as an enterprise from capitalizing and realizing the benefits of services that 112 individual agencies have developed that could be of great benefit to the state. This 113 alternative does not address the need for the state to get in step with Washington State 114 agencies and federal efforts to develop and integrate SOA best practices into their business 115 improvement and application development environment. 116• As agencies mature in their individual development of SOA-based services, the opportunity 117 for the state to miss the opportunity to provide all agencies common, shared enterprise 118 services is great. 1196.2.Alternative Two: 120Proceed with the SOA Initiative as a Tier One Enterprise Initiative 121• The Enterprise Architecture Committee charter has been approved by the ISB and the 122 initiative can proceed with the remaining phases of the methodology. A documenter team 123 has been formed consisting of SOA subject matter experts within the various state agencies. 124 The next phases of the EAC architectural framework call for a “discovery” within the context 125 of a domain document that will examine the SAO programs at the state and national level to 126 determine the “as is” state of SOA. The documenter team will also perform a readiness 127 assessment as described in the SOA initiative charter, to determine the where the potential 128 gaps are in the ability of the state as an enterprise to move forward with SOA. 129• By moving forward with the SOA Initiative the EAC, ISB, and the documenter team will 130 become more informed about the potential of developing a Tier One SOA program and the 131 other objectives that are outlined in the SOA Initiative Charter. Key questions to be answered 132 will also be addressed by the documenter team as they proceed through the methodology. 133• The state as an enterprise needs to understand the potential value of SOA and look to 134 develop SOA governance and a framework for the identification of Tier One common, shared 135 services. This would ensure that the state is taking advantage of the work within the 136 individual agencies in their development of common services and also providing guidance 11
  6. 6. 12 137 and support for agencies that want to move in the direction of SOA but do not understand 138 how to get started. 1396.3.Alternative Three: 140Delay moving forward with the SOA Initiative and a Tier One Enterprise Initiative 141• This alternative would put the SOA initiative on hold until a later date when the committee 142 feels that it is the right time to move forward and the resources are available from a 143 committee and agency resource perspective. 144• The rationale would be that the state is not ready to move forward with SOA and that the 145 committee should allow SOA to mature within the agencies that are moving forward with the 146 initiative before looking to a statewide program development and developing criteria for 147 common enterprise shared services. 148• The implication is that the state would fall behind the activity of the individual agencies and 149 that individual solution, governance, and standards would be developed outside of a 150 statewide view. Request for Proposals for major systems, current state projects, and the IT 151 Strategic plan are all calling for SOA principle solutions based on loosely coupled common 152 services. 153 7.Recommendation 154• The recommendation is that the EAC committee proceeds with alternative 2 which are to 155 move forward with the SOA initiative and reconvene the documenter team. This would allow 156 the subject matter experts in the state to come together and review the current state of SOA 157 initiatives within the state and federal government and make recommendations to the 158 committee concerning how and if the state as an enterprise should move forward with SOA. 159• If the objectives of the initiative are realized, individual state agencies can choose to take 160 advantage of the common, shared services or move in another direction. The intent is to 161 move the state forward with SOA and develop a program, framework, and reference 162 architecture to provide opportunities for the state and agencies to realize the benefits of 163 common, shared services. The initiative will look for an opportunity to identify, refine, or build 164 a common Tier 1 SOA-based shared service to validate the framework, and propose as a 165 state ISB standard. 166• By moving forward, the SOA Initiative would pursue the following objectives that are listed in 167 the SOA Initiative Charter. These objectives are explained in greater detail for better 168 understanding by the committee. 169Objectives: 170 Develop a Tier One enterprise SOA strategy: As individual agencies are developing SOA 171 strategies and programs it is critical that the state as an enterprise develop a Tier One 172 (enterprise) SOA strategy. The absence of a statewide strategy would leave the state in a 173 position where it would not be able to develop or fully take advantage of common services 174 that could be shared with one or more state agencies. 13
  7. 7. 14 175 Identify program requirements to assist in education, identification, creation, and use 176 of shared services: The state, as an enterprise, needs a program that can assist agencies in 177 the development of shared services and SOA principles and governance. The program 178 would develop best practices leveraging existing state and federal best practices, and criteria 179 for the identification and development of Tier One common services. This program and the 180 resources within the program would be defined as part of the SOA initiative deliverables. 181 However, possible resources associated with the program would consist of subject matter 182 experts from various agencies. 183 Identify and refine policies and standards for SOA planning and governance: As the 184 initiative is evaluating existing federal and state SOA programs, policies and standards for 185 SOA planning and governance will be brought forward to the enterprise level. The enterprise 186 SOA program will need governance standards for the identification, development, 187 documentation, storage, and implementation of shared services. 188 Create decision-making framework to manage SOA services: A framework is necessary 189 to manage Tier One shared services once they are identified and in use. This framework 190 would define a repository for the shared services, service level agreements and other critical 191 information and requirements to properly manage the SOA-based services. 192 Develop reference architecture to help guide service design and deployment: As the 193 enterprise program and individual agencies identify common services, reference architecture 194 is required complete with architectural templates for shared service design and deployment at 195 the enterprise level. 15
  8. 8. 16Washington State Enterprise Architecture Program September 17, 2008 17State Enterprise Service-Oriented Architecture (SOA) Business Case EA Committee Endorsed Version 2.1 18 196 8.Glossary 197SERVICES Self-contained, reusable software modules that are independent 198 of the computing platforms on which they run. Services allow a 199 one-to-one (1:1) mapping between business tasks and the exact 200 IT components needed to execute the task. Services can be 201 shared, and can be combined, to form complete business 202 solutions. 203 A SOA service used by more than one business solution. 204 “Shared” services are often classified by scope or range of 205 influence. “Enterprise” services are shared across many 206 business domains. “Domain” services are shared within a single 207 business domain. “Local” services are typically confined to a 208 single business solution 209SERVICE-ORIENTED ARCHITECTURE A Service Oriented Architecture (hereafter called SOA) is an 210 architectural framework designed to offer common services, in 211 an agreed upon, consistent fashion, to reduce duplication of 212 effort across an enterprise. 213 It is one tenet of organizational transformation and IT 214 management focused on a long-term view blueprint (with a plan) 215 that describes the transitioning from current and desired 216 operational state. SOA unifies business processes through the 217 use of service encapsulation, loose coupling, abstraction, 218 reusability, composability, autonomy, and discoverability. 219 Business services can be defined, and be implemented in a 220 unified enterprise view that is coherent and repeatable, hence; 221 All functions are defined as services. This includes purely 222 business functions, business transactions composed of lower- 223 level functions, and system service functions. 224 All services are independent. They operate as "black boxes"; 225 external components neither know nor care how they perform 226 their function. 227 In the most general sense, the interfaces are virtually-usable; 228 that is, at an architectural level, it is irrelevant whether they are 229 local (within the system) or remote (external to the immediate 230 system), what interconnect scheme or protocol is used to effect 231 the invocation, or what infrastructure components are required to 232 make the connection. 233 In all this, the interface is the key, and is the focus of the calling 234 application. It defines the required parameters and the nature of 235 the result; thus, it defines the nature of the service, not the 236 technology used to implement it. It is the system's responsibility 19 Page 8 of 10 20
  9. 9. 21Washington State Enterprise Architecture Program September 17, 2008 22State Enterprise Service-Oriented Architecture (SOA) Business Case EA Committee Endorsed Version 2.1 23 237 to effect and manage the invocation of the service, not the calling 238 application. This allows two critical characteristics to be realized: 239  That the services are truly independent, and 240  That the services can be managed. 241 It is imperative to develop a stage “Architecture Management 242 Maturity Framework” that defines what needs to be done to 243 effectively manage the Service Oriented Architecture initiative. 244TIER ONE Statewide Enterprise Architecture business processes, data, or 245 technologies that is common among the majority or to all state 246 agencies. 247 Tier Definitions: 248  Tier One: Across/among agency systems 249  Tier Two: Within an agency 250  Tier Three: Sub- agency level 251 These three different tiers depend on the degree to which they 252 should be common, and what other entities with which they 253 should be common. A description of the state’s Tiers is available 254 at: http://isb.wa.gov/committees/enterprise/concepts/ 255WEB SERVICES A set of standards-based, platform-independent technologies 256 designed to support interoperable program-to-program 257 interaction over a network. The advent of Web services has 258 largely influenced the broad adoption of SOA. However, in the 259 context of a Service-Oriented Architecture, Web services are just 260 one possible communication mechanism. 261 9.References 262Gartner Gartner Group Research Service, retrieved 2007 263 Building a Service-Oriented Architecture Business Case: 264 Effective Communication is the First Step, Gartner, March 2007 265Forrester Forrester Research Service, retrieved 2007 266NASCIO National Association of Chief Information Officers, Enterprise 267 Architecture Tool Kit v 3, October 2003. 268Standards Information Services Board EA Integration Architecture 269 Standards http://isb.wa.gov/policies/eaprogram.aspx 24 Page 9 of 10 25
  10. 10. 26Washington State Enterprise Architecture Program September 17, 2008 27State Enterprise Service-Oriented Architecture (SOA) Business Case EA Committee Endorsed Version 2.1 28 270 Appendix A: Documenter Team 271This document was developed through the enterprise architecture Shared Services for SOA initiative, 272chartered July 10, 2008. The Documenter Team members are listed in the Charter Appendix A at: 273http://dis.wa.gov/enterprise/enterprisearch/soa_initiative.aspx 274 Appendix B: Review Log 275The following feedback on this document was received by the Enterprise Architecture Program; the 276response to each contribution is noted below. Review by whom Contribution Response and when EA Committee • Revised where terms ‘shared’ and ‘common’ Incorporated comments and interchanged into endorsement document • Removed ‘potentially’ from Objective description – ‘Identify program requirements…’ p 7, line 143 • Revised Section 7, Recommendation to include the initiative will look for an opportunity to identify, refine, or build a Tier 1 SOA-based solution. 277 Appendix D - 2008-2014 State Strategic Information Technology Plan 278Goal 1: Invest in Common Systems 279• Adopt a common system approach for the state’s back-office systems such as the Office of Financial 280 Management’s Roadmap project, the Department of Personnel’s Human Resources Management 281 System, and the Health Care Authority’s Benefits Administration/Insurance Accounting System. 282Goal 2: Promote Data Sharing 283• Allow for the sharing of data through common data standards and management, data archiving, and 284 the adoption of common platforms and infrastructure. 285Goal 3: Promote Common IT Practices 286• Adopt standards, frameworks, and infrastructures that promote data sharing, an integrated end-user 287 experience, and provide for common functionality across the state such as licensure and revenue 288 collection. 289Goal 4: Provide an Integrated End-user Experience 290• Ensure citizens and businesses can interact seamlessly with multiple federal, state, and local 291 agencies. 29 Page 10 of 10 30

×