WORD
Upcoming SlideShare
Loading in...5
×
 

WORD

on

  • 455 views

 

Statistics

Views

Total Views
455
Views on SlideShare
455
Embed Views
0

Actions

Likes
0
Downloads
9
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

WORD WORD Document Transcript

  • 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Contributors: 15 Integration Services Governance Scott Came Department of Information Services 16 Laura Parma 17 EA Committee Document Department of Information Services 18 Version 1.5 19 Department of Information Services Enterprise Architecture Program 1110 Jefferson Street SE P.O. Box 42445 Olympia, WA 98504-2445 Phone 360/902.3519 Fax 360/902.2982 1
  • 2Washington State Enterprise Architecture Program December 13, 2006 3Integration Services Governance EA Committee Document—Version 1.5 4 20 December 13, 2006Table of Contents 211. Document History.......................................................................................................................2 222. Document Context......................................................................................................................3 233. Introduction and Purpose............................................................................................................4 244. Scope..........................................................................................................................................4 255. Public and Private Services........................................................................................................4 266. Roles and Responsibilities..........................................................................................................5 27 6.1. Change Management ..........................................................................................................5 28 6.1.1. Public Services..............................................................................................................5 29 6.1.2. Private Services.............................................................................................................5 30 6.1.3. Infrastructure..................................................................................................................6 31 6.2. Configuration Management..................................................................................................6 32 6.3. Quality Assurance ...............................................................................................................6 33 6.3.1. Assurance of Real-World Effect.....................................................................................6 34 6.3.2. Assurance of Standards and Interaction Profile Conformance.......................................7 35 6.4. Service Level Agreement.....................................................................................................7 36 6.5. Service Reuse .....................................................................................................................7 377. Integration Competency Center..................................................................................................7 388. References.................................................................................................................................8 39 Appendix A: Documenter Team...................................................................................................10 40 Appendix B: Review Log..............................................................................................................11 41 42 43 44 45 1.Document History Date Version Editor Change July 21, 2006 1.0 Scott Came Initial Draft August 4, 2006 1.1 Scott Came Second Draft November 16, 2006 1.2 Paul Warren Douglas EAC and Documenter Team revisions November 30, 2006 1.3 Paul Warren Douglas Documenter Team revisions - Near Final Draft 5 Page 2 of 12
  • 6Washington Enterprise Architecture Program December 13, 2006 7Integration Services Governance EA Committee Document—Version 1.5 Date Version Editor Change December 6, 2006 1.4 Paul Warren Douglas Documenter Team final revisions to present to EAC for endorsement, and EAC edits December 13, 2006 1.5 Paul Warren Douglas EAC edits for endorsement Changed status to EA Committee document 46 47 2.Document Context 48This document currently has EA Committee Document status. This status signifies that the 49document has been endorsed by the EAC and is waiting to be adopted by a vote of the ISB. For 50more information about the Enterprise Architecture Program or the ISB Enterprise Architecture 51Committee and its initiative, please visit the EA Committee website at: 52http://isb.wa.gov/committees/enterprise/index.aspx. 8 Page 3 of 12
  • 9Washington Enterprise Architecture Program December 13, 2006 10Integration Services Governance EA Committee Document—Version 1.5 53 3.Introduction and Purpose 54The purpose of this document is to establish standards for the governance of the state’s 55integration architecture, services deployed within that architecture, and infrastructure that 56supports integration. 57This document answers the following questions: 58 • How can the state manage and control changes to service interfaces? 59 • How can the state identify versions of services, and associate sets of service artifacts 60 with a version identifier? 61 • How can the state ensure that agencies reuse services properly, only creating variants of 62 services when justified by a business case? 63 • How can the state ensure that services properly achieve their advertised REAL-WORLD 64 effect? 65 • How can the state ensure that service interfaces conform to the standards of a service 66 interaction profile within the architecture? 67 • What are the standard issues that agencies should consider addressing in the service- 68 level agreement (SLA) for a service? 69This document does not provide guidance on overall business or information technology 70governance issues. In particular, it does not suggest which services agencies should provide to 71one another, nor does it suggest which agencies should provide which services. These 72governance issues should be addressed by individual projects or system implementation 73initiatives. 74 4.Scope 75The ISB Integration Architecture standards available at: http://isb.wa.gov/policies/eaprogram.aspx 76apply to executive and judicial branch agencies and educational institutions. Academic and 77research applications at institutions of higher education are exempted. 78In this document, the terms “state agency” and “agency” mean any agency or institution within the 79scope of the previous paragraph, and the term “state enterprise” means all agencies and 80institutions (collectively) within the scope of the previous paragraph. 81Starting November 9, 2006, the Integration Architecture Standards will govern the planning and 82construction of all applications that share data with other agencies. 83 84Exemption requests must be submitted to the DIS Management and Oversight of Strategic 85Technologies Division and will be forwarded to the ISB for decision. Applications existing or 86under construction as of November 9, 2006, are not required to immediately comply, but will be 87required to comply when redesigned or replaced. 88 5.Public and Private Services 89According to the [OASIS] SOA Reference Model [SOA-RM], ‘private services’ and ‘public 90services’ are two broad categories of services within service oriented architectures. For purposes 91of this document, and integration architecture, these terms should not be confused with ‘public 92and private government services.’ A PRIVATE SERVICE is one that an agency offers to a known, finite, 93specific set of consumers. Private services should be governed by specific service level 94agreements negotiated between the consumers and the provider. 11 Page 4 of 12
  • 12Washington Enterprise Architecture Program December 13, 2006 13Integration Services Governance EA Committee Document—Version 1.5 95A PUBLIC SERVICE is one that an agency offers to a much broader set of consumers whose identity 96cannot be determined in advance, and that may change regularly. Public services should be 97governed by generic service level agreements that the provider publishes publicly with the service 98description, and that apply to all consumers. 99The standards in this document will distinguish governance mechanisms for public and private 100services, where appropriate. 101 6.Roles and Responsibilities 102This section establishes standards for the governance of integration architecture, infrastructure, 103and services. 1046.1.Change Management 105Change management standards define the way in which the state will manage and control 106changes to service interfaces (both public and private) and the shared integration infrastructure. 107Change management includes the management of the initial deployment of a service. 1086.1.1.Public Services 109Each public service shall have an agency responsible for provisioning the service. This agency is 110called the “provisioner.” The provisioner may represent the interests of several agencies through 111a program office or similar organizational unit; however, there is a single entity responsible for 112provisioning the service. 113The provisioner is responsible for identifying a group of stakeholders of the service. This should 114primarily include agencies responsible for current or planned consumer systems that use (or will 115use) the service, but may also include other stakeholders. The provisioner shall consult with this 116stakeholder group when considering changes to a service’s real-world effect or interface. This 117consultation shall begin with a notification, using the service repository’s notification capabilities 118(described in [Repository Solution Set]) and other appropriate mechanisms (for example, 119announcements at a Customer Advisory Board meeting). The standard service-level agreement 120for the service shall state clearly who has the final authority to authorize changes to the service 121(e.g., can the provisioner make the decision after consulting the stakeholder group, or must the 122provisioner seek a majority or consensus of the stakeholder group in favor of the change.) 123The provisioner is responsible for the implementation and proper functioning of the service, but 124need not inform the stakeholder group of any service implementation changes that do not change 125the interface or real-world effect. The provisioner is responsible for the implementation of 126adapters that connect provider systems to the integration infrastructure, and is also responsible 127for implementing and maintaining any orchestrations involved in the implementation of the 128service. 129For definitions of the concepts real-world effect, service interface, provider system, adapter, and 130orchestration, the reader should consult [CITRA]. 1316.1.2.Private Services 132The provisioner of a private service shall negotiate change management processes with 133consumers of the service, and shall establish those processes in the service-level agreements. 134The agreement shall specify, at a minimum: 135 • Under what conditions (including how often) a provisioner may change the service’s 136 interface 137 • How far in advance of a proposed change the provisioner must notify consumers of the 138 intent to change 14 Page 5 of 12
  • 15Washington Enterprise Architecture Program December 13, 2006 16Integration Services Governance EA Committee Document—Version 1.5 139 • How to resolve disputes between consumers regarding the viability or desirability of a 140 change to the interface 141 • How the partners will fund and implement system changes that result from the interface 142 change 1436.1.3.Infrastructure 144The Integration Competency Center (ICC), defined in section 6 below, will not typically be the 145provisioner of a service, but will mange changes to the shared integration infrastructure 146environment according to DIS’ standard change management processes. The ICC shall be 147responsible for notifying users of the infrastructure about planned changes, consulting with users, 148and coordinating with users’ project schedules. The standard service-level agreement into which 149the ICC enters with agencies to provide infrastructure and repository access shall establish 150change procedures, notification windows, and the decision-making process. 1516.2.Configuration Management 152The provisioner of a service is responsible for assigning version labels to each new version of a 153service, according to the following convention. 154A version label has four parts: a major version number, a minor version number, a point version 155number, and a build number. For example, version 1.2.3.4 has major version number 1, minor 156version number 2, point version number 3, and the build number is 4. 157A point version increment indicates a cosmetic change to a service interface that has no impact 158on the behavior of the service or the interaction of consumers with the service. An example 159would be correcting or adding documentation to the interface description. 160A minor version increment indicates a change to the interface that has very minor or no impact on 161existing consumer implementations. That is, the new service interface is backwards compatible 162with previous versions. 163A major version increment indicates a change to the interface, or policies associated with use of 164the service, that have significant impact on existing consumer implementations. 165After observing the change management standards in section 5.2 above, if a service provisioner 166makes a change to a service, the provisioner updates the service repository to reflect the new 167version. 1686.3.Quality Assurance 169Mechanisms are necessary to ensure that services reliably achieve their advertised real-world 170effect, and that each service interface conforms to a service interaction profile. 1716.3.1.Assurance of Real-World Effect 172The provisioner of a service is responsible for assuring the quality of the service, in particular 173making sure the service properly achieves the stated real-world effect. The ICC can assist the 174provisioner in fulfilling this responsibility (for example, by providing a version of the infrastructure 175platform dedicated to testing), but the final responsibility rests with the provisioner. 176Provisioners of public services shall consider providing tools to assist consumers in testing 177consumer systems that use the service. These tools could include: 178 • Providing a standalone implementation of the service interface(s) that a consumer can 179 use in developing a consumer system, including basic testing 17 Page 6 of 12
  • 18Washington Enterprise Architecture Program December 13, 2006 19Integration Services Governance EA Committee Document—Version 1.5 180 • Deploying the service in a test environment managed by the ICC to support more 181 sophisticated testing and to test performance 1826.3.2.Assurance of Standards and Interaction Profile Conformance 183Services deployed on the integration infrastructure platform and service models stored in the 184shared service repository must conform to any standards adopted by the Information Services 185Board in the area of system integration. In particular, service interfaces must conform to a 186service interaction profile standards (currently defined in [Web Services SIP], [MQ SIP], and 187[File Drop SIP]), and service models should conform to service modeling standards (defined in 188[SMG]), in order to use the shared infrastructure and repository. 189The ICC, in coordination with the Management and Oversight of Strategic Technologies Division 190(MOSTD) of DIS, are responsible for advising agencies on public service design and 191implementation to ensure conformance with standards and service interaction profiles. The ICC 192shall be responsible for ensuring that any service deployed on the shared integration 193infrastructure platform, and any service model stored in the shared service repository, conforms 194to the standards. 1956.4.Service Level Agreement 196When establishing a service-level agreement for a service, the parties (provisioner and 197consumer(s)) shall consider addressing the following issues in the agreement: 198 • Availability requirements (with what probability is the service available for interaction) 199 • Responsiveness requirements (how quickly does the service respond, both 200 synchronously and asynchronously) 201 • Privacy requirements (what restrictions are there on what the parties may do with 202 information that they obtain as part of the service interaction) 203 • Change management processes (as discussed in section 5.1 above) 204 • Financial aspects (does the provider charge a fee for usage of the service) 2056.5.Service Reuse 206Services and interfaces fall under the Enterprise Architecture Commonality Principle. Services 207and interfaces shall be designated as Tier One common assets upon demonstration of a clear 208business case; once designated as common, a business case is required for an agency to invest 209in and provide a duplicate service or interface. 210It is within the role of the ICC to promote the reuse of services and interfaces, even when those 211services or interfaces have not been designated Tier One common assets. Processes for 212developing and defining Tier One services for reuse should be defined by the EA Committee as 213the common services architecture is documented. 214Provisioners can attach policies to services that govern their reuse, and incorporate these policies 215into the service-level agreement associated with the service. For instance, a provisioner can 216prevent users from “repackaging” a service (simply wrapping the service interface with another 217service that the user provides) and changing the conditions of use (for instance, by charging 218users for access to the service.) 219 7.Integration Competency Center 220The standards in this document refer to an organizational unit called an Integration Competency 221Center (ICC) to support interagency system integration. 20 Page 7 of 12
  • 21Washington Enterprise Architecture Program December 13, 2006 22Integration Services Governance EA Committee Document—Version 1.5 222An ICC is a key to the delivery of quality and reliable enterprise integration services, and is an 223important facilitator of an enterprise approach to integration. The main objective of the ICC is to 224improve the efficiency and effectiveness of system integration activities, through close 225coordination of shared integration infrastructure with system implementation projects. This 226coordination is the responsibility of a team of skilled technical staff that have two principal roles: 227 • The operational function maintains and monitors the infrastructure of the enterprise 228 integration system. This is a support job, somewhat similar to network or system 229 management, except that it deals with application-level logic and middleware instead of 230 lower-level network or server management technical levels. 231 • The development function helps developers in each application project team design and 232 build their connections (adapters) into the integration infrastructure. This usually also 233 involves assembling and maintaining documentation (interface metadata) for the 234 application interactions. This is similar to a data administration or database administration 235 function. The development function also includes ensuring that agencies and projects 236 are aware of available shared integration infrastructure and how to use it to accomplish 237 project objectives. 238As part of fulfilling both of these roles, the ICC maintains a single statewide repository of system 239interfaces (called Service Models in [CITRA]). The ICC ensures that service models are 240consistent in format and content across the enterprise, ensures that each model contains proper, 241consistent metadata, owner agency identified as accountable for the service, and ensures that 242models reflect the reuse of existing services to meet the needs of new projects. Industry 243experience demonstrates that consistent application of standards, usage of infrastructure, and 244reuse of services is much less likely to occur without the centralized coordination function 245provided by an ICC. 246The Chief Integration Architect will manage and lead the ICC. This position will have overall 247responsibility for the proper functioning of the infrastructure, for delivery of quality consulting 248services to agencies, and for making and communicating the decisions assigned to the ICC by 249these standards. 250The Department of Information Services will manage the ICC, and is responsible for provisioning 251the shared integration infrastructure. This infrastructure includes mechanisms to transmit 252messages between systems (messaging middleware, defined in [Platform Solution Set]) and a 253repository to store and display service models and interface descriptions (defined in [Repository 254Solution Set]). The ICC will support integration between agencies. 255Individual agencies may form an organizational unit similar to an ICC to support system 256integration within each agency; the statewide ICC may serve as a resource and consultant to 257agency ICC units as needed. 258 8.References 259CITRA Washington State Information Services Board, 260 Enterprise Architecture Committee (2006). Conceptual 261 Integration Technical Reference Architecture, 262 Information Services Board. 263File Drop SIP Washington State Information Services Board, 264 Enterprise Architecture Committee (2006). File Drop 265 Service Interaction Profile Standards, Information 266 Services Board. 267Platform Solution Set Washington State Department of Information Services, 268 Enterprise Architecture Program (2006). Integration 269 Infrastructure Solution Set, Information Services Board. 23 Page 8 of 12
  • 24Washington Enterprise Architecture Program December 13, 2006 25Integration Services Governance EA Committee Document—Version 1.5 270Repository Solution Set Washington State Department of Information Services, 271 Enterprise Architecture Program (2006). Service 272 Repository Solution Set, Information Services Board. 273SMG Washington State Information Services Board, 274 Enterprise Architecture Committee (2006). Service 275 Modeling Standards, Information Services Board 276SOA-RM Reference Model for Service Oriented Architectures, 277 Working Draft 11. Organization for the Advancement of 278 Structured Information Standards (OASIS) 2005. 279Web Services SIP Washington State Information Services Board, 280 Enterprise Architecture Committee (2006). Web 281 Services Service Interaction Profile Standards, 282 Information Services Board. 283MQ SIP Washington State Information Services Board, 284 Enterprise Architecture Committee (2006). MQ Service 285 Interaction Profile Standards, Information Services 286 Board. 26 Page 9 of 12
  • 27Washington Enterprise Architecture Program December 13, 2006 28Integration Services Governance EA Committee Document—Version 1.5 287 Appendix A: Documenter Team 288This document was developed through the Integration Architecture enterprise architecture 289initiative, chartered December 14, 2005. The following individuals were members of the 290Documenter Team for this initiative, and participated in review of this document. 291 • Kent Andrus, Office of Financial Management 292 • Lori Bame, LEAP Committee 293 • Jerry Britcher, Department of Social and Health Services 294 • Scott Came, Department of Information Services 295 • Gary Dubuque, Department of Revenue 296 • Jim Eby, Department of Fish and Wildlife 297 • Brian Everson, Washington State Patrol 298 • Laura Graham, Legislative Service Center 299 • Robin Griggs, Department of Licensing 300 • John Hanson, Commission on Trade and Economic Development 301 • Tom Henderson, Department of Labor & Industries 302 • Paul Hubert, Department of Information Services 303 • Debbie Johnson, The Higher Education Coordinating Board 304 • Lorraine Louderback, Department of Corrections 305 • Dan Mercer, Department of Labor & Industries 306 • Miles Neale, Department of Ecology 307 • Bill Norris, Department of Health 308 • Laura Parma, Department of Information Services 309 • Mike Rohrbach, Administrative Office of the Courts 310 • Jeff Sharp, Office of the State Treasurer 311 • Matt Stevens, Department of Information Services 312 • Lyle Tillett, Department of Retirement Systems 313 • Steven Scott, Department of Information Services 314 • Donna Edwards, Department of Information Services 315 • Paul Warren Douglas, Department of Information Services 29 Page 10 of 12
  • 30Washington Enterprise Architecture Program December 13, 2006 31Integration Services Governance EA Committee Document—Version 1.5 316 Appendix B: Review Log 317The following feedback on this document was received by the Enterprise Architecture Program; 318the response to each contribution is noted below. Review by whom Contribution Response and when November 30, • Changed document title to Incorporated into document. 2006 reflect document content. • Added additional descriptions for public and private services terms • Changed guidelines to standards where applicable • Changed should to shall where applicable • Revised references to reflect ISB standards • Revised Websphere MQ Service references to reflect MQ Service Profile revisions • Removed reference to Gartner Hype Cycle and predictions • Revised ICC language to reflect an implemented ICC rather then recommendations for implementing the ICC • Moved ICC section to Section 6. December 6, 2006 • Minor editorial changes for Incorporated into document. readability by the Documenter Team • Final DT endorsement, ready for EAC approval. December 6, 2006 • Added ‘build number’ Incorporated into document. information to 5.2 Configuration Management • Minor editorial changes • Added Scope statement 32 Page 11 of 12
  • 33Washington Enterprise Architecture Program December 13, 2006 34Integration Services Governance EA Committee Document—Version 1.5 December 13, • Changed Standards to Incorporated into document. 2006 Governance in title and sectional headings to more appropriately classify document type • Modified Scope intro to reflect changes • Changed title of section 6 to Roles and Responsibilities • Added ‘Processes for developing and defining Tier One services’ directional statement within 6.5 Service Reuse 319 35 Page 12 of 12