Enterprise Architecture Guide
The Enterprise Architecture Working Group Last Update: April 30th, 2013
Enterprise Architecture Guide
Page | 1 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
Introduction ................................................................................................................................................. 2
Audience .................................................................................................................................................. 2
What is Enterprise Architecture? ............................................................................................................. 2
Why do Enterprise Architecture? ............................................................................................................ 3
EA Scope .................................................................................................................................................. 3
Assumptions, Risks & Issues .................................................................................................................... 3
Guiding Principles ........................................................................................................................................ 5
The Enterprise Architecture Framework ..................................................................................................... 6
The EA Information Repository ................................................................................................................ 7
EA Models ................................................................................................................................................ 7
EA Development and Management Concepts ............................................................................................. 9
Critical Success Factors for EA Management ........................................................................................... 9
EA Services ................................................................................................................................................. 11
EA Governance .......................................................................................................................................... 14
Roles and Responsibilities – Recommendations .................................................................................... 15
EA Process Model ...................................................................................................................................... 16
Initiating EA at Waterloo ........................................................................................................................... 17
Continuous Improvement ...................................................................................................................... 17
Appendix A: Enterprise Architecture Working Group Members ............................................................... 18
References ................................................................................................................................................. 19
Revision History ......................................................................................................................................... 20
Enterprise Architecture Guide
Page | 2 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
Introduction The Enterprise Architecture Working Group (EAWG) prepared this document to guide the establishment of the Waterloo Enterprise Architecture (EA) Program. This guide provides recommendations on:
• the scope and objectives of the EA program • guiding principles for EA at Waterloo • the EA framework and methods • critical requirements and success factors for EA
The EAWG expects that an authoritative handbook for Waterloo EA will be a critical early deliverable of the permanent EA program. This document is intended to set direction and to provide lessons learned from the EA investigation that will inform such a handbook.
Disclaimer This document is not yet complete. Please direct any questions or concerns to the EAWG.
Audience The expected audience for this document includes:
• Enterprise Architects, planners and designers tasked with developing and maintaining the EA • University planners and strategists responsible for EA steering and review • Project Managers and IT and business professionals accountable for aligning and integrating
Project Management (PM) processes with EA
What is Enterprise Architecture? EA is the formal description and documentation of an enterprise. The term "enterprise” may be taken to mean any business organization -‐-‐ it may, for example, comprise a single department, or every department in a large organization. The scope of EA analysis includes, but is not limited to: enterprise components, data entities, business processes, business functions, institutional data, and the relationships among all of these. EA typically focuses on three core descriptions: the "current state" of the enterprise; its "future state", also called the "target" or "desired" state; and the roadmap or plan for achieving the future state. EA is business-‐driven and focused first on business strategy: the object is to document strategic goals and to ensure that the analyzed functions, processes, systems and enterprise components are aligned with and support the execution of that strategy. EA also expresses enterprise-‐wide standards, policies, rules and principles and expects that systems and business processes will comply with these. EA is an ongoing process; it is not something that is done once and completed. It influences and informs planning and decision-‐making and, in turn, it is reshaped and refined by the outcomes of business and IT investments that transform the underlying enterprise.
For additional information and definitions of EA please see:
http://en.wikipedia.org/wiki/Enterprise_architecture
Enterprise Architecture Guide
Page | 3 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
http://www.gartner.com/it-‐glossary/enterprise-‐architecture-‐ea/
Why do Enterprise Architecture? The main valued output of EA is information: EA provides an enterprise-‐wide information resource to inform and support IT investment and planning. Waterloo’s EA program will create a blueprint to support enterprise transformation initiatives. It will provide a rich, structured model of the university’s current state, a corresponding reference model of its target or desired state, and a roadmap detailing the steps required to evolve the enterprise from the current to the target state. The EA program also defines and enforces architectural principles, technical standards and best practices. EA captures and reflects the declared strategic goals and objectives of the enterprise and enforces the alignment of IT and business initiatives with those strategic goals. At the same time, EA encourages the adoption of a common language for describing the enterprise, its business functions and its system components, which improves communication and supports the adoption of enterprise-‐wide patterns and standards. By providing improved visibility into the state and capabilities of the enterprise, and by enforcing compliance with standards and alignment with strategy, EA improves the design, performance and value of the university’s systems and business processes. EA makes the enterprise more agile, and improves its ability to respond to change.
For more information on the EA value proposition, please see the EAWG program charter: https://sharepoint.uwaterloo.ca/sites/ITStrategicPlan/EAWG/Deliverables/Charters/EA%20Program%20Charter%20(DRAFT).pdf.
With these long-‐term goals in mind, the EAWG proposes the following scope, principles, priorities, and critical success factors for the EA program.
EA Scope By definition, EA is enterprise-‐scoped, user-‐centric, and business-‐driven. The long-‐term goal is to include all Waterloo systems, services and business processes in the EA, and to make EA-‐compliance a core requirement for every major initiative, but this will not happen overnight. It is the responsibility of the permanent EA program leadership to define how and when and with what level of detail and compliance systems and infrastructure will be incorporated into the EA. The EAWG proposes the following priorities:
1. Enterprise systems – systems critical for the university’s mission 2. Systems storing or handling sensitive data 3. Shared systems – systems shared by more than one university department or functional area 4. Departmental systems – systems that serve only a single department or functional area
Assumptions, Risks & Issues
Assumptions • A clear commitment to EA by the CIO and the university executive
Enterprise Architecture Guide
Page | 4 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
• A collaborative IT strategic planning process and a clear strategic direction for IT at Waterloo • The dedication of the Enterprise Architecture Working Group (EAWG) • Sufficient training for the EAWG to complete the investigative phase of program development • A mandate to establish a permanent EA Program with dedicated, authorized, and trained
resources accountable for the development and performance EA
Risks & Issues • Securing sufficient funding for the EA program • Dedicating sufficient skilled resources to the EA program • Obtaining approval for specialized EA consulting where necessary • Winning stakeholder support for and long-‐term commitment to EA processes and principles –
there is an abiding risk that not all faculties and business areas will adopt EA wholeheartedly and that IST will have to lead, innovate and continually demonstrate the value of EA in the hope of winning gradual buy-‐in
• EA compliance may increase timelines for project delivery • Effectively applying EA processes and methods to existing systems and projects , and integrating
EA with existing program/project management methodologies
Enterprise Architecture Guide
Page | 5 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
Guiding Principles These guiding principles are fundamental requirements and practices that the EAWG believes are critical to the long-‐term health and effectiveness of the EA program and the university’s systems environment. These principles are intended to guide EA design and practice, enterprise planning, IT investments, and information systems selection and design. These principles may be refined to meet evolving business needs, and at the discretion of the permanent EA program leadership.
Waterloo’s EA and information systems shall:
• Support the university’s strategic goals • Be collaboratively governed – i.e., EA governance is a shared responsibility of IST, the University
executive and the faculties and other departments • Focus first on users • Create and consistently apply metrics to evaluate the success of EA and IT initiatives • Enforce business rules consistently across the university • Support standards-‐based IT architecture and systems • Be flexible, to adapt to changing business needs and new technologies • Support compliance with the university's legislated mandates • Support the standardization of technology, documentation and language across the enterprise • Support single-‐sign-‐on and a single identity per user • Require that systems and components be compatible and interoperable • Favour off-‐the-‐shelf technologies over custom solutions unless formally justified (e.g., by
effectiveness or total cost of ownership) • Be cost-‐effective • Comply with vendor-‐neutral principles • Support collaboration and data sharing • Support compliance with accessibility standards – i.e., Ontarians with Disabilities Act (OADA) • Require that university data be authoritative – every data field will have an owner and system of
record • Balance the need for data protection and security with the need for user access to university
data and systems (e.g., Freedom of Information and Protection of Privacy Act, or FIPPA and Personal Information Protection and Electronic Documents Act, or PIPEDA)
Enterprise Architecture Guide
Page | 6 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
The Enterprise Architecture Framework An EA framework is an index of EA products – documents, models, and project and design artifacts – that together describe the enterprise. A framework identifies and documents the relationships between:
• Strategic goals • Enterprise assets • Business processes • Data descriptions and relationships • Applications and systems • Enterprise technologies
The EAWG completed its EA investigation using the Zachman Enterprise Architecture Framework, and we recommend the adoption of this framework as the de facto standard for Waterloo. The Zachman Framework is a widely-‐used, industry-‐standard approach to EA. It is a matrix of 36 cells – six rows and six columns.
Each row represents a distinct perspective or view of the enterprise: Scope, Business, System, Technology, Component, and Operations. Working from the top down, the rows narrow in scope and increase in detail as each perspective adds the constraints of its particular domain. Each of the six columns poses one of the classic interrogatives: What, How, Where, Who, When, and Why. Each cell contains approved document types that answer these questions at a level appropriate to each row’s perspective. The design is intended to decompose, or reverse-‐engineer, the enterprise into the simplest
Enterprise Architecture Guide
Page | 7 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
possible views, or what Zachman characterizes as primitive models. The framework facilitates the organization, classification and communication of enterprise information. It is not a methodology or a toolset; it is simply a matrix or an index, conceptually akin to the periodic table of the elements.
For additional details on the Zachman Framework, please see Zachman International: http://www.zachman.com/about-‐the-‐zachman-‐framework
The EA Information Repository The contents of the EA framework are managed in an information repository designed to work with the chosen framework. Industry-‐standard tools are available to manage the repository, but it is beyond the scope of the EAWG’s mandate to prescribe a toolset. Office tools and a SharePoint site were sufficient for the EAWG to complete its investigation. Nevertheless, even when dealing with a comparatively small set of files, the EAWG met with challenges in organizing and maintaining a provisional repository in SharePoint. It would be unwise to underestimate the headaches that could arise from less-‐than-‐robust repository maintenance tools. The permanent EA program leadership will select and implement an appropriate toolset to facilitate the population, maintenance and use of the EA framework. The repository and toolset should support/provide, at a minimum:
• An intuitive user-‐interface • Version controls for framework artifacts • Security controls to manage enterprise-‐wide access to the repository
EA Models The EAWG focused its investigative efforts on the Business Architecture domain of EA, which comprises the top two rows of the Zachman framework: the Executive and Business Management perspectives. This is a common approach for transformation initiatives. The group also followed closely the approach prescribed by the Ontario Public Service (OPS) in its EA development. The OPS takes a highly user-‐centric approach that emphasizes program and service definitions. The models prescribed for this approach focus on service outputs, value-‐chains, and end-‐user needs. Ultimately, the EA program leadership will define the models and products that support its approach to EA. Nevertheless, the EAWG endorses the models used by the OPS and encourages their adoption at Waterloo. Please see the following resources for more information on these models and their advantages:
Ontario Public Service Business Architecture examples: https://sharepoint.uwaterloo.ca/sites/ITStrategicPlan/EAWG/Shared%20Documents/Training%20and%20Reference%20Material/Gov't%20Ont%20Business%20Architecture%20examples/gedsp_ba.pdf
Ontario Public Sector Strategic Business Design: https://sharepoint.uwaterloo.ca/sites/ITStrategicPlan/EAWG/Shared%20Documents/Training%20and%20Reference%20Material/Public%20Sector%20Business%20Design%20Dec%206%202006.ppt
Canadian Government Reference Model (GCRM):
Enterprise Architecture Guide
Page | 8 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
http://www.iccs-‐isac.org/wp/library/2013/01/Canadian-‐Governments-‐Reference-‐Model-‐Version-‐1.0-‐Final.pdf
EAWG Business Architecture Models in the Zachman Framework: https://sharepoint.uwaterloo.ca/sites/ITStrategicPlan/EAWG/Shared%20Documents/Working%20Documents/Business%20Architecture%20Models%20in%20Zachman%20Framework.pptx
Model Notation and Documentation Standards Regardless of the specific forms prescribed, the EA program must define and enforce a consistent, enterprise-‐wide standard in documentation and modeling notation. Models and artifacts must also be annotated with consistent metadata so that they can be viewed and understood out of context by university stakeholders and non-‐specialists. A major aim of the program is the development of a common language for business and IT; the standardization of documentation across the university is a critical step toward achieving that goal.
The EAWG created a proposal for EA model meta-‐data notation standards: https://sharepoint.uwaterloo.ca/sites/ITStrategicPlan/EAWG/Deliverables/Zachman%20Framework%20Row%201/EAWG-‐EA_Artifact_Model.pdf
Enterprise Architecture Guide
Page | 9 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
EA Development and Management Concepts
Critical Success Factors for EA Management
Compliance • EA management provides for enforcement of enterprise-‐wide EA compliance • IT and business initiatives across the enterprise are subject to review for EA compliance • Systems and initiatives are evaluated for compliance with EA principles and standards • University PM processes and products comply with EA mandates • University PM processes and products incorporate prescribed EA models and documentation • The EA program leadership is authorized to prescribe the degree of detail, the priority, and the
measurement of compliance for different systems and initiatives • Compliance waivers are granted at the discretion of the EA program leadership, but are granted
only after thorough, formal analysis and justification, and are subject to scheduled reviews
Integration • EA principles and practices and are tightly integrated with PM and Systems Development Life
Cycle (SDLC) methodologies, enterprise planning, IT investment and steering processes • PM and systems implementations provide input to refine and evolve the EA and keep it current,
as suggested in the following diagram:
• EA integration with PM and SDLC processes is formalized, with consistent checkpoints, compliance-‐reviews and checklists, and minimum documentation standards. The Ontario Public
Enterprise Architecture Guide
Page | 10 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
Service standard offers an excellent starting point: http://www.mgs.gov.on.ca/stdprodconsume/groups/content/@mgs/@goits/documents/resourcelist/241105.pdf
Participation • The effectiveness of the EA program relies on full participation across the university • EA governance and steering includes representation from the university executive,
administration, IST and the faculties (the specifics of this representation are TBD)
Quality Control • The leadership of the EA program is accountable for the quality and integrity of EA processes
and products • EA management provides for authoritative management and maintenance of the EA knowledge
repository by the EA leadership • EA management requires authoritative, reliable and consistent measurement of:
o EA performance o IT-‐strategic alignment o EA compliance
Enterprise Architecture Guide
Page | 11 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
EA Services
Architecture review A core responsibility of the EA program leadership is to review programs, initiatives and systems for EA-‐compliance. EA-‐compliance is enforced as a critical success factor for all major initiatives and systems. The reviews are consistent, disciplined, and transparent and based on published standards. The granting of exemptions is the responsibility of the Chief Enterprise architect; this process, too, is formal, documented and transparent.
Architectural Policies & Standards To be effective, the EA program must define and enforce enterprise-‐wide standards. Technical standards encourage the implementation of applications and systems that are more maintainable, interoperable, sustainable, secure and cost-‐effective. Architectural standards provide a basis for evaluating how well IT initiatives align with institutional objectives and strategy. EA also aligns with and enforces compliance with policies and legislative mandates (e.g., FIPPA, PIPEDA, and OADA).
To encourage compliance with standards, we recommend that the EA program develop a Waterloo-‐specific Technical Reference Model, which defines architectural components and their relationships, and codifies agreement on technical standards, including: protocols, specifications, data formats, API definitions, criteria and checklists for product selection, application development best practices, etc.
Consulting The EA program functions as a “centre of excellence”, which provides knowledge, training, resources, and best practices to the university community. Enterprise-‐wide EA-‐compliance requires participation across the university, but it is led and informed by the central EA group. In this capacity, the EA program may provide advice and recommendations on matters related to EA and systems architecture and design to other areas of the university.
EA Development One of the first priorities of EA development is the definition of a target or future-‐state architecture for the university. This future-‐state architecture will evolve as the enterprise evolves – i.e., as transformation initiatives are completed and the underlying current-‐state architecture changes. The EA program is responsible for the maintenance of the current-‐ and future-‐state architectures, as well as the roadmap of transformation initiatives to carry the enterprise from current to future state. Together, these activities form the basics of EA development.
EA Reference Model An architectural reference model is an abstract framework of generic, re-‐usable design models, which together describe the components of the enterprise. The reference model provides the complete set of enterprise components: ideas, concepts, business functions, services, entities. The EAWG based much of its preliminary modeling on the Public Service Reference model used by the Ontario Public Service; this provided a decent and relevant starting point, but it does not necessarily describe perfectly the business
Enterprise Architecture Guide
Page | 12 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
of the university. The EA program is responsible for the creation and maintenance of a comprehensive reference model for the University of Waterloo. This model will describe the university’s business concerns, and enable clear and consistent description of, and communication about, everything the university “does”.
Education and Outreach The EA program creates and makes available educational and training material related to EA and EA-‐compliance. These materials must be audience-‐appropriate: executives and planners have very different EA-‐training needs from IT specialists or managers in the university’s business units. The objective is to provide those responsible for EA integration and EA compliance across the university with the information and skills they need to become compliant.
Information Management EA shapes the way in which university information, or enterprise data, is stored, collected, maintained, and accessed. EA aligns with and enforce information management procedures, e.g., data retention, destruction, and security. EA may also participate in the modeling of enterprise data itself, as part of the development of reference models that define the business entities of concern to the university. Sound information management is a critical component of EA-‐compliance review.
Methods and tools The EA program provides approved tools, methods, guidelines, best practices and documentation to assist PMs and business leaders across the university in becoming EA-‐compliant.
Repository Development and Maintenance The EA program is responsible for the creation, population, maintenance and integrity of the EA information repository. The EA team selects and uses prescribed repository maintenance tools. It defines the approved architectural models and artifacts required to populate the repository, as well as the documentation and meta-‐data standards which govern the creation of these artifacts.
EA is an iterative function that relies on feedback from enterprise initiatives. The long-‐term effectiveness of the EA program rests on how well it is integrated with project governance and PM processes across the university. If PM processes are EA-‐compliant, project initiatives will generate much of the collateral that populates the EA repository, and completed initiatives will feed back into the EA, re-‐shaping the architecture and the roadmap.
Enterprise Architecture Guide
Page | 13 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
Strategic Innovations As the lead architects, the EA group is expected to take a strong role in driving innovation and transformational change, for example, in areas such as mobile application and portal design and development, open data, and enterprise business intelligence initiatives.
Enterprise Architecture Guide
Page | 14 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
EA Governance The purpose of EA governance is to plan, manage, monitor and optimize the effectiveness of the EA program. Without effective governance, EA will never deliver its anticipated benefits. A prescriptive governance model is beyond the scope of this guide. The purpose of this section is to propose critical success factors and recommendations for the effective governance of EA at Waterloo.
Accountabilities • Accountability for the performance, alignment, integration and effectiveness of the EA program
is clearly prescribed and mandated • EA program leadership is accountable to:
o An EA Review or Steering body, responsible for overall EA-‐strategic compliance and long-‐term EA strategic planning
o An EA advisory committee or panel, with appropriate university representation, responsible for enterprise-‐wide information management, planning and investment
• The EA Review body is in turn accountable to the CIO • PMs and business leaders in IST and across campus are in turn accountable to the leadership of
the EA program for the EA compliance of their systems, assets, and initiatives
Note: The above diagram depicts formal accountabilities, not the flow of information or responsibilities. The nature of steering, for example, assumes that the EA Steering Body would provide feedback, guidance and direction to the core EA team, but the team is accountable to steering for EA performance.
Enterprise Architecture Guide
Page | 15 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
Roles and Responsibilities – Recommendations Specific prescriptions for roles, structures and responsibilities are beyond the scope of this guide, but the following are suggested as examples:
EA Steering /Review • An executive EA Steering or Review panel • Monitors the integrity, effectiveness, alignment and direction of the EA program • The EA program leadership is accountable to this body for enterprise-‐wide EA compliance and
direction
University EA Advisory Committee: • An information governance committee, with appropriate representation from the university’s
information management community (e.g., Records Management, Institutional Analysis and Planning)
CEA • The Chief Enterprise Architect (CEA) (or similar) is a dedicated leadership role with
accountability for the overall development and performance of the EA program • Responsibilities include:
o Management of the EA program o The integrity, quality, performance of EA program and its products o Provision of EA information and guidance to initiatives across campus o Review of projects and initiatives for EA compliance o Definition of measures for EA performance and alignment o Integration of EA into PM processes, with PMO o Communication of the requirements, principles and achievements of the EA program
across the university
EA Core Team • A unified EA Office, Program or Team, under the management of the CEA, and staffed with
trained, dedicated EA experts who perform the required core functions of the EA program • May or may not include delegates from across the university • Responsibilities include:
o EA modeling and analysis o Development and maintenance of the EA information repository o Creation of the EA core products: the baseline architecture, the target architecture, and
the roadmap o Collaboration with university initiatives to integrate EA tools, methods and products
• The EA program is expected to include capabilities covering the traditional sub-‐disciplines of EA: Business Architecture, Information Architecture, Application Architecture, Technology Architecture, Security Architecture – how precisely these domains are covered is TBD
Enterprise Architecture Guide
Page | 16 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
EA Process Model EA is a cyclical process. It is driven by business needs and aligned with business strategy. Both the university’s business strategy and its future state architecture are directly influenced by external and internal drivers, including trends in higher education, legislative mandates, technological innovations and developments (e.g. security concerns), and market forces. While business strategy drives innovation, EA keeps the business and technical initiatives aligned with the strategic vision. The EA Roadmap provides the sequence of priority change initiatives. The implementations, and the PM and SDLC processes and best practices that drive them, provide feedback which revises and refines the current state architecture.
Throughout this cycle, EA provides visibility and clarity; it allows planners, strategists and architects to identify those components of the enterprise that are candidates for change, as well as those that will feel the impact of change.
* This diagram is adapted from the Government of Ontario EA Process Model, which is in turn based on the model created by META Group Inc.
Enterprise Architecture Guide
Page | 17 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
Initiating EA at Waterloo Early priorities for the EA program will include:
• Initializing the EA repository • Populating the baseline or “current state” architecture • Creating the target or “future state” architecture, based in part on outcomes of the Strategic
Planning initiative now underway • Creating the roadmap to prioritize initiatives that will move the university toward its planned
future state • Planning and implementing the formal integration of EA into university PM processes
Additional priorities for the EA program (medium-‐ to long-‐term):
• Developing a reference model for how the university works • Identifying “service output types” appropriate for this reference model • Defining the models and artifacts required for each Zachman Framework cell, based on this
reference model
Continuous Improvement
Critical Success Factors For EA to remain relevant and provide optimal value it must be continually revised and refreshed to reflect and respond to the evolving enterprise. Without regular reviews and continuous improvements, EA will produce only shelfware. The EA program must establish processes and defined checkpoints to continually assess and report on the progress and effectiveness of the EA measured against:
• Industry best practices • Progress towards the University’s strategic goals • Progress toward the planned future state
Recommendations: • Scheduled EA program review to ensure:
o The current architecture is accurate o The target architecture aligns with strategic vision o The roadmap reflects strategic priorities and is realistic and achievable
Enterprise Architecture Guide
Page | 18 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
Appendix A: Enterprise Architecture Working Group Members
Name Department Role Email Dave Wallace IST Governance
and Facilitation
Dave Kibble IST, IS Governance [email protected] Andrea Chappell IST, ITMS IT Strategic
Plan Project Lead
Marg Stephenson IST, IS Project Lead [email protected] Jay Athia IAP Member [email protected] Jonathan Woodcock CPA Member [email protected] Andrea Sweet CPA Member [email protected] Pascal Calarco Library Member [email protected] Chris Halonen University Records Member [email protected] Shawn Winnington-‐Ball
IST, CSS Member shawn.winnington-‐[email protected]
Connie van Oostveen IST, IS Member [email protected] Bob Wallwork IST, IS Member [email protected] Colin Bell IST, ISS Member [email protected]
Enterprise Architecture Guide
Page | 19 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
References
1. Government of Ontario, “Enterprise Architecture Process and Methods Handbook”, 2005, https://sharepoint.uwaterloo.ca/sites/ITStrategicPlan/EAWG/Shared%20Documents/Training%20and%20Reference%20Material/EAPM-‐v3%20(2005).pdf
2. Government of Ontario, “Information & Technology Standards: Government of Ontario IT Standards (GO-‐ITS) Number 56 Appendix B”, http://www.mgs.gov.on.ca/stdprodconsume/groups/content/@mgs/@goits/documents/resourcelist/274818.pdf.
3. Government of Ontario, “Information & Technology Standards: Government of Ontario IT Standards (GO-‐ITS) Number 56 OPS Enterprise Architecture Principles and Artefacts”, http://www.mgs.gov.on.ca/stdprodconsume/groups/content/@mgs/@goits/documents/resourcelist/274814.pdf.
4. Massachusetts Institute of Technology Information Technology Architecture Group (ITAG), “Enterprise Architecture Guide”, http://web.mit.edu/itag/index.html.
5. US Department of Veteran’s Affairs, “Enterprise Architecture: Strategy, Governance, & Implementation”, http://www.enterprise-‐architecture.info/Images/Documents/DVAEAGov.pdf.
6. Wallace, Dave, Corporate Chief Technology Officer, Ontario Government, “The Enterprise Architecture Conference: Enterprise Architecture – A Blueprint for Evolving the Re-‐invention of Government”, Queens Printer, Ontario, July 25, 2003.
7. Zachman, John, http://www.zachman.com/
Enterprise Architecture Guide
Page | 20 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf
Revision History Version Date Author Revision 1.0.0 2012.12.15 EA Working Group First draft 1.1.0 2013.02.05 Bob Wallwork Revised; converted from XLS to Word;
condensed & re-‐organized 1.1.1 2013.02.25 Bob Wallwork Revised and condensed further 1.1.2 2013.02.26 Bob Wallwork Added notes and appendices, including
glossary, EAWG composition 1.1.3 2013.03 Connie Van
Oostveen Read and provided comments, edits, revisions
1.1.3 2013.03 Bob Wallwork Revised to incorporate Connie’s changes 2.0.0 2013.03.27 Bob Wallwork New organization based on Chris Halonen’s
reading of OPS EA Guide; substantial re-‐writes of existing sections; new sections added on services, process model, etc.
2.0.1 2013.04.17 Bob Wallwork Revised based on feedback from walkthrough with EAWG. Removed exec sum, glossary. Amended governance diagram. Numerous edits, links & references.
2.0.2 2013.04.30 Bob Wallwork Revised based on group feedback