• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
SOA Initiative Charter (doc)
 

SOA Initiative Charter (doc)

on

  • 1,063 views

 

Statistics

Views

Total Views
1,063
Views on SlideShare
1,063
Embed Views
0

Actions

Likes
0
Downloads
53
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    SOA Initiative Charter (doc) SOA Initiative Charter (doc) Document Transcript

    • 1 2 3 4 5 6 7 8 Stewards/Contributors: 9 Bill Kehoe10 Department of Licensing 11 Christy Ridout 12 Department of Labor & Industries 13 Frank Westrum 14 Department of Health Paul Warren Douglas15 Service-Oriented Architecture (SOA) Department of Information Services 16 Initiative Charter 17 Reviewers/Contributors:18 ISB Approved Documenter Team19 Version 3.0 Enterprise Architecture Committee20 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
    • 2Washington State Enterprise Architecture Program July 10, 2008 3Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 4 21 July 10, 2008Table of Contents 221. Document History.......................................................................................................................3 232. Document Context......................................................................................................................3 243. Purpose.......................................................................................................................................3 254. Initiative Description ...................................................................................................................4 26 4.1. Introduction...........................................................................................................................4 27 4.2. Background..........................................................................................................................4 28 4.3. Objectives.............................................................................................................................5 295. Key Issues or Decisions to be Addressed...................................................................................5 30 5.1. Related EA Committee Principles.........................................................................................6 316. Deliverables and Timelines.........................................................................................................6 327. Key Stakeholders........................................................................................................................8 33 7.1. Enterprise Architecture Committee Stewards.......................................................................8 34 7.2. Business Sponsorship..........................................................................................................8 35 7.3. Documenter Team................................................................................................................8 36 7.4. Coordination with Related Efforts.......................................................................................10 378. Past Work on this Initiative........................................................................................................10 389. Documenter Team Process......................................................................................................10 39 9.1. Time Commitment of the Documenter Team......................................................................11 4010. Document Review Process.....................................................................................................11 41 10.1. Key Dates.........................................................................................................................11 42 10.2. Timeline............................................................................................................................11 4311. Evolving a Single, Cohesive Enterprise Architecture..............................................................12 4412. Initiative Status Reporting.......................................................................................................12 4513. Initiative Sunset.......................................................................................................................12 4614. Glossary..................................................................................................................................12 4715. References..............................................................................................................................14 48 49 50 5 Page 2 of 18
    • 6Washington Enterprise Architecture Program July 10, 2008 7Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 51 1.Document History 52 Date Version Editor Change March 7, 2007 - 1.0 – Allen Schmidt Conceptual Draft for EA Committee October 26, 2007 1.6 endorsement Bill Kehoe Christy Ridout Frank Westrum Paul Warren Douglas October 31, 2007 2.0 Paul Warren Douglas Endorsed by EAC. Documenter Team Draft April 3, 2007 2.1 Paul Warren Douglas Documenter Team Comments May 15, 2008 2.2 Paul Warren Douglas Documenter Team Comments Ed Tolentino SOA Definition May 13, 2008 2.3 Paul Warren Douglas Documenter Team Comments Ed Tolentino SOA Definition Edits June 3, 2008 2.4 Christy Ridout EA Committee Comments and Endorsement July 10, 2008 3.0 Paul Warren Douglas Approved by the Information Services Board 53 54 2.Document Context 55This document currently has ISB Approved status. This status signifies the document has been 56endorsed by the EA Committee and approvedted by a vote of the Information Services Board. For 57more information about the ISB Enterprise Architecture Committee and its initiative, please visit 58the EA Committee website at: 59http://isb.wa.gov/committees/enterprise/index.aspx 60 3.Purpose 61(SOA) The purpose of this charter is to identify the opportunity and high-level plan for a TIER ONE 62Service Oriented Architecture (SOA) initiative designed to advance the state’s enterprise 63architecture. The document provides a description, background, expected deliverables, scope, 64resources, timelines, and key issues and decisions to address in order to achieve the initiative’s 65objectives. 8 Page 3 of 18
    • 9Washington Enterprise Architecture Program July 10, 2008 10Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 66The Enterprise Architecture is defined as a logically consistent set of principles, practices, 67policies, models, standards, and guidelines that are derived from business requirements that 68guide decision-making and the engineering of an organization’s information systems and 69technical infrastructure. 70The ISB Enterprise Architecture Standards, Guidelines, and related architectural documents are 71available at: http://isb.wa.gov/policies/eaprogram 72 4.Initiative Description 734.1.Introduction 74The state of Washington places a high-priority on Government accountability and efficiencies in 75services. Government services need to be provided from the perspective of a cohesive, single 76state enterprise. 77Agency business programs provide secure and reliable services statewide, while various types of 78applications and technical infrastructure ensure 24/7 delivery of those government services. The 79systems are built using a variety of technologies and platforms, and parts of these systems 80perform similar functions. 81The opportunity exists to identify the similar functions or ‘services’ within the enterprise which 82could be consolidated into a single service or services to increase efficiency, improve business 83agility, and reduce organizational complexity. SERVICE-ORIENTED ARCHITECTURE (SOA) separates the 84business, applications, and technology into loosely coupled ‘service’ layers, so that similar 85functions can be provided as SERVICES, and made available as reusable building blocks. 86Service examples: Authentication, credit card authorizations, 87The state’s Enterprise Architecture Committee created the SOA initiative to evaluate and 88understand this business-driven architectural evolution. 89This initiative seeks to develop recommendations for an enterprise SOA roadmap, reference 90framework, and program requirements to assist in education, identification, creation, and use of 91shared services. 924.2.Background 93Service-Oriented Architecture are evolving as the basic building blocks for enterprise architecture 94solutions. The target - enterprise agility. The Forrester Research estimates “62% of enterprises 95are using or will use SOA by the end of 2007, and 40% will use SOA for strategic business 96transformation1” NASCIO predicts that SOA promises to be a significant innovation for state 97government. While the concepts of SOA aren’t new, they require enterprise change. 98The state’s Information Services Board (ISB) adopted EA Integration Architecture2 standards, and 99the state’s Enterprise Integration Service, that includes an Integration Competency Center, 100position the state to create shared services. 101SOA Provides: 102• Agility. Enterprises need to match business needs with the IT infrastructure efficiently and 103 timely. 104• Maintainability. SOA decouples the business services that have longer lifecycles from the 105 technology services that have shorter lifecycles. 111 Topic Overview: Service-Oriented Architecture, by Randy Heffner, Larry Fulton, Forrester 12Research, June 8, 2--7 132 ISB EA Integration Architecture Standards at: http://isb.wa.gov/policies/eaprogram.aspx 14 Page 4 of 18
    • 15Washington Enterprise Architecture Program July 10, 2008 16Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 106• Reuse. An inventory and/or repository of useful building blocks to reduce development time 107 and maintenance cost. 108• Interoperability. Services are self-contained, reusable software modules, independent of 109 applications and computing platforms. 1104.3.Objectives 111The SOA Initiative objectives are associated with Discovery and Initiative Goals as described 112below. After reviewing the Discovery results, the EAC will either request more work on Discovery 113or decide whether to proceed with Initiative Goals. 114Step 1: Discovery: 115• Develop the business case for Tier One enterprise SOA. 116• Create a Tier One enterprise SOA readiness assessment. 117• Establish common terminology and key concepts. 118Step 2: Initiative Goals: 119• Develop a Tier One enterprise SOA strategy. 120• Identify program requirements to assist in education, identification, creation, and use of 121 shared services. 122• Identify and refine policies and standards for SOA planning and governance 123• Create decision-making framework to manage SOA services. 124• Develop a reference architecture to help guide service design and deployment. 125 5.Key Issues or Decisions to be Addressed 126• How to utilize the Enterprise Integration Architecture/Integration Competency Center 127 components/artifacts/services 128• What roles and responsibilities are required to create and maintain an SOA Services program 129 for Tier One services? 130• What primary technologies enable SOA (i.e. enterprise service bus, data integration, 131 metadata repositories and management, integration middleware, etc.) 132• What Web Services or messaging technologies and best practices ensure security and 133 reliability for the deployment and consumption of shared services? 134• What are the risks and/or pain points of adding shared services to an existing business 135 process function or application (e.g. potential network impacts, added governance, etc?) 136• How does a multi-agency enterprise identify, select, and agree upon the service to be 137 shared? 138• What private and public sector best practices exist for SOA programs and resources, 139 education, governance, and use? 140• Identify ISB standards, state RCWs, federal mandates, or other policies for implementing 141 shared services, including potential impacts to business or technical services delivery 142 models. 143• What are the recommended architecture review and compliance models for the SOA? 17 Page 5 of 18
    • 18Washington Enterprise Architecture Program July 10, 2008 19Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 144• What best practices, tools, and industry standards are recommended for business and data 145 modeling, describing, storing, etc. 146• How do we engage with and educate the business community and agencies? What are the 147 private and public sector best practices? 148• What are the related state’s ISB security standards, and what ‘industry’ standards and best 149 practices are needed (e.g. WS-Security) to ensure security. 1505.1.Related EA Committee Principles 151The Shared Services for SOA Architecture initiative will rely on the state’s EA Tier One over- 152arching principles3 for initiative decision-making. Other domain-specific principles may also be 153established during the initiative process as noted in Section 5: Key Issues or Decision to be 154Addressed. 155Key Tier One over-arching principles include: 156• The Commonality Principle - Should be common where there is a clear business case; once 157 designated as common, justification is required to deviate 158• The Interoperability Principle – Should enable interoperability 159• The Natural Boundaries Principle - Should be designed around natural boundaries. 160• The Business Continuity Principle - Should be designed and implemented in a way that 161 minimizes interruptions to service 162 6.Deliverables and Timelines 163This section identifies the high-level work plan deliverables, and timelines to achieve the initiative 164Objectives identified in Section 4.4. Each enterprise initiative evolves architectural components 165(including policies, standards, and guidelines) in accordance with the NASCIO EA Framework 166and Architecture Lifecycle documented in the Enterprise Architecture Program’s Program 167Management Plan. 168 169 Document Description Timeline Define the opportunities, objectives, scope, stakeholders, and July 10, Charter documenter team members. Gain Executive Sponsorship. 2008 - ISB 170 171 172 203 The Washington State EA Over-Arching Principles at: http What are the risks and/or pain 21 points of adding shared services to an existing business process function or application? 22://isb.wa.gov/committees/enterprise/architecture/index.aspx 23 Page 6 of 18
    • 24Washington Enterprise Architecture Program July 10, 2008 25Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 Phase Document/Task Purpose Timeline Identify the state’s current SOA processes, Phase I – TBD and architecture (i.e. Integration Baseline Baseline Artifacts, Architecture, Integration Competency Architecture Solution Sets Center, policies, solution sets, initiatives, etc.) Identify principles, business drivers, and TBD environmental trends to guide Tier One enterprise SOA decisions. SOA Architecture Document SOA industry standards and Domain best practices for business, information, technology, and solution architectures. The preferred Tier One SOA architecture, TBD Phase II – Target Architecture including functional and supporting Target Solution Set features. Architecture Phase III – Gap/Opportunity Strategic analysis between Baseline and Gap/Opportu Analysis Target Architectures including: final nity Analysis gaps/opportunities, and recommended migration strategies. Finalizes selected components for target architecture. Can include additional findings. Note: Includes recommended migration strategies to ‘close the gaps’ (i.e. common authentication, standards, architectural changes), and meet initiative objectives identified in charter including: Conceptual Technical Create Enterprise SOA Reference TBD Reference Architecture Architecture. Include selected domain principles, business drivers, environmental trends, target solution set features, and glossary. Phase IV – Recommended Standards and Migration TBD Migration Recommended Strategies to meet Initiative Objectives Plan Migration Strategies 173 26 Page 7 of 18
    • 27Washington Enterprise Architecture Program July 10, 2008 28Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 174 7.Key Stakeholders 175This section identifies key stakeholders of the initiative. 1767.1.Enterprise Architecture Committee Stewards 177Each initiative must have at least one steward from the Enterprise Architecture Committee. 178Committee stewards can be considered as the executive sponsors of the initiative. As such, the 179stewards are responsible for coordinating communication with the Committee, coordinating 180communication with other executive stakeholders, assisting in removal of obstacles to the 181initiative’s progress, and assisting in making resources available to the initiative. In all of these 182responsibilities, the Enterprise Architecture Program will support the stewards as needed. 183EA Committee Stewards 184 • Bill Kehoe, Department of Licensing 185 • Christy Ridout, Labor and Industries 186 • Frank Westrum, Department of Health 187Acting Enterprise Architect 188 • Paul Warren Douglas 189Documenter Team Members 190 • See Appendix A 1917.2.Business Sponsorship 192State agency business service owners are key stakeholders for creating the business vision and 193objectives for an enterprise SOA shared services program. This initiative will seek opportunities to 194establish open communications channels to identify common business requirements. 195Part of a successful SAO strategy is for IT to partner with process-centric business leaders who 196have a process mandate, and then to internalize that process partner’s business goals. Business 197and IT must co-articulate and execute the vision of business process improvement and the 198contribution of a services oriented architecture. 199SOA requires architects to focus on business capabilities, rather than on applications. Business 200processes must be expressed in terms of capabilities that business requires, and then evaluated 201in terms of commonalities and synergies before considering enabling systems. SOA is not a 202technology. It requires strong commitment from the business sponsors to re-think their operating 203model and to break down the functional boundaries within the organizations. 204An enterprise SOA needs collaboration between IT and lines of business that focuses on 205business process modeling, business strategy mapping, application integration and data 206standards. During this collaboration, the business community will need to focus on their business 207workflows, their decision support data requirements, and their analytical processes. IT will need 208to focus on the technical architecture, business applications, and business reporting solutions. In 209doing this together, they need to drive toward a process centric culture that develops 210collaboration among enterprises. 2117.3.Documenter Team 212The Documenter Team will consist of subject-matter experts and other stakeholders to assist the 213Enterprise Architecture Committee and Program with completing the deliverables for the initiative. 29 Page 8 of 18
    • 30Washington Enterprise Architecture Program July 10, 2008 31Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 214The EA Committee and Program will send an open invitation for subject matter experts to 215participate on the multi-agency/entity Documenter Team. Documenter Team members for this 216initiative are expected to include agency enterprise architects, application architects, technology 217architects, and business solutions architects. Individuals may also be invited to participate based 218on their experience. The Documenter Team is listed in Appendix A. 219An SOA enterprise architect is expected to be acquired to help the initiative achieve its objectives, 220and other Industry experts may be brought in to work on specific project deliverables. 221The initiative stewards are responsible to ensure the following roles are sufficiently staffed for to 222complete the project objectives. This initiative should not move forward until all of the roles below 223are satisfied by the team membership or contracted assistance. 224Note: The following draft Roles and Responsibilities matrix is subject to change following the 225selection of the SOA enterprise architect and program resources. 226 DRAFT Role4 DRAFT - Definition/Purpose Executive Communicates with key stakeholders on behalf of the initiative Sponsors/Stewards Ensures the Documenter Team has adequate resources to meet its milestones Facilitates resolution of issues that cannot be resolved within the team SOA Enterprise Provides technical expertise in the initiative’s topic areas Architect Responsible to provide each written deliverable (See list of deliverables and responsibilities identified within the Primary Subject- Statement of Work) Matter Expert Brings best practices and lessons-learned to the initiative Authors artifacts (supported by Chief Enterprise Architect and Policy Advisor) Agency Architects Represent communities of interest Subject-Matter Brings best practices and lessons-learned from the statewide IT Experts community to the initiative Project Manager Monitors and reports initiative’s progress towards milestones Provides logistical support to Documenter Team (meeting coordination, support resources, etc.) Facilitates team meetings and ensures maximum meeting productivity/effectiveness Manages submission of team’s artifacts to central EA repository Enterprise Architect Provides strategic direction to ensure the SOA enterprise architecture aligns with the state’s enterprise architecture direction and policies, and 324 The Roles and Definition/Purpose Matrix is based on the NASCIO EA Tool Kit. 33 Page 9 of 18
    • 34Washington Enterprise Architecture Program July 10, 2008 35Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 DRAFT Role DRAFT - Definition/Purpose other domains Support in the identification of the correct framework artifacts, existing policies, etc. Supports executive sponsor in communicating with the EA Committee Authors and reviews artifacts (supported by SMEs and Policy Advisor) Provides coordination across Documenter Teams and Domains Policy Advisor Supports Documenter Team in creation of Compliance Components (policies, standards, guidelines) in the Technology Architecture Through artifact review, ensures Compliance Components meet ISB form and content standards Provides policy-oriented coordination across Documenter Teams 227 2287.4.Coordination with Related Efforts 229The Shared Services initiative will examine the relationships to other initiatives such as the 230Integration Architecture Standards, the Enterprise Integration Service and Integration 231Competency Center, and the Identity Management initiative, as well as any other related EA 232initiative or ISB policy. 233 8.Past Work on this Initiative 234Some state and local agencies/entities and educational institutions have built common services 235and/or Web services or SOA solutions or components; however, there is not an Enterprise SOA 236Program to provide needed education to enable the identification, selection, and use of common 237services. 238 9.Documenter Team Process 239This section identifies the expected schedule for the initiative’s activities and deliverables in the 240Document Process. 241The Enterprise Architecture Committee and Program recognize that by its very nature, the effort 242to reach architectural milestones is difficult to predict. At the same time, the Committee and 243Program have established that the Enterprise Architecture must be in the habit of frequently 244producing valuable deliverables. Therefore, initiatives must practice effective project 245management techniques, including time boxing of objectives as needed, to remain on-track with 246this schedule. Schedule deviations must be communicated and coordinated with the Enterprise 247Architecture Committee. 248The target milestone dates listed above are the EA Program’s best estimate at the outset of the 249Contextual pass. At the conclusion of each level of detail, the Documenter Team and EA 250Program will have a much better estimate as to the time required to complete the initiative. 36 Page 10 of 18
    • 37Washington Enterprise Architecture Program July 10, 2008 38Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 2519.1.Time Commitment of the Documenter Team 252This section sets forth the expectations of the Enterprise Architecture Committee and the 253Enterprise Architecture Program as to what commitment of time and resources will be requested 254of team members. 255The Documenter Team member’s time still needs to be determined for this initiative. Past 256initiatives averaged 3-6 hours per month. The Enterprise Architecture Program’s expected hours 257per week will be determined on scope and selection of deliverables. 258 10.Document Review Process 259This section identifies the expected schedule for the initiative’s activities and deliverables in the 260Review Process. Note that the Review Process need not follow the Document Process 261sequentially; some of the Review Process milestones may occur during the Document Process 262timeline. 26310.1.Key Dates 264Key stakeholder’s meeting schedules are: TBD 265Key stakeholder meeting dates will be included in the detailed workplan developed and managed 266by the SOA enterprise architect. 26710.2.Timeline 268This section identifies the expected dates for the Review Process milestones. The timeline and 269review process will be identified within the detailed project workplan. 270 Phase I – Process Example Activity (note stakeholder group) Date Comment/Revision Enterprise Architecture Committee review and October 2007 endorsement of contextual artifacts (Charter) – June 2008 and Phase I Conceptual Information Services Board review of July 10, 2008 contextual and conceptual artifacts (Charter and Phase I Conceptual Endorsement EAC – Contextual (Charter) and Phase I October 2007 Conceptual – June 2008 ISB - Contextual (Charter) and Phase I July 10, 2008 Conceptual 271 39 Page 11 of 18
    • 40Washington Enterprise Architecture Program July 10, 2008 41Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 272 11.Evolving a Single, Cohesive Enterprise Architecture 273The Enterprise Architecture Committee has established the goal of having all enterprise initiatives 274evolve a single, cohesive Tier One SOA Enterprise Architecture for Washington State. 275Members of the Documenter Team are asked to share in this goal with the Committee and the 276Enterprise Architecture Program. The Program will provide the coordination, leadership, and 277consulting expertise to ensure the achievement of this goal through development of standard 278architecture artifacts with standard tools and housed in a single repository. The Program will also 279ensure that artifacts from all initiatives are presented to the stakeholder community as a cohesive 280architecture, in accordance with the Program’s Communications Plan. 281 12.Initiative Status Reporting 282The Enterprise Architecture Program will prepare an initiative status report for each Enterprise 283Architecture Committee meeting (every other Wednesday). The status report will contain, at a 284minimum: 285 • Status of initiative versus expected timeline for each level of detail, established above 286 • Indicator of whether this status is on track or not 287 • If no progress has been made on the initiative in the past two weeks, the status report will 288 indicate a reason 289The Enterprise Architecture Program Director will circulate the status report for review by the 290Documenter Team. 291 13.Initiative Sunset 292When the Documenter Team, Enterprise Architecture Committee, or Enterprise Architecture 293Program Director believe the initiative has achieved its initial objectives, the topic of closing out 294the initiative will be placed on the agenda of the Enterprise Architecture Committee. The initiative 295will be closed, or not, at the discretion of the Committee or by the Information Services Board. 296 14.Glossary 297SERVICES Self-contained, reusable software modules that are 298 independent of the computing platforms on which they 299 run. Services allow a 1:1 mapping between business 300 tasks and the exact IT components needed to execute 301 the task. Services can be shared, and can be combined, 302 to form complete business solutions. 303 An SOA service used by more than one business 304 solution. Shared services are often classified by scope 305 or range of influence. “Enterprise” services are shared 306 across many business domains. “Domain” services are 307 shared within a single business domain. “Local” 308 services are typically confined to a single business 309 solution 310SERVICE-ORIENTED ARCHITECTURE A Service Oriented Architecture (hereafter called SOA) 311 is an architectural framework designed to offer common 312 services, in an agreed upon, consistent fashion, to 313 reduce duplication of effort across an enterprise. 314 It is one tenet of organizational transformation and IT 315 management focused on a long-term view blueprint (with 42 Page 12 of 18
    • 43Washington Enterprise Architecture Program July 10, 2008 44Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 316 a plan) that describes the transitioning from current and 317 desired operational state. SOA unifies business 318 processes through the use of service encapsulation, 319 loose coupling, abstraction, reusability, composability, 320 autonomy, and discoverability. 321 Business services can be defined, and be implemented 322 in a unified enterprise view that is coherent & repeatable, 323 hence; 324 All functions are defined as services. This includes 325 purely business functions, business transactions 326 composed of lower-level functions, and system service 327 functions. 328 All services are independent. They operate as "black 329 boxes"; external components neither know nor care how 330 they perform their function. 331 In the most general sense, the interfaces are virtually- 332 usable; that is, at an architectural level, it is irrelevant 333 whether they are local (within the system) or remote 334 (external to the immediate system), what interconnect 335 scheme or protocol is used to effect the invocation, or 336 what infrastructure components are required to make the 337 connection. 338 In all this, the interface is the key, and is the focus of the 339 calling application. It defines the required parameters 340 and the nature of the result; thus, it defines the nature of 341 the service, not the technology used to implement it. It is 342 the system's responsibility to effect and manage the 343 invocation of the service, not the calling application. This 344 allows two critical characteristics to be realized: 345  That the services are truly independent, and 346  That the services can be managed. 347 It is imperative to develop a stage “Architecture 348 Management Maturity Framework” that defines what 349 needs to be done to effectively manage the Service 350 Oriented Architecture initiative. 351TIER ONE Statewide Enterprise Architecture business processes, 352 data, or technologies that are common among the 353 majority or to all state agencies. 354 Tier Definitions: 355  Tier 1: Across/among agency systems 356  Tier 2: Within an agency 357  Tier 3: Sub- agency level 358 These three different tiers depend on the degree to 359 which they should be common, and what other entities 360 with which they should be common. A description of the 361 state’s Tiers is available at: http://isb.wa.gov/committees/ 362 enterprise/concepts/ 363WEB SERVICES A set of standards-based, platform-independent 364 technologies designed to support interoperable program- 45 Page 13 of 18
    • 46Washington Enterprise Architecture Program July 10, 2008 47Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 365 to-program interaction over a network. The advent of 366 Web services has largely influenced the broad adoption 367 of SOA. However, in the context of a Service-Oriented 368 Architecture, Web services are just one possible 369 communication mechanism.. 370 371 15.References 372Enterprise SOA Enterprise SOA, Service-Oriented Architecture Best 373 Practices, Dirk Krafzig, Karl Banke, Dirk Slama, 2005 374SOA-ERL Service-Oriented Architecture, Concepts, Technology, 375 and Design, Thomas Erl, 2005 376Gartner Gartner Group Research Service, retrieved 2007 377Forrester Forrester Research Service, retrieved 2007 378NASCIO National Association of Chief Information Officers, 379 Enterprise Architecture Tool Kit v 3, October 2003. 380 48 Page 14 of 18
    • 49Washington Enterprise Architecture Program July 10, 2008 50Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 381 Appendix A: Documenter Team 382This document was developed through the enterprise architecture Shared Services for SOA 383initiative, chartered (expected) January 10, 2008. The following individuals were members of the 384Documenter Team for this initiative, and participated in review of this document. First Last Company Email Phone Role Bill Kehoe Department of Licensing Steward Christy Ridout Labor and Industries Steward Allen Schmidt Office of Financial Statewide Management Financial Systems Ed Tolentino Department of Information Enterprise Services Architect Frank Westrum Department of Health Steward Paul Douglas Department of Information Policy Advisor Services Little Sheryl Department of Licensing Administrative Documentation Support Program Team Kent Andrus Office of Financial Agency Management Architect/ Subject Matter Expert Jerry Britcher Department of Social and Agency Health Services Architect/ Subject Matter Expert Bill Yock University of Washington Agency Architect/ Subject Matter Expert Donna Edwards Department of Information Agency Services Architect/ Subject Matter Expert Lance Calisch Department of Information Agency Services Architect/ Subject Matter Expert Darrell Davenport Department of Retirement Agency Systems Architect/ Subject Matter Expert Roger Deming Liquor Control Board Agency Architect/ Subject Matter Expert Gary Dubuque Department of Revenue Agency Architect/ Subject Matter Expert Robin Griggs Department of Licensing Agency 51 Page 15 of 18
    • 52Washington Enterprise Architecture Program July 10, 2008 53Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 Architect/ Subject Matter Expert Bret Holtz Department of Health Agency Architect/ Subject Matter Expert David Jennings Department of Health Agency Architect/ Subject Matter Expert JoAnne Kendrick Department of Information Chief Integration Services Officer Chris Lamb Department of Retirement Agency Systems Architect/ Subject Matter Expert Daniel Mercer Labor and Industries Agency Architect/ Subject Matter Expert Noel Morgan Department of Agency Transportation Architect/ Subject Matter Expert Joy Paulus Department of Information GIT Architect/ Services Subject Matter Expert Heidi Whisman Department of Ecology Agency Architect/ Subject Matter Expert Son Tran Department of Ecology Agency Architect/ Subject Matter Expert Douglas McGregor Department of Licensing Agency Architect/ Subject Matter Expert 385 386 Appendix B: Review Log 387The following feedback on this document was received by the Enterprise Architecture Program; 388the response to each contribution is noted below. Review by whom Contribution Response and when Initiative Stewards • Renamed initiative from Common Incorporated into Document and acting CEA Services to Shared Services • Revised/Updated Document Context 54 Page 16 of 18
    • 55Washington Enterprise Architecture Program July 10, 2008 56Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 to reflect latest EA Program version • Updated Appendix A: Documenter Team • Revised expected Charter date for request for ISB adoption EAC, enterprise • Clarified SOA, shared services, Incorporated into Document architects objectives and scope. EAC and Initiative • Reworded intro to clarify the initiative Incorporated into Document Stewards will evaluate and understand and create recommendations, rather then implement • Objectives reordered to focus on high-level, added discovery objective “first identify if SOA strategy should be perused at the Tier One level, others moved to Key Questions section. Moved business focused objectives to Key Questions section. • Added new row section 9 Baseline to identify the state’s current artifacts, solutions, etc (i.e. Integration Architecture) • Changed target dates Documenter Team • Removed Shared Services from title, Incorporated into Document Comments as service result from SOA • Edited document to remove Shared Services where needed • Revised Glossary entries and definitions • Revised Section 6 Scope and Section 9.2 Timeline and Deliverables, and aligned with initiative Objectives • Replaced Section 6 with Section 9.2 Documenter Team • Refined Objectives based on DT Incorporated into Document Comments comments • Revised Glossary definitions • Renamed 4.3 Business Drivers/Environmental Trends – ‘SOA Provides.’ • Combined/removed duplicate Key 57 Page 17 of 18
    • 58Washington Enterprise Architecture Program July 10, 2008 59Service-Oriented Architecture (SOA) Initiative Charter ISB Approved—Version 3.0 Issues or Decisions • Removed bulleted Objectives in Deliverables and Timelines and created cross reference Final DT • Clarified Purpose section Incorporated into Document Comments • Minor revisions in Introduction and 5/13/08 Key Issues • SOA Glossary definition revision EA Committee • Revised Objectives. Added Stepped Incorporated into Document Comments approach including: 6/3/2008 • Step 1: Discovery Business Case, Readiness Assessment, and Glossary 389 60 Page 18 of 18