UWEnterprise Architecture Guide

Enterprise
Architecture Guide

The Enterprise Architecture Working Group

Last Update: April 30th, 2013

Enterprise Architecture Guide

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

Page | 1 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


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%20
Charter%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


• 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


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)



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


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%2
0Reference%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%2
0Reference%20Material/Public%20Sector%20Business%20Design%20Dec%206%202006.ppt
Canadian Government Reference Model (GCRM):


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%20Docu
ments/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%20
Row%201/EAWG-‐EA_Artifact_Model.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


Service standard offers an excellent starting point:

http://www.mgs.gov.on.ca/stdprodconsume/groups/content/@mgs/@goits/documents/resour
celist/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



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


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.


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.



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.


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


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.


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


Appendix A: Enterprise Architecture Working Group Members

Name Department Role Email

Dave Wallace IST Governance dwallace@uwaterloo.ca
and
Facilitation
Dave Kibble IST, IS Governance dkibble@uwaterloo.ca
Andrea Chappell IST, ITMS IT Strategic andrea.chappell@uwaterloo.ca
Plan Project
Lead
Marg Stephenson IST, IS Project Lead marg.stephenson@uwaterloo.ca
Jay Athia IAP Member jathia@uwaterloo.ca
Jonathan Woodcock CPA Member jonathan.woodcock@uwaterloo.ca
Andrea Sweet CPA Member a2sweet@uwaterloo.ca
Pascal Calarco Library Member pvcalarco@uwaterloo.ca
Chris Halonen University Records Member chris.halonen@uwaterloo.ca
Shawn Winnington-‐ IST, CSS Member shawn.winnington-‐
Ball ball@uwaterloo.ca
Connie van Oostveen IST, IS Member connie.vanoostveen@uwaterloo.ca
Bob Wallwork IST, IS Member rwallwor@uwaterloo.ca
Colin Bell IST, ISS Member colin.bell@uwaterloo.ca



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”,
celist/274818.pdf.

3. Government of Ontario, “Information & Technology Standards: Government of Ontario IT
Standards (GO-‐ITS) Number 56 OPS Enterprise Architecture Principles and Artefacts”,
celist/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/



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 Read and provided comments, edits,
Oostveen 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


UWEnterprise Architecture Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UWEnterprise Architecture Guide

Uploaded by

Copyright:

Available Formats

The Enterprise Architecture Working Group

• the scope and objectives of the EA program

What is Enterprise Architecture?

For additional information and definitions of EA please see:

Why do Enterprise Architecture?

1. Enterprise systems – systems critical for the university’s mission

Assumptions, Risks & Issues

Risks & Issues

Waterloo’s EA and information systems shall:

• Support the university’s strategic goals

The Enterprise Architecture Framework

The EA Information Repository

Ontario Public Service Business Architecture examples:

Ontario Public Sector Strategic Business Design:

Canadian Government Reference Model (GCRM):

EAWG Business Architecture Models in the Zachman Framework:

Model Notation and Documentation Standards

EA Development and Management Concepts

Critical Success Factors for EA Management

Service standard offers an excellent starting point:

Page | 10 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf

Architectural Policies & Standards

Page | 11 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf

Education and Outreach

Methods and tools

Repository Development and Maintenance

Page | 12 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf

Page | 13 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf

Page | 14 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf

Roles and Responsibilities – Recommendations

University EA Advisory Committee:

Page | 15 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf

Page | 16 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf

Initiating EA at Waterloo

• Initializing the EA repository

Additional priorities for the EA program (medium-­‐ to long-­‐term):

• Developing a reference model for how the university works

• Industry best practices

Page | 17 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf

Appendix A: Enterprise Architecture Working Group Members

Name Department Role Email

Page | 18 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf

Page | 19 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf

Page | 20 http://ist.uwaterloo.ca/ea/UWEnterpriseArchitectureGuide.pdf

You might also like

Additional priorities for the EA program (medium-‐ to long-‐term):