1

2

3

4

5

6

7

8

9

10

11   Washington State Enterprise Architecture Program
12

13         Over-Arching Architect...
2Washington State Enterprise Architecture Program                                                                November ...
6Washington Enterprise Architecture Program                                             November 10, 2004
 7Over-Arching A...
9Washington Enterprise Architecture Program                                             November 10, 2004
 10Over-Arching ...
12Washington Enterprise Architecture Program                                              November 10, 2004
 13Over-Archin...
15Washington Enterprise Architecture Program                                              November 10, 2004
 16Over-Archin...
Upcoming SlideShare
Loading in …5
×

Over-Arching Principles

407 views

Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Over-Arching Principles

  1. 1. 1 2 3 4 5 6 7 8 9 10 11 Washington State Enterprise Architecture Program 12 13 Over-Arching Architecture Principles 14 Version 1.0 15 1
  2. 2. 2Washington State Enterprise Architecture Program November 10, 2004 3Over-Arching Architecture Principles ISB Approved Document—Version 1.0 4 16 November 10, 2004Table of Contents 171. Document History.......................................................................................................................2 182. Document Context......................................................................................................................2 193. Scope of the Principles in this Document....................................................................................3 204. The Commonality Principle.........................................................................................................3 215. The Business Alignment Principle..............................................................................................3 226. The Natural Boundaries Principle...............................................................................................4 237. The External Linkages Principle.................................................................................................4 248. The Scalability Principle..............................................................................................................5 259. The Security Principle.................................................................................................................5 2610. The Customer Viewpoint Principle............................................................................................5 2711. The Business Ownership Principle...........................................................................................6 2812. The Business Continuity Principle............................................................................................6 2913. The Interoperability Principle....................................................................................................6 30 31 32 33 34 1.Document History Date Version Editor Change November 10, 2004 1.0 Greg Brant Final draft for ISB approval 35 36 2.Document Context 37This document currently has ISB Approved Document status. This status signifies that the 38document has been approved by the Information Services Board (ISB). 39For more information about the Enterprise Architecture Program or the ISB Enterprise 40Architecture Committee, please visit the EA Committee website at: 41http://isb.wa.gov/committees/enterprise/index.aspx. 5 Page 2 of 6
  3. 3. 6Washington Enterprise Architecture Program November 10, 2004 7Over-Arching Architecture Principles ISB Approved Document—Version 1.0 42 3.Scope of the Principles in this Document 43The primary focus of these principles is business processes, data, and technologies of the 44Enterprise Architecture that are shared across the state (Tier One). However, when possible, the 45application of the principles to individual agency architectures, and sub-agency architectures 46(Tiers 2 & 3), improves the consistency and cohesiveness across architectures. 47 4.The Commonality Principle 48Should be common where there is a clear business case; once designated as 49common, justification is required to deviate 50Rationale 51We have decentralized approach to funding, people/resource allocation, priorities, governance 52and management, which drives to an uncommon architecture without a principle to support 53commonality. 54The greater the number of agencies that use the Enterprise Architecture the greater the ability of 55agencies to leverage each other's IT investments. 56Implications: 57Enterprise Architecture has an obligation to ensure there is a good business case for including a 58process, data, or technology in Tier One. 59Agencies should have good business case for deviations from process, data, or technology in 60Tier One. 61Mandatory compliance may be required for some processes, data, or technologies that have 62strong risk implications to the state (e.g. some security components). 63The Enterprise Architecture process should be designed to encourage participation from a broad 64range of agencies. 65May require change in funding approach. 66 5.The Business Alignment Principle 67Should align projects and investments based on Priorities of Government (POG) 68Rationale: 69The State has articulated a set of priorities that guide where to focus our efforts. Information 70technology decisions need to be driven by these business priorities. 71Implications: 72Enterprise Architecture decisions will be made with the strongest alignment to the Priorities of 73Government possible. 74Many POG-related activities will require participation from Communities of Interest in order to be 75successful. The perspective of these Communities of Interest should be considered when 76making Enterprise Architecture decisions. 8 Page 3 of 6
  4. 4. 9Washington Enterprise Architecture Program November 10, 2004 10Over-Arching Architecture Principles ISB Approved Document—Version 1.0 77 78 6.The Natural Boundaries Principle 79Should be designed around natural boundaries. 80Rationale: 81Achieving the ability to view state government as a single enterprise requires the ability to 82effectively integrate systems as needed. Systems with well defined, natural boundaries aid in 83integration. 84Implications: 85In order to meet its mandate in a timely manner, the state will need to leverage and use all of its 86available resources including the existing environment. 87Within the boundaries of an "Information System", tight coupling streamlines business processes. 88Between "Information Systems", loose coupling allows open, plug and play approach. 89Requires definitions of what is in and out of scope of statewide "Information Systems". 90Requires enterprise-level business and data modeling. 91 7.The External Linkages Principle 92Should facilitate linkages with external partners 93Rationale: 94Achieving results at less cost through creative budget solutions may require increased partnering 95with external entities. 96Many of the approaches and techniques used for linking with external entities can also be used 97within the state to improve our ability to consolidate similar activities in different agencies. 98Improved linkages to external partners can improve services to citizens. 99Implications: 100Will have security implications (more granular – connectivity and sharing without compromising 101own security.) 102May require migration to open or industry standards. 103May require some enterprise level metadata. 104Systems should be constructed with clearly defined interfaces. 105Inter-system communication mechanisms (e.g. messaging infrastructure) become more 106important. 11 Page 4 of 6
  5. 5. 12Washington Enterprise Architecture Program November 10, 2004 13Over-Arching Architecture Principles ISB Approved Document—Version 1.0 1078.The Scalability Principle 108Should be scalable to support different size organizations and loads and handle 109growth or decline in business levels. 110Rationale: 111Spending reprioritization, program elimination, or consolidation of similar activities in different 112agencies may require systems to scale up or down to support changes in business level. 113Implications: 114May affect charge-back model. 115May impact user interface choices. 116Will require flexibility to support different business processes. 117Will require strong capacity planning scope or model. 118 119 9.The Security Principle 120Should protect information assets 121Rationale: 122Citizens look to government to play a key role in safeguarding both their physical security, and 123their personal information. 124Implications: 125Will require more enterprise-level security “minimum-level thresholds” to prevent “weakest links” 126from compromising security for all. 127May require consistent business rules. 128May require broader risk analysis. 129May require layers of security. 130 10.The Customer Viewpoint Principle 131Should be designed around the customers viewpoint and provide a consistent 132customer experience 133Rationale: 134State government is increasingly required to be viewed as a single enterprise. 135Implications: 136May support functions like single sign-on, one-stop shopping, and common payment options for 137customers. 138May require numerous systems to shift from a transactional model to a more customer-centric 139model. 140Will require additional understanding of customer usage patterns. 141May require additional “look and feel” standards and compliance. 142May require an enterprise portal strategy. 143Should facilitate access for all users. 14 Page 5 of 6
  6. 6. 15Washington Enterprise Architecture Program November 10, 2004 16Over-Arching Architecture Principles ISB Approved Document—Version 1.0 144 11.The Business Ownership Principle 145Should have a clear business owner 146Rationale: 147The Architecture will need to accommodate the constant changes that impact the services the 148State delivers, and how the State delivers those services. Understanding who owns which piece 149of the architecture helps ensure those most affected by those changes are involved up front. 150Implications: 151High-Level Business Process and Data modeling needs to occur in order to determine ownership. 152Business leadership needs to be involved in order to accept ownership. 153As components are added to the architecture they should include owner as an attribute. 154 12.The Business Continuity Principle 155Should be designed and implemented in a way that minimizes interruptions to 156service 157Rationale: 158Citizens expect government to take the appropriate measures to ensure government services 159won’t be interrupted. 160Implications: 161An enterprise view of Disaster Recovery and Business Continuity will need to be developed. 162 13.The Interoperability Principle 163Should enable interoperability 164Rationale: 165Interoperability will be required to support critical government initiatives such as Homeland 166Security or Public Safety. 167Interoperability will be required to support business drivers such as the ability to view state 168government as a single enterprise, and the ability to consolidate similar functions. 169Interoperability facilitates data sharing between internal and external partners. This supports 170streamlining processes, improving service and reducing costs. 171Implications: 172Will have security implications. 173May require migration to open or industry standards. 174 17 Page 6 of 6

×