1. 1234567891011 Washington State Enterprise Architecture Program 1213 Integration Architecture Initiative Charter 14 EA Committee Document 15Version 1.3 16 1

2. 2Washington State Enterprise Architecture Program December 14, 20053Integration Architecture Initiative CharterEA Committee DocumentVersion 1.3417 December 14, 2005Table of Contents 181. Document History.......................................................................................................................2 192. Document Context......................................................................................................................3 203. Description of the Initiative..........................................................................................................4 214. Key Stakeholders........................................................................................................................4 22 4.1. Enterprise Architecture Committee Stewards.......................................................................4 23 4.2. Business Sponsorship..........................................................................................................4 24 4.3. Documenter Team................................................................................................................4 25 4.4. Coordination with Related Efforts.........................................................................................8 265. Key Issues or Decisions to be Addressed...................................................................................9 276. Expected Tier One Component Scope........................................................................................9 287. Past Work on this Initiative........................................................................................................10 298. Schedule: Document Process...................................................................................................11 30 8.1. Key Dates...........................................................................................................................11 31 8.2. Timeline..............................................................................................................................11 32 8.3. Time Commitment of the Documenter Team......................................................................12 339. Schedule: Review Process.......................................................................................................12 34 9.1. Key Dates...........................................................................................................................12 35 9.2. Timeline..............................................................................................................................12 3610.Evolving a Single, Cohesive Enterprise Architecture..............................................................13 3711.Initiative Status Reporting.......................................................................................................14 3812.Initiative Sunset.......................................................................................................................14 3913.Attachments............................................................................................................................14 4041 42431.Document History 44DateVersion Editor Change October 5, 2005 1.0 Dennis Jones Initial DraftScott Came November 30, 2005 1.1 Dennis Jones Reflection of steering committee and documenter teamScott Came membership New format 5Page 2 of 14 3. 6Washington Enterprise Architecture Program December 14, 2005 7Integration Architecture Initiative CharterEA Committee DocumentVersion 1.3 8DateVersion EditorChange December 9, 20051.2 Scott Came Initiative name changed fromFinancial/Admin Services perLaura ParmaEAC direction 11/30 Removal of Roadmapgovernance sections andRoadmap IntegrationArchitecture steering committee December 14, 2005 1.3 Scott Came Modifications to addressRoadmap initiative stakeholdersneeds December 21, 2005 1.3 Scott Came Adopted by EA Committee45462.DocumentContext 47This document currently has EA Committee Document status. This status signifies thatthe 48document has been adopted by a vote of the ISB Enterprise Architecture Committee.49For more information about the Enterprise Architecture Program or the ISB Enterprise 50Architecture Committee and its initiatives, please visit the EA Committee website at:51http://isb.wa.gov/committees/enterprise/index.aspx. 9 Page 3 of 14 4. 10Washington Enterprise Architecture ProgramDecember 14, 2005 11Integration Architecture Initiative Charter EA Committee DocumentVersion 1.3 12 523.Description of the Initiative 53The Integration Architecture Initiative of the Enterprise Architecture Committee seeks to establish 54standards, guidelines, and infrastructure solutions to support the integration of information 55systems.56The initial usage of these standards, guidelines, and solutions will be in support of the Financial 57and Administrative Systems Roadmap initiative (http://www.ofm.wa.gov/roadmap/.) The 58Integration Architecture enterprise architecture initiative expects to coordinate closely with the 59Roadmap initiative to ensure that the standards, guidelines, and solutions developed meet the 60Roadmaps needs. However, this initiatives intent is to support the integration of information 61systems between government agencies without compromise and wherever operationally and 62technically feasible.63The infrastructure solutions established by this initiative will be documented within the statewide 64Enterprise Architectures Solution Architecture. Standards and guidelines will be documented 65within the Technology Architecture.66The Integration Architecture initiative also expects to establish Information Architecture 67components that are relevant to the integration of information systems. For example, this 68initiative expects to develop data modeling conventions and metadata, and standards for the 69representation of information as messages between systems.704.Key Stakeholders 71This section identifies key stakeholders of the initiative. 724.1.Enterprise Architecture Committee Stewards73Eachinitiative must have at least one steward from the Enterprise Architecture Committee. 74Committee stewards can be considered as the executive sponsors of the initiative. As such, the 75stewards are responsible for coordinating communication with the Committee, coordinating 76communication with other executive stakeholders, assisting in removal of obstacles to the 77initiatives progress, and assisting in making resources available to the initiative. In all of these 78responsibilities, the Enterprise Architecture Program will support the stewards as needed.79TheCommittee stewards for this initiative are: 80 Laura Parma, Assistant Director, Department of Information Services 814.2.BusinessSponsorship82This initiative has no additional business sponsorship beyond the Enterprise Architecture 83Committee. As noted elsewhere in this charter, this initiative views the Financial and 84Administrative Roadmap initiative as a key stakeholder, and as such coordinate closely with the 85Roadmap initiative.864.3.Documenter Team87Each initiative must have a Documenter Team, consisting of subject-matter experts and other 88stakeholders who can assist the Enterprise Architecture Program in evolving viable standards, 89policies, guidelines, and architectural components. The expectations, including time commitment, 90of Documenter Team members will be documented later in this document. Note that the term 91Documenter Team originates from the Documenter role in the NASCIO Enterprise Architecture 92framework; this is to signify that the teams objective is to play (or assist in playing) that role as 93defined in the framework, not that the team is responsible for all architectural documentation 94effort in the initiative. 13Page 4 of 14 5. 14Washington Enterprise Architecture Program December 14, 200515Integration Architecture Initiative CharterEA Committee DocumentVersion 1.316 95Each Documenter Team should ensure that the following roles are sufficientlycovered. (These96roles and their definitions are taken from the EA Program Management Plan.) 97In the NASCIO framework, the Documenter role (played here by the Documenter Team) is not98assigned responsibility for making decisions. Rather, the Documenter Teams responsibility is to99draft recommended components that are then reviewed, endorsed, and approved within the 100Review process, as documented in section 9 below.RoleDefinition/PurposeExecutive Sponsor Communicates with key stakeholders on behalf of the initiative Ensures the Documenter Team has adequate resources to meet its milestones Reports on initiative progress to the EA Committee Facilitates resolution of issues that cannot be resolved within the teamSubject-MatterProvides technical expertise in the initiatives topic areas Expert Represents communities of interest Brings best practices and lessons-learned from the statewide IT community to the initiative Authors artifacts (supported by Architect and Policy Advisor)Project Manager Monitors and reports initiatives progress towards milestones Provides logistical support to Documenter Team (meeting coordination, support resources, etc.) Facilitates team meetings and ensures maximum meeting productivity/effectivenessArchitect Supports Documenter Team in identifying and using the correct framework artifacts, modeling notations, etc. Supports executive sponsor in communicating with the EA Committee Manages submission of teams artifacts to central EA repository Provides coordination across Documenter Teams Authors artifacts (supported by SME and Policy Advisor)Policy AdvisorSupports 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 Supports SME and Architect in authoring of artifacts other than Compliance Components Provides policy-oriented coordination across Documenter Teams10117Page 5 of 14 6. 18Washington Enterprise Architecture Program December 14, 200519Integration Architecture Initiative CharterEA Committee DocumentVersion 1.320102The following table identifies the members of the Documenter Team for this initiative. This 103initiative will not move forward until all of the roles above are satisfied by the team membership.104The core of the Documenter Team for this initiative will consist of the members of the Agency 105Architects Special Interest Group (SIG), supplemented by technical experts from state agencies 106that have experience developing integration architecture in their own environment. MemberTitle Phone contactTeam roleOrganizationEmail contact Bill Norris Chief Architect (360) 236-4426 SMEDepartment of bill.norris@doh.wa.govHealth Brian Everson Information (360) 705-5396 SMETechnologyBrian.Everson@wsp.wa.govArchitectWashington StatePatrol Dan MercerChief Architect (360) 902-6003 SMEDepartment of merc235@lni.wa.govLabor andIndustries Debbie JohnsonThe Higher(360) 753-7893 SMEEducationDebbieJ@hecb.wa.govCoordinatingBoard Gary DubuqueEnterprise(360) 586-7981 SMEArchitecturegaryd@dor.wa.govDepartment ofRevenue Jeff SharpOffice of the State (360)SMETreasurerjeff@tre.wa.gov Jerry BritcherChief Architect (360) 902-7550 SMEDepartment of britcjc@dshs.wa.govSocial and HealthServices Jim Eby IT Manager(360) 902-2303 SMEDepartment of ebyjre@dfw.wa.govFish and Wildlife21 Page 6 of 14 7. 22Washington Enterprise Architecture Program December 14, 2005 23Integration Architecture Initiative CharterEA Committee DocumentVersion 1.3 24 John Hanson Commission on (360) 725-4139 SME Trade and johnh@cted.wa.gov Economic Development Kent Andrus Office of Financial (360) 664-7767 SME and TEMS Management Project kent.andrus@ofm.wa.govCoordinationLaura GrahamChief Architect graham.laura@leg.wa.govSME Legislative Service CenterLaura Parma Assistant Director(360) 725-5321 Executive Sponsor Department of LauraP@dis.wa.gov Information ServicesLori Bame Senior(360) 786-6115 SME Applications bame_lo@leg.wa.gov Consultant LEAP CommitteeLorraineNetwork Specialist(360) 725-8493 SME Louderback Department of lklouderback@doc1.wa.gov CorrectionsLyle Tillet Department of (360) 664-7106 SME Retirement LyleT@drs.wa.gov SystemsMatt StevensEnterprise(360) 902-3221 SME Security Services matts@dis.wa.gov Analyst Department of Information ServicesMike Rohrbach Administrative(360) 705-5246 SME Office of the mike.rohrbach@courts.wa.gov CourtsMiles Neale Department of (360) 407-6592 SME Ecology mnea461@ecy.wa.govPaul Hubert Department of (360) 725-5309 SME 25 Page 7 of 14 8. 26Washington Enterprise Architecture Program December 14, 200527Integration Architecture Initiative CharterEA Committee DocumentVersion 1.328Information paulh@dis.wa.govServices Robin GriggsChief Architect (360) 664-6537 SMEDepartment of rgriggs@dol.wa.govLicensing Tom Henderson Integration (360) 902-5861 SMEArchitecthent235@lni.wa.govDepartment ofLabor andIndustries Scott CameChief Architect (360) 902-3519 SMEDepartment of scottca@dis.wa.gov Project ManagerInformation ArchitectServices TBD Department ofPolicy AdvisorInformationServices107108The Enterprise Architecture Program is in the process of hiring an Integration Architect to staff 109this initiative in its efforts to develop an integration architecture to support the Financial and 110Administrative Roadmap. When the Integration Architect has been hired, he or she will be added 111to the Documenter Team, and this charter will be updated to reflect the adjustment of roles on the 112team.113To ensure timely development of the envisioned scope (documented in section 6 below), and to 114respect the agreed-upon time commitment of Documenter Team members (documented in 115section 8 below), the primary responsibility for developing this initiatives deliverables will be 116assigned to a core group of the Documenter Team. This core group will consist of the DIS Chief 117Architect and the Integration Architect discussed in the previous paragraph. The expectation is 118that other members of the Documenter Team will serve chiefly in a review/comment capacity by 119reviewing initiative deliverables at least every other week.120As with all Documenter Teams supporting the enterprise architecture effort, this Documenter 121Team will remain open to participation by anyone in state or local government in Washington.1224.4.Coordinationwith Related Efforts123This section identifies related efforts (planned or underway) to address issues similar to the 124issues in the scope of this initiative. Preferably, representatives from these related efforts will 125serve on the initiatives Documenter Team. To the extent this is not possible, this section 126documents the strategy for coordination with these related efforts.127As documented elsewhere in this charter, this initiative will coordinate closely with the Financial 128and Administrative Systems Roadmap Program initiative.29 Page 8 of 14 9. 30Washington Enterprise Architecture Program December 14, 200531Integration Architecture Initiative CharterEA Committee DocumentVersion 1.3321295.Key Issues or Decisions to be Addressed 130The purpose of the statewide enterprise architecture is to support strategic technology decision- 131making. Consequently, enterprise architecture initiatives are chartered for the purpose of building 132a framework (or set of tools) to support important decisions.133The purpose of this section is to document the issues or decisions to be supported by the 134architectural components produced by thisinitiative. 135Thesedecisions are: 136 What is the technical architecture that will allow information systems and business 137processes to be implemented incrementally with confidence that all of the pieces will fit 138together as they come on-line? 139 What are the clear and consistent guidelines for central systems providers and line 140agencies that allow information systems to fit within the states current environment of 141common and agency "shadow systems"? 142 How can information systems be constructed to allow business process solutions to be 143composed of agency unique and central, common components? 144 What is the governance model for managing changes to the integration platform and 145interfaces hosted on that platform? 146 How should the information being exchanged at integration points be modeled so as to 147promote common understanding of information semantics? 1486.ExpectedTier One Component Scope149To provide support for making the decisions documented above, this initiativewill develop 150components in the enterprise architecture as described in this section.151This section should not be viewed as limiting the scope of the initiative; rather, it is a rough guide 152for what the initiative may accomplish.153The purpose of the first phase of each initiative is to conduct a contextual-level pass at the Tier 154One components to be evolved by the initiative. During this contextual pass, the Enterprise 155Architecture Program and the Documenter Team are expected to define the initiatives scope 156more precisely (in terms of components to be evolved.)157It is expected that this initiative will develop an Integration Domain within the Technology 158Architecture of the statewide Enterprise Architecture.159This domain will document its guiding principles, of which the following constitute an initial list: 160 Integration of systems should leverage open industry standards-based technologies 161absent a strong business case justifying a proprietary alternative. 162 Integration of systems should minimize the coupling between those systems; that is, 163integration should minimize the impact on a system of changes to systems with which it is 164integrated. 165The Integration Domain will contain Compliance Components (policies, standards,and 166guidelines) that identify technical requirements of integration and standards-basedtechnologies 167that satisfy those requirements. These requirements will include:168 Message confidentiality 169 Message non-repudiation 170 Message authentication 171 Message integrity33Page 9 of 14 10. 34Washington Enterprise Architecture Program December 14, 200535Integration Architecture Initiative CharterEA Committee DocumentVersion 1.336172 Reliable messaging 173 Auditing/logging of messages 174 Performance 175In addition, the Domain will contain Compliance Components that establish standard protocols 176and technologies for basic message exchange patterns (e.g., synchronous request-response, 177asynchronous request-response, publish-subscribe, one-way messaging, etc.)178The initiative also expects to produce guidelines (in the form of Compliance Components) for the 179software architecture of solutions purchased or built in the state enterprise. These guidelines will 180assist decision-makers in ensuring that these solutions are integration ready by providing proper 181integration points and open (but secure) interfaces to those integration points.182The initiative also expects to produce a Tier One infrastructure solution set (in the Solution 183Architecture) that provides an integration platform on top of the statewide networks. This platform 184will provide the infrastructure that integrates systems in a manner conformant to the Compliance 185Components discussed above.186The initiative also expects to develop documentation guidelines for the Tier One Information 187Architecture. These guidelines will include, at a minimum: 188 How should information exchanged at integration points be modeled to represent agreed- 189upon semantics? For example, should information structures be modeled in UML? 190 What metadata should be tracked for information structures? 191 How should services (process components) be modeled, and what metadata should be 192tracked? 193 What standards should be developed for how information structures are represented in 194messages exchanged between systems/processes? For example, should structures be 195represented in XML governed by XML Schemas? (This will overlap somewhat with 196Technology Architecture.) 197Finally, the initiative will recommend a governance model for managing changes to the integration 198platform and interfaces hosted on that platform. The initiative will seek to leverage existing IT 199governance mechanisms for this purpose, but will be clear about the unique change management 200challenges associated with system integration.201It is expected that the Financial and Administrative Systems Roadmap initiative will conduct a 202pilot test of the integration architecture developed by the Integration Architecture EA Initiative. 203This pilot test will provide valuable feedback as to the viability of the architecture, in terms of its 204ability to address effectively the decisions documented in section 5 above. It is expected that the 205Roadmap Integration Architecture Steering Committee will base its endorsement (as discussed in 206section 9 below) on successful completion of this test and incorporation of any feedback into the 207architecture.2087.PastWork on this Initiative209This section identifies any past or ongoing work in the area of this initiative, which the 210Documenter Team can use as a starting point.211The accomplishments of the Roadmap program to-dateare documented thoroughly on the 212Program website (http://www.ofm.wa.gov/roadmap/).213Several state agencies, including the Department of Social and Health Services, Department of 214Labor and Industries, and Department of Information Services, have explored integration 215architecture as part of internal agency initiatives. These discovery efforts will serve as a valuable 216foundation for this initiative.37Page 10 of 14 11. 38Washington Enterprise Architecture Program December 14, 200539Integration Architecture Initiative CharterEA Committee DocumentVersion 1.3402178.Schedule:Document Process 218This section identifies the expected schedule for the initiatives activities and deliverables in the 219Document Process.2208.1.KeyDates221This section identifies any key dates to which the initiative must align its activities. 222TheRoadmap initiative requires that a stable integration architecture be in place by July 2006. 223There are two systems implementations under consideration that will follow the Roadmap 224framework. Integration Architecture guidance to these projects is needed by early Spring 2006. 225These two implementations are:226 Employee Travel and Expense Management System (TEMS) this project is funded by 227OFM and is underway. 228 Grants and Contracts Management System this project is currently being considered by 229Ecology, CTED and OFM. It is not yet funded but the feasibility study will begin in 230December 2005. 2318.2.Timeline232This section identifies the expected delivery timeline for the initiatives deliverables. Each 233enterprise initiative must evolve architectural components (including policies, standards, and 234guidelines) in accordance with the Architecture Lifecycle documented in the Enterprise 235Architecture Programs Program Management Plan. In particular, the evolution of components 236must follow a progression through specific levels of detail.237This initiative expects to evolve components through the lifecycle levels of detail on the following 238schedule:Level of Detail Target Milestone DateContextualJanuary 1, 2006ConceptualMarch 1, 2006Logical May 1, 2006 (target, Information and Technology Architecture Components)PhysicalJuly 1, 2006 (target, Solution Architecture Components)239240Note: These target milestone dates are not promises or commitments, but targets that the 241initiative will strive to achieve. Achieving these target milestone dates will depend largely on 242successful implementation of a proposal to provide staff support to the initiative.243The Enterprise Architecture Committee and Program recognize that by its very nature, the effort 244to reach architectural milestones is difficult to predict. At the same time, the Committee and 245Program have established that the Enterprise Architecture must be in the habit of frequently 246producing valuable deliverables. Therefore, initiatives must practice effective project 247management techniques, including time boxing of objectives as needed, to remain on-track with41Page 11 of 14 12. 42Washington Enterprise Architecture Program December 14, 200543Integration Architecture Initiative CharterEA Committee DocumentVersion 1.344248this schedule. Schedule deviations must be communicated and coordinated with the Enterprise 249Architecture Committee.250It is the responsibility of the Enterprise Architecture Program to provide project management 251services to each of the Enterprise Architecture Committees initiatives and the Documenter 252Teams assigned to these initiatives. (Note that this commitment of the EA Program only applies 253to architectural aspects of initiatives.)2548.3.TimeCommitment of the Documenter Team255This section sets forth the expectations of the Enterprise Architecture Committee and the 256Enterprise Architecture Program as to what commitment of time and resources will be requested 257of team members.258Documenter Team members should expect to devote 2-4 hours per month. As noted above, the 259Enterprise Architecture Program is in the process of hiring an Integration Architect to support this 260initiatives effort to provide an integration architecture for the Financial and Administrative 261Systems Roadmap. This Integration Architect will be expected to devote 40 hours per week to 262this initiative. It is possible that up to an additional 20 hours per week of project management 263services for the initiative will be provided by the Enterprise Architecture Program.2649.Schedule:Review Process 265This section identifies the expected schedule for the initiatives activities and deliverables in the 266Review Process. Note that the Review Process need not follow the Document Process 267sequentially; some of the Review Process milestones may occur during the Document Process 268timeline.2699.1.Key Dates270This section identifies any key dates to which the initiative must align its activities. 271There are no particular key dates to which this initiative must align its activities. 2729.2.Timeline273This section identifies the expected dates on which Review Process milestones will take place. 274This section must conform to the existing ISB Policy Creation and Update Process maintained by 275MOSTD, which identifies a Comment and Review followed by an Endorsement Phase.276In addition to Customer Advisory Board (CAB) and Information Services Board (ISB) review and 277endorsement of this initiatives work-product (which is required of all EA initiatives), the Financial 278and Administrative Roadmap Integration Architecture Steering Committee will provide guidance 279to this initiative, and will review the recommended architecture to ensure that it meets the 280Roadmaps needs.45Page 12 of 14 13. 46Washington Enterprise Architecture ProgramDecember 14, 200547Integration Architecture Initiative Charter EA Committee DocumentVersion 1.348 Phase Activity (note stakeholder group)DateComment/RevisionCAB review of contextual artifacts Jan 2006 Roadmap Integration Architecture Steering Committee review of contextual artifactsCAB review of conceptual artifacts Feb 2006 Roadmap Integration Architecture Steering Committee review of conceptual artifactsCAB review of draft logical artifactsMar 2006 Roadmap Integration Architecture Steering Committee review of draft logical artifactsCAB review of logical artifactsApr 2006 Roadmap Integration Architecture Steering Committee review of logical artifactsISB review of logical artifactsMay 2006CAB review of physical artifacts Jun 2006 Roadmap Integration Architecture Steering Committee review of physical artifactsISB review of physical artifacts Aug 2006Endorsement CAB endorsement of logical artifacts May 2006 Roadmap Integration Architecture Steering Committee endorsement of logical artifactsISB endorsement of logical artifacts Jul 2006CAB endorsement of physical artifactsJul 2006 Roadmap Integration Architecture Steering Committee endorsement of physical artifactsISB endorsement of physical artifactsSep 2006 28110.Evolvinga Single, Cohesive Enterprise Architecture 282The Enterprise Architecture Committee has established the goal of having all enterpriseinitiatives 283evolve a single, cohesive Tier One Enterprise Architecture for Washington State.284Members of the Documenter Team are asked to share in this goal with the Committee and the 285Enterprise Architecture Program. The Program will provide the coordination, leadership, and49 Page 13 of 14 14. 50Washington Enterprise Architecture ProgramDecember 14, 200551Integration Architecture Initiative Charter EA Committee DocumentVersion 1.352286consulting expertise to ensure the achievement of this goal through development of standard 287architecture artifacts with standard tools and housed in a single repository. The Program will also 288ensure that artifacts from all initiatives are presented to the stakeholder community as a cohesive 289architecture, in accordance with the Programs Communications Plan.29011.Initiative Status Reporting 291The Enterprise Architecture Program will prepare an initiative status report for each Enterprise 292Architecture Committee meeting (every other Wednesday). The status report will contain, at a 293minimum:294 Status of initiative versus expected timeline for each level of detail, established above 295 Indicator of whether this status is on track or not 296 If no progress has been made on the initiative in the past two weeks, the status report will 297indicate a reason 298The Enterprise ArchitectureProgram Director will circulate the status report for review by the 299Documenter Team.30012.Initiative Sunset301This initiative will end when its deliverables are completed and accepted by the Enterprise 302Architecture Committee and Financial and Administrative Roadmap Executive Sponsors.30313.Attachments 304 This charter has made several references to the Roadmap program documentation, 305which is available online at: http://www.ofm.wa.gov/roadmap/.53Page 14 of 14