1

2

3

4

5

6

7

8

9

10

11   Washington State Enterprise Architecture Program
12

13       Integration Architecture...
2Washington State Enterprise Architecture Program                                                                   Decemb...
6Washington Enterprise Architecture Program                                                 December 14, 2005
7Integration...
10Washington Enterprise Architecture Program                                            December 14, 2005
11Integration Ar...
14Washington Enterprise Architecture Program                                               December 14, 2005
 15Integratio...
18Washington Enterprise Architecture Program                                             December 14, 2005
 19Integration ...
22Washington Enterprise Architecture Program                                           December 14, 2005
23Integration Arc...
26Washington Enterprise Architecture Program                                             December 14, 2005
 27Integration ...
30Washington Enterprise Architecture Program                                               December 14, 2005
 31Integratio...
34Washington Enterprise Architecture Program                                             December 14, 2005
 35Integration ...
38Washington Enterprise Architecture Program                                               December 14, 2005
 39Integratio...
42Washington Enterprise Architecture Program                                               December 14, 2005
 43Integratio...
46Washington Enterprise Architecture Program                                                December 14, 2005
 47Integrati...
50Washington Enterprise Architecture Program                                              December 14, 2005
 51Integration...
Upcoming SlideShare
Loading in …5
×

charter

769 views
689 views

Published on

Published in: Education, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
769
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
26
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

charter

  1. 1. 1 2 3 4 5 6 7 8 9 10 11 Washington State Enterprise Architecture Program 12 13 Integration Architecture Initiative Charter 14 EA Committee Document 15 Version 1.3 16 1
  2. 2. 2Washington State Enterprise Architecture Program December 14, 2005 3Integration Architecture Initiative Charter EA Committee Document—Version 1.3 4 17 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 40 41 42 431.Document History 44 Date Version Editor Change October 5, 2005 1.0 Dennis Jones Initial Draft Scott Came November 30, 2005 1.1 Dennis Jones • Reflection of steering committee and documenter team Scott Came membership • New format 5 Page 2 of 14
  3. 3. 6Washington Enterprise Architecture Program December 14, 2005 7Integration Architecture Initiative Charter EA Committee Document—Version 1.3 8 Date Version Editor Change December 9, 2005 1.2 Scott Came • Initiative name changed from “Financial/Admin Services” per Laura Parma EAC direction 11/30 • Removal of Roadmap governance sections and Roadmap Integration Architecture steering committee December 14, 2005 1.3 Scott Came • Modifications to address Roadmap initiative stakeholders needs December 21, 2005 1.3 Scott Came • Adopted by EA Committee 45 462.Document Context 47This document currently has EA Committee Document status. This status signifies that the 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. 4. 10Washington Enterprise Architecture Program December 14, 2005 11Integration Architecture Initiative Charter EA Committee Document—Version 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 60Roadmap’s needs. However, this initiative’s 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 Architecture’s 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 Stewards 73Each initiative 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 77initiative’s 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. 79The Committee stewards for this initiative are: 80 • Laura Parma, Assistant Director, Department of Information Services 814.2.Business Sponsorship 82This 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 Team 87Each 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 91“Documenter Team” originates from the Documenter role in the NASCIO Enterprise Architecture 92framework; this is to signify that the team’s 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. 13 Page 4 of 14
  5. 5. 14Washington Enterprise Architecture Program December 14, 2005 15Integration Architecture Initiative Charter EA Committee Document—Version 1.3 16 95Each Documenter Team should ensure that the following roles are sufficiently covered. (These 96roles 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 not 98assigned responsibility for making decisions. Rather, the Documenter Team’s responsibility is to 99draft recommended components that are then reviewed, endorsed, and approved within the 100Review process, as documented in section 9 below. Role Definition/Purpose Executive 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 team Subject-Matter Provides technical expertise in the initiative’s 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 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 Architect 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 team’s artifacts to central EA repository Provides coordination across Documenter Teams Authors artifacts (supported by SME and Policy Advisor) 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 Supports SME and Architect in authoring of artifacts other than Compliance Components Provides policy-oriented coordination across Documenter Teams 101 17 Page 5 of 14
  6. 6. 18Washington Enterprise Architecture Program December 14, 2005 19Integration Architecture Initiative Charter EA Committee Document—Version 1.3 20 102The 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. Member Title Phone contact Team role Organization Email contact Bill Norris Chief Architect (360) 236-4426 SME Department of bill.norris@doh.wa.gov Health Brian Everson Information (360) 705-5396 SME Technology Brian.Everson@wsp.wa.gov Architect Washington State Patrol Dan Mercer Chief Architect (360) 902-6003 SME Department of merc235@lni.wa.gov Labor and Industries Debbie Johnson The Higher (360) 753-7893 SME Education DebbieJ@hecb.wa.gov Coordinating Board Gary Dubuque Enterprise (360) 586-7981 SME Architecture garyd@dor.wa.gov Department of Revenue Jeff Sharp Office of the State (360) SME Treasurer jeff@tre.wa.gov Jerry Britcher Chief Architect (360) 902-7550 SME Department of britcjc@dshs.wa.gov Social and Health Services Jim Eby IT Manager (360) 902-2303 SME Department of ebyjre@dfw.wa.gov Fish and Wildlife 21 Page 6 of 14
  7. 7. 22Washington Enterprise Architecture Program December 14, 2005 23Integration Architecture Initiative Charter EA Committee Document—Version 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.gov Coordination Laura Graham Chief Architect graham.laura@leg.wa.gov SME Legislative Service Center Laura Parma Assistant Director (360) 725-5321 Executive Sponsor Department of LauraP@dis.wa.gov Information Services Lori Bame Senior (360) 786-6115 SME Applications bame_lo@leg.wa.gov Consultant LEAP Committee Lorraine Network Specialist (360) 725-8493 SME Louderback Department of lklouderback@doc1.wa.gov Corrections Lyle Tillet Department of (360) 664-7106 SME Retirement LyleT@drs.wa.gov Systems Matt Stevens Enterprise (360) 902-3221 SME Security Services matts@dis.wa.gov Analyst Department of Information Services Mike Rohrbach Administrative (360) 705-5246 SME Office of the mike.rohrbach@courts.wa.gov Courts Miles Neale Department of (360) 407-6592 SME Ecology mnea461@ecy.wa.gov Paul Hubert Department of (360) 725-5309 SME 25 Page 7 of 14
  8. 8. 26Washington Enterprise Architecture Program December 14, 2005 27Integration Architecture Initiative Charter EA Committee Document—Version 1.3 28 Information paulh@dis.wa.gov Services Robin Griggs Chief Architect (360) 664-6537 SME Department of rgriggs@dol.wa.gov Licensing Tom Henderson Integration (360) 902-5861 SME Architect hent235@lni.wa.gov Department of Labor and Industries Scott Came Chief Architect (360) 902-3519 SME Department of scottca@dis.wa.gov Project Manager Information Architect Services TBD Department of Policy Advisor Information Services 107 108The 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 initiative’s 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.Coordination with Related Efforts 123This 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 initiative’s 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. 9. 30Washington Enterprise Architecture Program December 14, 2005 31Integration Architecture Initiative Charter EA Committee Document—Version 1.3 32 1295.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 this initiative. 135These decisions are: 136 • What is the technical architecture that will allow information systems and business 137 processes to be implemented incrementally with confidence that all of the pieces will fit 138 together as they come on-line? 139 • What are the clear and consistent guidelines for central systems providers and line 140 agencies that allow information systems to fit within the states current environment of 141 common and agency "shadow systems"? 142 • How can information systems be constructed to allow business process solutions to be 143 composed of agency unique and central, common components? 144 • What is the governance model for managing changes to the integration platform and 145 interfaces hosted on that platform? 146 • How should the information being exchanged at integration points be modeled so as to 147 promote common understanding of information semantics? 1486.Expected Tier One Component Scope 149To provide support for making the decisions documented above, this initiative will 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 initiative’s 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 161 absent a strong business case justifying a proprietary alternative. 162 • Integration of systems should minimize the coupling between those systems; that is, 163 integration should minimize the impact on a system of changes to systems with which it is 164 integrated. 165The Integration Domain will contain Compliance Components (policies, standards, and 166guidelines) that identify technical requirements of integration and standards-based technologies 167that satisfy those requirements. These requirements will include: 168 • Message confidentiality 169 • Message non-repudiation 170 • Message authentication 171 • Message integrity 33 Page 9 of 14
  10. 10. 34Washington Enterprise Architecture Program December 14, 2005 35Integration Architecture Initiative Charter EA Committee Document—Version 1.3 36 172 • 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- 189 upon 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 192 tracked? 193 • What standards should be developed for how information structures are represented in 194 messages exchanged between systems/processes? For example, should structures be 195 represented in XML governed by XML Schemas? (This will overlap somewhat with 196 Technology 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.Past Work on this Initiative 209This 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-date are 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. 37 Page 10 of 14
  11. 11. 38Washington Enterprise Architecture Program December 14, 2005 39Integration Architecture Initiative Charter EA Committee Document—Version 1.3 40 2178.Schedule: Document Process 218This section identifies the expected schedule for the initiative’s activities and deliverables in the 219Document Process. 2208.1.Key Dates 221This section identifies any key dates to which the initiative must align its activities. 222The Roadmap 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 227 OFM and is underway. 228 • Grants and Contracts Management System – this project is currently being considered by 229 Ecology, CTED and OFM. It is not yet funded but the feasibility study will begin in 230 December 2005. 2318.2.Timeline 232This section identifies the expected delivery timeline for the initiative’s deliverables. Each 233enterprise initiative must evolve architectural components (including policies, standards, and 234guidelines) in accordance with the Architecture Lifecycle documented in the Enterprise 235Architecture Program’s 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 Date Contextual January 1, 2006 Conceptual March 1, 2006 Logical May 1, 2006 (target, Information and Technology Architecture Components) Physical July 1, 2006 (target, Solution Architecture Components) 239 240Note: 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 with 41 Page 11 of 14
  12. 12. 42Washington Enterprise Architecture Program December 14, 2005 43Integration Architecture Initiative Charter EA Committee Document—Version 1.3 44 248this 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 Committee’s 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.Time Commitment of the Documenter Team 255This 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 260initiative’s 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 initiative’s 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 Dates 270This 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.Timeline 273This 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 initiative’s 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 280Roadmap’s needs. 45 Page 12 of 14
  13. 13. 46Washington Enterprise Architecture Program December 14, 2005 47Integration Architecture Initiative Charter EA Committee Document—Version 1.3 48 Phase Activity (note stakeholder group) Date Comment/Revision CAB review of contextual artifacts Jan 2006 Roadmap Integration Architecture Steering Committee review of contextual artifacts CAB review of conceptual artifacts Feb 2006 Roadmap Integration Architecture Steering Committee review of conceptual artifacts CAB review of draft logical artifacts Mar 2006 Roadmap Integration Architecture Steering Committee review of draft logical artifacts CAB review of logical artifacts Apr 2006 Roadmap Integration Architecture Steering Committee review of logical artifacts ISB review of logical artifacts May 2006 CAB review of physical artifacts Jun 2006 Roadmap Integration Architecture Steering Committee review of physical artifacts ISB review of physical artifacts Aug 2006 Endorsement CAB endorsement of logical artifacts May 2006 Roadmap Integration Architecture Steering Committee endorsement of logical artifacts ISB endorsement of logical artifacts Jul 2006 CAB endorsement of physical artifacts Jul 2006 Roadmap Integration Architecture Steering Committee endorsement of physical artifacts ISB endorsement of physical artifacts Sep 2006 28110.Evolving a Single, Cohesive Enterprise Architecture 282The Enterprise Architecture Committee has established the goal of having all enterprise initiatives 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, and 49 Page 13 of 14
  14. 14. 50Washington Enterprise Architecture Program December 14, 2005 51Integration Architecture Initiative Charter EA Committee Document—Version 1.3 52 286consulting 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 Program’s 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 297 indicate a reason 298The Enterprise Architecture Program Director will circulate the status report for review by the 299Documenter Team. 30012.Initiative Sunset 301This 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, 305 which is available online at: http://www.ofm.wa.gov/roadmap/. 53 Page 14 of 14

×