1. art and entertainment
2. visual art and design
3. architecture

State of Vermont Enterprise Architecture Framework
(VEAF)
Guidebook for Standards and Methods
Level 0
Version 2.1 May 2014
VEAF Guidebook
State of Vermont
Revision History
Version
Date
Organization /
Point of Contact
Description of Changes
1.0
2/4/2014
J. Hunt
Initial Version
2.0
4/7/2014
c. Bradley
Formatting and reworking content
2.1
5/6/2014
C. Bradley
Editing Formatting consistent with
other VEAF documents. Aligned
components with HSE VEAF HSEP
Strategy Documents.
CONTENTS
Executive Summary....................................................................................................................................... 6
Value of the Enterprise Architecture Office ........................................................................................... 6
Introduction .................................................................................................................................................. 8
Chapter 1 - Background ................................................................................................................................ 8
Enterprise Architecture Definition ......................................................................................................... 9
Scope .................................................................................................................................................... 10
In Scope .......................................................................................................................................... 10
Out of Scope................................................................................................................................... 10
Approach .............................................................................................................................................. 10
Governance .................................................................................................................................... 11
Business ......................................................................................................................................... 11
Application ..................................................................................................................................... 11
Information .................................................................................................................................... 11
Technology ..................................................................................................................................... 12
EA Strategy ..................................................................................................................................... 12
Domain Levels of Understanding ................................................................................................... 12
Focus..................................................................................................................................................... 12
Benefits of VEAF ................................................................................................................................... 13
Chapter 2 - VEAF Organization and Administration ................................................................................... 13
Organizational Roles & Management Responsibilities ........................................................................ 13
Architecture Owner ....................................................................................................................... 13
2|Page
VEAF Guidebook
State of Vermont
Enterprise Architecture Office ....................................................................................................... 14
Enterprise Architect ....................................................................................................................... 15
Communications Plan ........................................................................................................................... 15
Chapter 3 - Enterprise Architecture Office as a Center of Excellence ........................................................ 17
Architecture Governance Processes .................................................................................................... 18
Identification of Stakeholders across the organization ................................................................. 18
Manage Best Practices ................................................................................................................... 19
Architecture Documentation Process ............................................................................................ 19
Architecture Review Process ......................................................................................................... 19
Architecture Communication Process ........................................................................................... 19
Architecture Compliance Process .................................................................................................. 19
Architecture Sustainability Management ...................................................................................... 20
Architecture Change Management Process .................................................................................. 20
Chapter 4 - Business Drivers ....................................................................................................................... 20
Background........................................................................................................................................... 20
Enterprise Business Drivers .................................................................................................................. 21
Chapter 5 - Technology Trends ................................................................................................................... 22
Enterprise Information Technology Trends.......................................................................................... 22
Chapter 6 - Principles .................................................................................................................................. 24
Guiding Principles of an Agency ........................................................................................................... 26
Chapter 7 - Enterprise Best Practices.......................................................................................................... 27
Enterprise Architecture must be an in-sourced effort ......................................................................... 27
IT resources must be focused on the agency’s mission ....................................................................... 27
The State will use a standard set of proven technologies.................................................................... 27
Technology selection will consider the ability to support systems ...................................................... 28
Governance of enterprise architecture will be centralized.................................................................. 28
The State will balance the needs of privacy and accessibly ................................................................. 28
Chapter 8 - Business Unit Considerations and the Importance of Non-Functional Requirements ............ 28
The NON-Functional Requirements Document.................................................................................... 29
Operational Considerations.................................................................................................................. 29
Business problem as articulated by the Business Lead ........................................................................ 30
Chapter 9 - Adapting the Architecture Development Method (ADM) for Business Units within the State
of Vermont .................................................................................................................................................. 31
Preliminary Framework and Principles ................................................................................................ 32
3|Page
VEAF Guidebook
State of Vermont
Sustainability Management Model ...................................................................................................... 33
Project Design and Implementation..................................................................................................... 33
Demonstrable Effectiveness ................................................................................................................. 33
Financial Resources .............................................................................................................................. 34
Business Earned Value Technique ........................................................................................................ 34
Components ......................................................................................................................................... 35
BU Architecture Assessments (ADM Phases A through E) ................................................................... 36
BU Migration Planning into the EA....................................................................................................... 36
BU / EA Governance and Principles...................................................................................................... 37
BU / EA Change Management Communication Methods .................................................................... 37
Chapter 10 - BU Requirements Management and the Requirements Repository. .................................... 40
Special Note on the Oracle SOA Repository. ........................................................................................ 42
BU Architecture Model Conclusion ...................................................................................................... 43
Chapter 11 - EA Documentation Requirements (Artifacts) for Architecture Models ................................. 44
Application of Views and Viewpoints ................................................................................................... 44
Documentation Requirements ............................................................................................................. 44
ISO/IEC/IEEE 42010 Architecture Description Template for collecting Artifacts ................................. 46
Chapter 12 - Conclusion .............................................................................................................................. 47
Supplemental .............................................................................................................................................. 48
Appendix A – State of Vermont HSEP Liscenced Products ................................................................... 48
4|Page
VEAF Guidebook
State of Vermont
Table of Figures
Figure 1- B-A-I-T, Governance and Strategy ............................................................................................... 11
Figure 3- EA Center of Excellence for SOA .................................................................................................. 18
Figure 5- Business Domain Principle Map................................................................................................... 26
Figure 6- Technology Domain Principle Map .............................................................................................. 27
Figure 9 Phases for Vermont Architecture Development Process Based on ADM from Open Group ....... 32
Figure 10 Change Control Method for Vermont EA and BU ....................................................................... 39
Figure 11 Architecture Repository .............................................................................................................. 41
Figure 12 Content of the Architecture Description .................................................................................... 46
5|Page
VEAF Guidebook
State of Vermont
EXECUTIVE SUMMARY
This is a guidebook, as such it is meant to guide readers through an overview of the State of Vermont
Architecture Framework (VEAF). It presents a brief method for directing the guidance, development,
and best practices for the administration of the State of VEAF platform.
The purpose of this document is to foster an appreciation of why Enterprise Architecture is needed, the
sphere of technical influence it governs and how the framework is used by the business to meets meet
and satisfies their mission.
VALUE OF THE ENTERPRISE ARCHITECTURE OFFICE
The nature of data processing has changed greatly in recent years. Today’s system users have more
computing power at their desktops than mainframes had just a decade ago. Each year, new and better
applications, software, hardware and peripherals are being developed. Each advance offers new
opportunities to increase processing capability and improve service to constituents of the State of
Vermont.
Every change state agencies or departments make to parts of a system, whether to take advantage of
new technologies or to respond to business changes, potentially affects many other parts of the
statewide IT portfolio. Furthermore, the systems built today must be capable of integrating with those
that are built tomorrow. VEAF is adaptable to such change yet it demands detailed plans, processes and
the commitment of all stakeholders across the organization.
VEAF is a complete expression of the enterprise; a master plan which acts as a collaboration force
between aspects of business and technology -- unifying both into a single goal. All the individual
components of the architecture to be used in the development of systems and must also ensure that
those components work together for the benefit of the whole.
The standards and guidelines governing VEAF will serve to support those who are making technologybased decisions for the State of Vermont. Rather than resorting to out-of-context, ad-hoc studies to
facilitate strategic IT decision making, IT Managers can look to the VEAF for guidance and direction to
capitalize on the technologies of the future while preserving today's investments. The goal is to enable
the State of Vermont to optimize its systems and make the whole greater than the sum of its parts. By
encouraging standardization of products and processes that are compatible with the architecture and by
providing guidance to planners, designers and implementers, VEAF represents a major step toward
optimal, cost-effective resource utilization.
6|Page
VEAF Guidebook
State of Vermont
Figure 1 VEAF Enterprise Architecture
7|Page
VEAF Guidebook
State of Vermont
INTRODUCTION
State of Vermont Enterprise Architecture Framework (VEAF) is an approach to Enterprise Architecture
based on The Open Group Architecture Framework (TOGAF) and Oracle Enterprise Architecture
Framework (OEAF). This chapter identifies the background and business case for architecture as well as
an architecture definition, scope of the architecture effort, approach to the architecture program, a
definition of program deliverables, and the focus of the effort.
CHAPTER 1 - BACKGROUND
In January of 2013, the State of Vermont Information
Technology Strategic Plan 2013-2018 was published. This
plan outlines Vermont’s IT vision for the next five years. The
opening executive summary, called out Department of
Information and Innovation’s (DII) mission, goals and
resources required, and strategic principles which are listed
below:
The goal of state-wide Enterprise
Architecture is to enhance
coordination, simplify integration,
and build a consistent
infrastructure.
Department of Information and Innovation’s Mission:
To improve state government effectiveness and productivity, the Department of Information and
Innovation provides expertise, standards and shared services for the state enterprise and supports
agency and/or department-specific IT.
Department of Innovation’s Goals and Resources Required (estimates for 2013 – 2018):

Modernize critical technologies (IT) - $430M (roughly 90% non-state funding) over 5 years

Ensure sustainability of IT capabilities - $ 13M over 5 years

Operate IT effectively - estimated $350M - $500M 2over 5 years

Enable productivity improvement throughout government - $ 35M over 5 years
Department of Innovation’s Strategic Principles:

Leverage IT successes in other States

Leverage shared services and cloud-based IT

Leverage modern IT delivery frameworks

Align the technology workforce to adapt to IT trends

Couple IT with business process optimization

Optimize IT investments via Enterprise Architecture (EA), Project Management (PM), and Project
Portfolio Management (PPM) methodologies.
Strategic principle six specifically calls for the optimization of IT Investments via enterprise architecture
methodologies and as such legitimizes the VEAF endeavor. The goals of VEAF focus on the business first,
enhancing coordination of efforts between the business and IT, simplifying integration, building a
consistent infrastructure, and generally allowing for greater efficiencies in the development of
technology solutions. The intent of VEAF is to realize these goals while ensuring the effective use of
8|Page
VEAF Guidebook
State of Vermont
state resources, thereby enabling consistent, effective delivery of services to Vermonters, State of
Vermont employees, vendors, and the businesses of Vermont.
Enterprise Architecture covers the broad spectrum of the strategic and operational capabilities of an
organization. This includes business, application, information, and technology domains. Technology
environments include networks, applications, databases, messaging, interfacing, middleware, security,
operations and other relevant architecture disciplines. Guidelines will be developed to facilitate access
and consolidation, provide security, eliminate duplication and help ensure that solutions are extensible,
scalable, and more easily integrated.
The pervasive use of the Internet is the primary driver of Enterprise Architecture. Citizens have come to
expect services to be provided through the Internet and the state must be capable of responding to
those demands. There are currently several departmental websites that provide information or services.
However, there is a broader need to provide integrated statewide services. The current state egovernment initiative will provide the first opportunities to establish architectural standards. Future egovernment initiatives will be developed in conjunction with standards that will become part of the
Enterprise Architecture.
Adopting Enterprise Architectural standards will require an ongoing commitment by the state. But with
the evolution of new products, technology trends, business trends, and user demands will require a
consistent architectural standards to ensure ongoing system stability. Compliance with architectural
standards will continue to evolve over time.
The result of adopting consistent EA standards will allow for more effective use of state resources and a
more efficient delivery of services.
ENTERPRISE ARCHITECTURE DEFINITION
In order to develop Enterprise Architecture (EA), there must be a
common understanding of the term “EA”. EA is a strategic information
asset base, which defines the mission, the information necessary to
perform the mission, the technologies necessary to perform the
mission, and the transformational processes for implementing new
technologies in response to changing mission needs (Schekkerman). 1
An EA includes baseline enterprise architecture, target enterprise
architecture and a transition plan. The EA is managed by governance
and principle methodologies documented and introduced as guidelines
for the support of the business mission.
The need for
sustainable business
and IT operations is
one of the primary
drivers of Enterprise
Architecture.
EA encompasses functional and operational aspects of the organization it describes. A complete
enterprise architecture description serves multiple purposes, among them:

Understanding, rationalizing, and mapping key business capabilities to their supporting
technology components. These technology components may change over time.
1
Schekkerman, Jaap. Enterprise Architecture Good Practices Guide. Trafford: Vancouver
BC, 2008
9|Page
VEAF Guidebook
State of Vermont

Breaking down the complexity of the supporting IT systems so that developers can analyze and
design components that are relatively isolated from one another without compromising their
ability to integrate them

Analyzing the functionality so that required technical components (or infrastructure) can be
identified

Assisting in the analysis of service-level requirements so that the means of delivering them can
be designed

Providing a basis for the specifications of the physical computer systems on which the IT system
will execute, and providing the basis for the mapping of components onto these computer
systems

The architecture efforts within the State of Vermont are intended to identify and document
existing systems, infrastructure, and components, as well as the blueprint for the development
of new systems, components, applications, and major modifications to existing systems.
SCOPE
Managing the scope of the VEAF is essential to its success. The scope
of the VEAF is defined by the business operations and processes
organizations most impacted by technology and where the adoption
of the architecture is most influential.
In Scope
Information technology
architecture is a strategic
issue that must be
addressed.
The VEAF encompasses the Executive, Legislative and Judicial
branches of state government.
Out of Scope
Vermont Higher Education and local governmental entities are outside the scope of this Enterprise
Architecture program.
However, where these other government entities are impacted, along with those organizations that do
business with the State, compliance to VEAF definitions, drivers, governance and principles are enacted
and enforced.
APPROACH
Over the past few years, business demands have caused the State information technology divisions and
State government leaders to consider information technology architecture for both current and future
technologies. A framework needed to be adopted that would allow business units within the State to
turn to VEAF for assistance in achieving their respective mission statements and goals.
Using The Open Group Architectural Framework (TOGAF) and Oracle Enterprise Architecture Framework
(OEAF) as a baseline, VEAF follows industry standards and principles. These standards and principles
guide all activities of VEAF and its strategic IT plan. DII also developed organizational roles, management
responsibilities, to complement VEAF. The organizational roles and responsibilities define how the
Enterprise Architecture is maintained and managed. The processes define how the architecture’s vitality
is maintained and how governance determines what part of the architecture becomes accepted, revised
or rejected.
10 | P a g e
VEAF Guidebook
State of Vermont
The following key architecture domains drive the VEAF program: Business, Application, Information, and
Technology. These domains are embraced by Governance and the Enterprise Architecture Strategy. For
the purposes of the Vermont Health Connect, The Agency of Human Services primarily drives the
business side. As designs, decisions, and other details are gathered and documented; the resulting
artifacts are captured and stored in the EA repository for future use and modification as needed.
In our current implementation, Business, Application, Information, and Technology (B-A-I-T) domains are
managed by Governance and EA Strategy.
Figure 2- B-A-I-T, Governance and Strategy
Governance
Indicates the overall enterprise governance that is required across all domains. It includes a Center of
Excellence (CoE) and Change Control Board (CCB). The function of Governance is to review and approve
any potential exceptions to the enterprise within the guidelines of the overall strategy of the State.
Business
Has ownership of components and processes is related to the VEAF Development, Security and
Management. Governance guides the relationship among all domains. The Business domain is
responsible for the following: Mission and Goals, Critical Success Factors, Business Capabilities, Business
Process and Design, Requirements, Rules and Organization.
Application
The Application Domain involves the following: EA Integration, Custom Application Development,
Service Definitions, Process alignments, and Services Architectures.
Information
As its name suggests, is data centric. This domain involves the following: Data Integration, Data
Architecture, Master Data Management (MDM), Metadata Management, Data Delivery, Business
Intelligence (BI) and Analytics, Enterprise Reporting and Performance Management, Data Quality and
Modeling, and Content Management.
11 | P a g e
VEAF Guidebook
State of Vermont
Technology
Focuses on hardware and Operating System (OS). This domain covers servers, network and network
appliances, telephony, OS, computers (desktop, laptop, and virtual), middleware, Database(s), Security
applications or devices, Storage systems, mobile portability and, Cloud Services.
EA Strategy
Concerns itself with the enterprise strategy that the State of Vermont is employing to leverage best
practices, provide reusable business services and guidance to vendors during implementation according
to the enterprise architecture standards adopted by the state.
Domain Levels of Understanding
The capabilities of the business, application, information, and technology domains can be understood on
multiple levels. This document is meant to function at level 0 and 1, providing a high level overview of
VEAF, without concerning itself with the details of individual systems or applications.
Level 0 – Capability Mapping for Business , Application , Information , and Technology Architectures
Level 0
Business Capabilities
Application Capabilities
Information Capabilities
Technology Capabilities
Level 1 – Map Business Processes to Application, Information, and Technology Support Models
Level 1
Business Processes,
Business Sub-Processes
Business Services &
Generic Application
Services mapping
App Diagrams,
Capability Model, Tech
Support Model, &
Product Mapping
Data Object Support
Mapping
Data Integration Model
Data Context
Technical Capability
Model &
Product Mapping
Level 2 – Component View
Level 2
Application Component
View
ERD Diagram
Integration Support Model
Technology Component
View & Logical Operational
Reference Architecture
Level 3 – Functional Requirements
Level 3
Product Application Services
Level 4 – Technical Requirements
Level 4
Product Technical Architecture
Figure 3 The Five Levels of Understanding
FOCUS
The State of Vermont recognizes that the development of Enterprise Architecture is a long term, ongoing process. The approach taken by the State of Vermont describes architecture as an adaptable, and
12 | P a g e
VEAF Guidebook
State of Vermont
evolving process providing continuous alignment between the business of state government and
technology. The current focus of VEAF is the Agency for Human Services.
Nonetheless, VEAF functions with a view to adaptability and vitality by engaging with other business
units within the State, offering high level technical expertise as to the suitability of a Business Domain’s
functionality within the EA.
BENEFITS OF VEAF
Fundamentally, the framework of EA provides a “generic problem space and common vocabulary within
which individuals can cooperate to solve a specific business problem.” (Schekkerman, p. 59).
Frameworks are guidance tools. As mentioned in the Approach above the framework for VEAF is based
on TOGAF and OEAF. The specific benefits of VEAF are listed below.

VEAF provides an enterprise-wide IT vision that supports business objectives.

It implements best practices and principles resulting in efficient, rapid responses to emerging
business needs.

It reduces expenditures by lower development, support and maintenance costs.

VEAF creates reusable pattern of architecture which minimize costs.

Provides an Enterprise Architecture with a clear strategy for procurement and migration.

VEAF offers a consistent framework providing for better return on existing investment and
supports future technology decisions.
CHAPTER 2 - VEAF ORGANIZATION AND ADMINISTRATION
This chapter identifies the administration aspects of VEAF. They include architecture governance, roles
and responsibilities, and the governance processes. These, in conjunction with strategic plans, project
management, and risk assessment requirements, will ensure the architecture remains viable and
supports the business of the State.
ORGANIZATIONAL ROLES & MANAGEMENT RESPONSIBILITIES
The support of Enterprise Architecture requires the involvement of personnel in a variety of roles and
responsibilities. The VEAF has identified the roles and organizational duties at both the State and
departmental level. The following provides a narrative description of the identified roles and
responsibilities.
Architecture Owner
The Architecture Owner is an executive manager with the authority and responsibility for the State’s
technology direction and owns the Enterprise Architecture. This position exists on two levels; The State
of Vermont CIO acts as the manager of technology and architecture from a statewide perspective. The
State of Vermont Chief Technology Officer (CTO) acts as the Architecture Owner at the department
level.
13 | P a g e
VEAF Guidebook
State of Vermont
ARCHITECTURE OWNER RESPONSIBILITIES
Supporting Enterprise
Architecture requires the
involvement of personnel in a
variety of roles and
responsibilities across the entire
organization.

Champions the value and effectiveness of the Enterprise
Architecture

Ensures that the on-going implementation of architecture is
successful

Continuously demonstrates the benefits of the Enterprise
Architecture

Ensures applications and services conform to the Enterprise Architecture

Promotes understanding and acceptance of the Enterprise Architecture

Assures appropriate resources are available and assigned to architecture roles

Ensures quality and currency of the architecture

Appoints an Architecture Office to oversee the use, maintenance and communication of the
architecture

Maintains particular focus on managing the architecture principles
Enterprise Architecture Office
The Enterprise Architecture Office is managed by the State CTO. The office oversees the development of
the VEAF, and is responsible for the use, maintenance and communication of the CAP at the enterprise
level. The CTO has been appointed by the CIO to chair and operate the Enterprise Architecture Office.
ARCHITECTURE OFFICE RESPONSIBILITIES

Maintains a focus on managing the Architecture Governance processes

Implements and manages a compliance process to ensure the conformance of IT deployment
projects to the Enterprise Architecture

Implements and manages a vitality process to ensure the currency and accuracy of the
Enterprise Architecture

Implements and manages a communication plan

Educates application developers, users, and management on Enterprise Architecture

Ensures all committees function appropriately and effectively and with a consistent
methodology

Educates facilitators and domain committee members on the methodology

Establishes and manages architecture targets and measurements

Establishes and manages the architecture implementation plan

Develops and maintains the architecture templates used by each domain

Acts as a liaison to other governmental entities and coordinates efforts with external standardssetting bodies
14 | P a g e
VEAF Guidebook
State of Vermont
Enterprise Architect
The Enterprise Architect, as a member of the Enterprise Architecture Office, is responsible for the use
and communication of the Enterprise Architecture (e.g. principles, processes, components) on behalf of
the Architecture Owner at the department level. The CTO will assign Enterprise Architects to work with
departments on assessing needs, offering assistance in communication and education as to what the
VEAF offers, while adhering to the governance and principles guiding VEAF.
Agencies have the latitude to refine the components within their domain, and the EA will incorporate
into the architecture. As authorized an EA may reject or require enhancements to components from the
Agency in order to adhere to the governance and principles of the Architecture.
ENTERPRISE ARCHITECT RESPONSIBILITIES WITH RESPECT TO AN
AGENCY
The Enterprise Architecture Office
provides a central focal point for
ensuring the vitality of the IT
architecture, overseeing architecture
management processes at the
statewide level.

Establishes and manages a departmental
compliance process to ensure the conformance
of IT deployment projects to the Enterprise
Architecture

Establishes and manages a communication plan
within the department

Provides education on the Enterprise Architecture to application developers, users and
management

Establishes and manages architecture targets and measurements

Establishes and manages the architecture implementation plan

Manages the physical storage and dissemination of the departmental architecture contents

Maintains a focus on managing the department’s integration with the VAEA governance
processes.

Maintains a liaison relationship with the Architecture Office

Participates as a technical member of the Center of Excellence (CoE) along with the business
members
ENTERPRISE ARCHITECT DOMAIN RESPONSIBILITIES

Develops and maintains domain content in the Architecture Blueprint

Assist statewide Architecture Review Committee with compliance studies, product reviews, and
architecture change/help requests

Provide guidance to departments on domain-specific architecture issues

Provide technical assistance and recommendations on architecture issues
COMMUNICATIONS PLAN
Enterprise Architecture contains large volumes of complex and inter-dependent information. Effective
communication of information to the right stakeholders a critical to success. An agreed upon
15 | P a g e
VEAF Guidebook
State of Vermont
communication plan with a well-defined set of roles, responsibilities and processes needs to be outlined
at the beginning of any project involving the Enterprise.
The Enterprise Architect and the Business Unit are responsible for approving the initial target
architecture of a project. The EA, using the guidance of the architecture principles, seeks to move the
business toward their solution through a managed and deliberative process using a communication plan.
The typical contents of a communication plan are:
1. Stakeholder identification
2. Organization of communication needs and mechanisms such as meetings, repositories, and
access to shared documents.
3. Identification and creation of foundational business documents such as charters, business
drivers, business goals, and business strategies.
4. Identification of KPIs (Key Performance Indicators)
5. Identification of upfront risks
Once a communication plan is established, the Enterprise Architect and the
Business Unit are able to more effectively act as a team, engaging areas of
the business impacted by the project. The team acts with authority to
commit resources and make and enforce decisions within their respective
organizations.
The State of Vermont
Enterprise
Architecture is
governed by a welldefined set of roles, As with the architecture, communication must be well managed to ensure
the effectiveness of the overall architecture.
responsibilities, and
The EA Governance process is used as the guide for the communication
processes.
plan. Governance is identified as an integral part of the overall strategy
used to implement technology solutions within the state. EA Governance is
closely aligned with Business Strategic Planning, IT Strategic Planning, IT
deployment, Project Management and Risk Assessment. (3)
The State of Vermont has identified these specific principles that govern the development of a
communication plan between the Enterprise Architecture group and the Business.
1. Wide Participation – wide participation by stakeholders throughout the business unit ensures
that the Enterprise Architecture will meet the optimal requirements of the line of business
2. Common Data Definitions and Vocabulary – Having a common taxonomy across the business
with respect to the Enterprise Architecture will ease the ability to integrate new technologies
into the business
3. Strategic Focus – EA Governance strives to fulfill the strategic requirements of individual
agencies and the state as a whole. This is achieved through the identification of metrics that
align the EA with the business strategy.
16 | P a g e
VEAF Guidebook
State of Vermont
Commissioner
Commissioner
Dotted lines show communication
lines between EA and Business Units
Business Units
(Agencies and
Departments)
Business Drivers, Business
Objectives, Business Processes,
Business Rules. SLA to Providers,
Vermonters, business entities,
functional and non-functional
business requirements
Business UAT
Business Practices
and Policies
CIO
CTO
Enterprise
Architects
Lead
Governance,
Enterprise
Principles,
Monitoring,
Education and
Compliance
E-PMO
EA OFFICE
Functions as a
team: Comprised
of CTO and
Enterprise
Architects
Business Analysts
Figure 4- EA and Business Communication Flow and Responsibilities
CHAPTER 3 - ENTERPRISE ARCHITECTURE OFFICE AS A CENTER OF EXCELLENCE
The Enterprise Architecture Office by reason of its commission from the State and the talent contained
therein, is a Center of Excellence (CoE) for Technology for the State of Vermont.
The Enterprise Architecture CoE is in place not only to help develop EA strategy, but to build awareness
for, evangelize, and implement best practices for enterprise architecture. The AE CoE identifies gaps and
training needs, offering a baseline for building governance and structure. This is critical for the maturity
of the Enterprise Architecture as it expands with time. The objective of this EA CoE is to build a user
community of EA subject matter experts (SMEs) and IT strategists that share enterprise architecture
information and knowledge throughout State Agencies.
The Enterprise Architecture Office’s mission is to support methodologies, standards, governance
processes, manage a service registry, and document repository. The main goal of this core group is to
establish best practices at design time that maximizes the reusability of applications and services.
The CoE includes a vision statement, domain goals, best practices, technology trends, and technology
standards. These documents expand and contract on an as needed basis with respect to the Business
17 | P a g e
VEAF Guidebook
State of Vermont
Domain and it relation to the Enterprise Domains. In the example of Service Oriented Architecture
(SOA) for the HBE, the CoE shows how the relations among the CTO and the EAs interact with the
Business Domains, fostering clear lines of communication and activities. This model exemplifies an EA
CoE for SOA. (Figure 54)
Figure 5- EA Center of Excellence for SOA
ARCHITECTURE GOVERNANCE PROCESSES
The Architecture Governance
processes are an integral part of
the overall IT management
processes.
The Architecture Governance processes are an integral part of
the overall IT management processes used to implement
technology solutions within the State. Good Enterprise
Architecture is required for successfully implementing,
developing, and managing the State’s Enterprise Architecture.
Governance is the rapt attention to the detail, principles, and standards of Enterprise Architecture.
Governance guides the organization to a realization of its Goals and to ultimately success. Below are the
primary processes necessary to govern the Enterprise Architecture Center of Excellence.
Identification of Stakeholders across the organization
In any architecture process, it is important to identify stakeholders at all parts of the organization in
order to ensure that all applicable views and viewpoint are represented. This will provide a more
holistic view of the architecture.
18 | P a g e
VEAF Guidebook
State of Vermont
Manage Best Practices
Best practices are discussed in depth in Chapter 7 of this document. As a center of excellence it is
necessary for the Enterprise Architecture Office to maintain and update best practices on an ongoing
basis.
Architecture Documentation Process
The goal of the Architecture Documentation Process is to produce the Architecture Blueprint. The
Architecture Blueprint articulates the State’s architecture,
showing classifications for products and compliances as
emerging, current, twilight, and sunset. Products and
compliances are also denoted as accepted or rejected during the
creation and review of the Architecture Blueprint. This
documentation process produces a wealth of information can be
drawn to aid agencies in determining technology solutions.
The Architecture Blueprint articulates
the State’s architecture, showing
classifications for products and
compliances as emerging, current,
twilight, and sunset.
Architecture Review Process
The review process allows the Enterprise Architecture Office to review, debate, discuss, and decide on
the various additions and changes to the Architecture Blueprint. It is also the process that determines
which variances will be accepted into the State’s technology portfolio.
Architecture Communication Process
The purpose of this process is to ensure that all users of the architecture understand the objectives of
the architecture blueprint and its significance to the State of Vermont. All users must have access to the
latest version of the architecture document in order to make educated decisions about future business
and technology. This requires that a mechanism must exist to communicate to all users in order to
ensure that their activities will be synchronized with the blueprint. The document must also be available
to contractors and vendors who expect to do business with the state. In many instances they will be
required to conform to the state’s architecture.
Architecture Compliance Process
The State of Vermont IT community has undertaken the development of Enterprise Architecture with
the understanding that it is tactically sound approach to managing information technology from a
statewide perspective. With general consensus achieved, it is assumed that compliance will be a
voluntary process. Agencies will adhere to defined architectural strategies because it is an expedient,
efficient and globally accepted.
However, there will exist circumstances that will preclude the use of the documented standards. A
formal compliance process exists to allow for the review and acceptance of variances from statewide
architecture. Agencies will be allowed to submit deviations. These deviations should be presented with
an appropriate business case stating the reasons for the variance. Business cases will be reviewed and
approved variances will be documented.
The approval process includes a variety of interests and community perspectives including business
needs, IT strategies, budgetary views, and legislative activities. Agencies should either work toward
making their initiatives compliant, or work towards refining standards. The architecture is not intended
to restrict organizations, but rather to enhance coordination and integration, to simplify
19 | P a g e
VEAF Guidebook
State of Vermont
implementation, to build a consistent infrastructure, and to promote interoperability providing for
greater efficiencies.
Architecture Sustainability Management
Architecture sustainability management describes the
The architecture is not intended
process by which new business strategies and requirements
to restrict organizations but
are incorporated into the organization. Through this process
rather to enhance coordination
architecture is enhanced and updated, bringing in new
and integration.
technologies, solutions, and designs. These developments
need to be incorporated into the enterprise architecture, and
the architecture governance process needs to ensure that
project innovations are appropriate and suitable for the enterprise architecture context.
Sustainability management is not concerned specifically with the design and delivery of solutions
in itself.
At a minimum, sustainability reviews should occur every four to six months as a best practice.
Architecture Change Management Process
Change Management addresses the impacts of the processes, organizational structure, relationships and
responsibilities associated with the creation of an enterprise-wide technology architecture. It does not
address changes to the Architecture Blueprint itself. The Change Management Process defines how
changes to the architecture are addressed and how the VEAF will be kept.
The Change Management Process is defined and controlled by the Enterprise Architecture Office and
may initiate change management actions.
CHAPTER 4 - BUSINESS DRIVERS
A key factor in developing an adaptive statewide Enterprise Architecture is the understanding of the
enterprise business drivers of Vermont state government. The enterprise business drivers document the
direction of the enterprise in order to help to ensure that the application of information technology
supports the business of the State. A successful Adaptive Enterprise Architecture will include both
business and technical architecture components. Both are equally important and define the roles and
processes utilized to document the specific architecture.
BACKGROUND
To expedite the definition of the technical architecture, one of the initial tasks undertaken by the State
in its effort to define Enterprise Architecture was to streamline the development of the enterprise
business drivers that guide information technology projects. The State utilized existing business strategic
plans and working groups with government leaders to document these business drivers. The initial set of
business drivers were documented in 2002. In January of 2004, the Architecture Review Committee
updated the business drivers, as well as the principles, best practices, and technology trends for the
State. Follow-on efforts to the development of the technical architecture will likely include
documentation of the business architecture including the roles, processes, and schedules that ensure
the accuracy and vitality of the business perspective of the State.
20 | P a g e
VEAF Guidebook
State of Vermont
ENTERPRISE BUSINESS DRIVERS
The Enterprise Business Drivers describe the business strategies of
Vermont state government, and documents the business direction
of the enterprise. They help to ensure that the application of IT
support the business of the State. The following list identifies a
sample of enterprise business drivers as developed and
documented by the state.
Enterprise business drivers
document the business
direction of the enterprise
1. The State of Vermont will make information easily accessible and readily available as needed
and wherever needed, for both the citizens of Vermont and the employees. Citizens currently
expect to get direct access to government services. In particular, the high availability of
information is becoming more and more necessary.
2. The State will deliver services in a fiscally accountable fashion. Vermont is a balanced budget
government with a constitutional limit on the collecting of taxes and the spending of taxes
collected.
3. Citizens of Vermont are becoming increasingly aware of new service delivery models. As citizens
demand for “faster, better, cheaper” service increases, it will be necessary for the State to
provide those services in innovative ways to produce maximum benefit.
4. In order to provide expanded services, the State of Vermont must collect increasing amounts of
personal information. As a result, it will be necessary for the State to put in place a means to
respect and protect the privacy of its citizens.
5. All state agencies must cooperate and collaborate in delivering their services. The citizens of
Vermont have increased expectations as to the sharing and availability of their personal data. In
other words, once it is given to an agency, they expect all agencies to have ready access to it this
providing them faster and better services.
6. The State will develop processes that allow its services to be delivered as closely as possible to
the citizen. Wide varieties of services are available and must be delivered to the citizens in a
manner that doesn’t impose inconvenience nor require the citizen’s presence at the central seat
of the government.
7. The State must continually provide high quality services quicker. As business models for service
delivery continue to mature through all categories of industry and government, the levels of
citizen expectations continue to rise.
8. As government services become increasingly available, it will be necessary for the state to
communicate and market those services throughout the entire state, so that all citizens receive
the benefits to which they are entitled.
9. As Vermont government moves from older process models to 21st century process models,
information technology will be a critical success factor in the creation, maintenance and delivery
of services to all citizens.
10. The current business model under which Vermont State Government functions was adopted in
the mid-1970’s. Reorganization of this model to better arrange and provide services is highly
probable under future administrations. This newer model is speculated to coordinate business
21 | P a g e
VEAF Guidebook
State of Vermont
units through similar “Pillars of Government”, such as Benefits Based, Justice & Public Safety,
Education, Regulatory & Administration, and Transportation & Engineering.
11. Homeland Security efforts require the State of Vermont to take a proactive approach in
protecting Vermont’s citizens and securing the State's IT assets and data. This will ensure
Vermont Government will continue after a natural or man-made disaster.
CHAPTER 5 - TECHNOLOGY TRENDS
Technology trends within the industry may have a significant impact on business, architecture, and the
deployment of information technology within state government. Identifying and tracking the progress of
these trends coupled with an awareness of their impact will allow IT decision makers to develop more
informed, effective decisions.
Some key questions that should be asked include the
following:
Technology trends can have a significant
impact on the business and architecture
requirements of state government.

What trends and events will drive new
business investment in IT?

What technology advances or changes will
impact IT deployment decision?

How can the State exploit IT while facing a complex and volatile environment?
The technology trends identified apply to the enterprise view of architecture. Each individual domain
should have technology trends identified that are specific to that domain. These trends should be
continually assessed for potential impacts to both the business and architecture.
ENTERPRISE INFORMATION TECHNOLOGY TRENDS
The following is a list that groups together a sample of trends coupled with potential decisions that
could potentially mitigate the impact of these trends.
1. Government will still experience a shortfall in obtaining highly skilled, motivated staff due to budget
constraints and out-sourcing options.

Successful agencies will focus in retaining, training, retooling, and uplifting existing staff.

Government will establish an increased emphasis on human capital management (HCM).

Leading-edge jurisdictions will replace initial recruitment, retention, and training efforts with a
holistic approach to human capital management, ultimately affecting sourcing and recruitment
strategies.
22 | P a g e
VEAF Guidebook
State of Vermont
2. The increasing failure of traditional software development methods and financial and resource
constraints combined with “time-to-market flexibility”, is producing fundamentally new techniques
for the execution of IT projects.

Buy vs. Build
o

Turnkey or tailored commercial off-the-shelf (COTS) solutions are increasing.
Component-based Development
o
Planned Reuse & COTS subcomponents
o
Emphasis on consolidation and uniformity for common business practices
o
Rather than customize applications, governments will focus greater attention on
standardizing traditional government business processes.
o
Object-Oriented Methods and Technologies
3. Enterprises are using new technologies to reduce administration costs and establish a unified
system management approach for corporate computing.

Return to Centrally Administered Computing

Network and System Management Tools

Server-centric Business Operations

Enterprise desire to reassert centralized control of IT

Mainframe mindset exploiting latest client/server technology
4. Unified management and governed evolution of the Enterprise Architecture will become a dominant
best practice even where asset ownership is federated. Federated architectures will focus on
supporting common business infrastructure initiatives across semi-autonomous business units.

The state must leverage buying power.

Collaboration between business units is imperative.
5. Tension between citizens’ security and right to privacy will become increasingly significant. Securing
IT assets and developing a comprehensive security and privacy architecture are required by 80%+ of
public sector CIOs. Privacy/security mandates will require CIOs to re-evaluate existing practices in
light of the physical and digital security requirements for federal, state, local, and international
government interfaces.
6. Evolution from Vendor Contracting to Vendor Partnerships will evolve.

Those vendors who develop true partnerships with the public sector during a down economy
will emerge as the winners.

Savvy vendors will sacrifice short-term profits for long-term, enterprise contractual agreements.

Vendors will gain ground by bundling product offerings.
23 | P a g e
VEAF Guidebook
State of Vermont
7. E-Government Slows

E-government” will be refocused on e-employees, where more immediate returns can be
realized.

The “re-facing” of e-government will allow time for establishing the foundation.

The “e” in e-government will be downsized, as reflected in the downsizing of government
budgets.

Minimal expansion of e-government services will occur Focus will be on rationalizing and
improving existing transactions (and their ease of use) across each jurisdiction.

Data sharing, ERP investments, and consolidation rationalization will provide a foundation for
reinvigorating e-government service offerings.
8. A service-oriented architecture is emerging due to the enablement of web-services and increased
accessibility and usage of all access channels.
9. The portal will be a cost of doing business, with frameworks broaching G2E, G2B, G2G, and G2C
requirements and providing content, process automation, integration, development, knowledge,
and collaboration management capabilities. Portal frameworks will provide comprehensive facilities
for interfaces (personalization, visualization, navigation) and application delivery (e.g., Web services
location, development, integration).
CHAPTER 6 - PRINCIPLES
The Enterprise Architecture Principles are general rules and guidelines, intended to be enduring and
seldom amended. Principles inform and support the way in which an organization sets about fulfilling its
mission. Principles are the general rules which hold true across the architecture.
Likewise, Domain Principles are the underlying general rules that hold true across a specific domain
Principles define the spirit of the architecture by capturing the thinking behind it. Domain Principles
form the core values of architectural decision making for an organization. These principles are derived
from The Open Group Architecture Framework (TOGAF) principle catalog as well as the Oracle
Enterprise Architecture Framework (OEAF).
In their turn, principles may be just one element in a structured set of ideas that collectively define and
guide the organization, from values through to actions and results.
Every Enterprise Architecture Principle follows a template based on TOGAF. This ensures a high degree
of quality and adaptation regardless of Agency business domain.
Enterprise Architecture principles have been identified along with the motivation and implication for
each. These statements provide rationale for adhering to the principles, serve as a starting point for
difficult evaluations and decisions, and guide the design and selection of technology components.
24 | P a g e
VEAF Guidebook
State of Vermont
The format of a principle should follow the example below.
Name
<Name of Principle>
Reference
<Unique identifier for the principle>
Statement
The Statement should succinctly and unambiguously communicate the fundamental rule. For the most part,
the principles statements for managing information are similar from one organization to the next. It is vital
that the principles statement be unambiguous.
Rationale
The Rationale should highlight the business benefits of adhering to the principle, using business terminology.
Point to the similarity of information and technology principles to the principles governing business
operations. Also describe the relationship to other principles, and the intentions regarding a balanced
interpretation. Describe situations where one principle would be given precedence or carry more weight than
another for making a decision.
Implications
The Implications should highlight the requirements, both for the business and IT, for carrying out the principle
– in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or
practices would be incongruent with the principle upon adoption. The impact to the business and
consequences of adopting a principle should be clearly stated. The reader should readily discern the answer
to: “How does this affect me?” It is important not to oversimplify, trivialize, or judge the merit of the impact.
Some of the implications will be identified as potential impacts only, and may be speculative rather than fully
analyzed.
Principles have been grouped into related categories. These principles apply across the enterprise. As
domains are developed, references to these overarching principles should be made where appropriate
and conflicts with these principles should be addressed.
Currently the Enterprise Architecture Group manages 85 named principles listed below. (Details
provided in XLS Workbook EAGOV-009 EA Principles)
Design for Reusability
(Common Use
Applications)
Focus on User Needs
Implement Security
Compliance (Security &
Regulatory Compliance)
Service Oriented
Architecture
Aligned and
Comprehensive
Enhance Decisionsupport
Accountability and
Transparency
Information Asset
Management
Compliance to
Enterprise Architecture
Master Data
Management
(Authoritative
Information Sources)
Effectiveness
Just Enough, Just in
Time
Comply with EA
Service Abstraction
Service Autonomy
Service Description
Service Discoverability
Service Harvesting
Standard Data Exchange
Formats
Service Loose Coupling
Utilize Advanced Data
Analytics
Service policy
enforcement
Service re-use
Service monitoring
Control Technical
Diversity
Open Process
Cost Optimization
Simplicity and
Consistency
Done is Better than
Perfect
Strategic Focus
Value & Risk
Classification
Wide Participation
Data Security
Common Data
Definition & Vocabulary
Data Stewardship
Standard Service
Contract
Information
Accessibility
Access via Services
Maximize Benefit to
Enterprise
Optimize for
Sustainability
Optimize Process and
Increase Accountability
Primacy of Principles
Compliance with Laws
and Regulations
Data Quality
Measurement for
Quality
Metadata Driven
Service security
"Automate SOA
governance processes"
Avoid Point-to-Point
Integrations
25 | P a g e
VEAF Guidebook
Business-level Services
Concurrent Service
Versions
Conform to
organization's
governance
Event Processing
Graceful Service
Migration
"Identified governance
stakeholders"
State of Vermont
Opaque Service
Implementation
Adhere to Open
Standards
Platform Independence
Availability
"Provider & consumer
contracts"
Ensure Architectural
Quality Attributes
(Performance &
Scalability)
Service Contract
Service metadata
SOA governance must
promote the alignment
of business and IT
Location Transparency
SOA Reference
Architecture is required
Logical Data
Representation
"Tailor SOA governance
processes"
Normalized Data
Formats
Technical Orchestration
Management
Automation
Virtualization & Cloud
Computing
Configuration over
Customization
Interoperability
Security as a Service
SSO and Identity
Federation across
Domains
Secure Web Services
Secure Management of
Security Information
Active Threat Detection
& Analysis
Secure, Complete Audit
Trail
Data Security
System Availability
Defense in Depth
Least Privilege
GUIDING PRINCIPLES OF AN AGENCY
Guiding Principles govern the business, agency and the entire organization. EA Guiding Principles govern
the implementation of how business principles are mapped and aligned with the CIO, CTO and other
business managers.
Using HBE as an example, EA Guiding Principles identify how a principle is mapped to 2013 Technology
Goals, the Governor’s Vision, and long term Department of Information and Innovation (DII) Strategic
Principles for 2013-2018.
For instance, Cost Optimization is a Business Principle from the Business Domain. It is defined as the
government and its agencies shall provide applicants with the lowest total cost for services rendered by
improving efficiencies and streamlining core operational processes. Yet, when mapped to the core EA
Principles for 2013 Technology goals Cost Optimization allows for the modernization and effective
sustainable technology to support the business.
The Business Domain Principle Map in relation to Technology Strategic Principles for 2013-2018 follows
the pattern in Figure 65.
Figure 6- Business Domain Principle Map
26 | P a g e
VEAF Guidebook
State of Vermont
Likewise the Technology Domain Principle Map shows technology specific principles as related to the
2013-2018 strategy. Figure 6
Figure 7- Technology Domain Principle Map
CHAPTER 7 - ENTERPRISE BEST PRACTICES
Best Practices identify industry processes related to the implementation of the architecture that will
assist in the maintenance and expansion of an adaptive statewide technical architecture. They apply to
the enterprise-wide concept of architecture. Each domain should identify and document best practices
relevant to that specific domain.
ENTERPRISE ARCHITECTURE MUST BE AN IN-SOURCED EFFORT
Architecture should be a core function of IT within the State as it comprises principles based on the
business needs of the enterprise and should guide the deployment of IT resources within the enterprise.
The State must protect the Architecture from undue influence by external partners. It may accept
external assistance, but ultimately architecture decisions should be led by the Architecture Office. Even
when outsourcing operations, the architectural direction must be set internally.
Enterprise Architecture governance will require significant commitment of resources.
IT RESOURCES MUST BE FOCUSED ON THE AGENCY’S MISSION
When resources are focused, it maximizes their value. New IT skills are often expensive to obtain and
difficult to acquire, because of this IT must be responsive to changing technologies and core business
processes. These must be a process to insure alignment between IT and business goals.
Non-core areas are candidates for outsourcing and decisions on specialization in cross functional
systems must have collaboration between agencies.
THE STATE WILL USE A STANDARD SET OF PROVEN TECHNOLOGIES
IT efforts need to focus on the business enterprise, improving interoperability and eliminating
technology silos. The goal of this is to ensure a stable long term technology and application
environment.
27 | P a g e
VEAF Guidebook
State of Vermont
In order to facilitate long term stability, IT must ensure compliance via a rigorous selection criteria and
utilize a standards process during procurement. This will limit choices via the architecture blueprint by
taking into consideration an enterprise-wide view when selecting technologies. By considering the
impacts to the enterprise to individual operations, and avoiding the undue proliferation of technologies,
IT will be able to ensure long term stability against short term efficiency.
TECHNOLOGY SELECTION WILL CONSIDER THE ABILITY TO SUPPORT SYSTEMS
By building in systems management into technology evaluation, IT will be able to help reduce the risk to
the business presented by new applications and technologies. By selecting supportable technologies IT
can better protect existing technology investments and ensure the effective deployment of technology
resources.
Considering systems management my limit the choice of IT solutions, and will require a champion in
senior management, as it will involve investment in systems management processes and technologies.
In return, this investment will increase system consistency, share ability and accessibility, providing
effective IT solutions that achieve desired public policy outcomes.
GOVERNANCE OF ENTERPRISE ARCHITECTURE WILL BE CENTRALIZED
The Enterprise Architecture Office will support common business infrastructure initiatives across
business units. This will require clear lines of communication with EAs and the business as the public
sector experiences above-average difficulty with EA governance.
Governance will play a huge role as e-government programs grow due to citizen demand.
THE STATE WILL BALANCE THE NEEDS OF PRIVACY AND ACCESSIBLY
Security implementations have bypassed the assessment of privacy policies, which must serve as their
foundation. Tensions between citizen’s security and right to privacy will become increasingly important.
Privacy and security mandates will require CIO’s to regularly re-evaluate existing practices in light of
digital and physical security requirements. It will be necessary to enhance and in some cases re-write
applications to ensure security of personal information and the state’s assets.
CHAPTER 8 - BUSINESS UNIT CONSIDERATIONS AND THE IMPORTANCE OF NONFUNCTIONAL REQUIREMENTS
Systems and technology vary widely throughout the Agencies and Divisions within the State of Vermont.
SOA (Service Oriented Architecture) is an architecture style for creating business solutions while
fostering business agility. The goal is to continuously improve business results, enable flexibility and
cost-effectiveness with existing business practices.
There are general principles which govern SOA. They are listed here as a guideline for business leaders.
These principles are used during the RFP process, but should be followed throughout the entire
Enterprise Architecture project.
1. Well defined Service Contract
2. Define Services with Appropriate Granularity. These items will appear in a Non-Functional
Requirements Catalog during the RFP process. The Enterprise Architecture Program hosts all
current NFRs used for the Enterprise.
28 | P a g e
VEAF Guidebook
State of Vermont
3. Service Statelessness should be a goal.
4. Services have appropriate Security and Enforcement Standards
5. Adoption of SOA Vocabulary – will facilitate communication between the Architecture Office
and the Business Unit.
THE NON-FUNCTIONAL REQUIREMENTS DOCUMENT
Functionality is important, of course. But if you don't consider non-functional requirements, then the
solution could very well be practically useless. Non-functional requirements are those that don't
necessarily address "I want my system to do this," but instead address "How do I make this system work
in the real world".
NFRs generally follow the ISO/IEC 9126 definitions for software quality. They are specific or implied
properties. An NFR should outline with some detail the suitability of the service being requested by the
business and how the enterprise attains that goal. Issues related to reliability, usability, efficiency,
maintainability, and portability.
The NFR is a way to show how the architecture, practically and realistically, addresses the services
performed by the business through the Enterprise.
OPERATIONAL CONSIDERATIONS2
It is critical to Define Metrics (including Key Business Performance Indicators) at the commencement of
mapping any business process to the Enterprise Architecture. Metrics are essential for the continuous
communication and justification of SOA engagement. What starts with a baseline measurement (which
might be put in a business case), will be measured at appropriate intervals and reported. Here a few
metrics are suggested. Most, if not all, of these are outlined in the NFR Document during the RFP
Process.
As a best-practice, it is wise to continually refer to these metrics during the development,
implementation and deployment of each service.

Application Usage: What is the actual usage of an application, before and after implementation
of SOA on the business. SOA can lead to a service which can be used by many more consumers
than in the current state. This change can be measured if there is a baseline.

Cost Reduction: Define various cost factors; e.g., maintenance, license, energy, etc. The ratio
between relevant cost factors also need to be taken in to consideration; e.g., the ratio in IT
budget between the projects supporting business growth initiatives and the projects for (legacy)
maintenance.

Functional Re-use: Define and measure functional re-use before and after the evolution of
service-enabling business functionality. The metrics need to be measured and reported across
business silos.

Quality of Service: Quality of Service (e.g., service up/downtime, message throughput) is part of
Service-Level Agreement (SLA) monitoring and should include appropriate performance-related
key performance indicators
2
http://www.opengroup.org/soa/source-book/l2soa/best-practices.htm
29 | P a g e
VEAF Guidebook
State of Vermont

Revenue-generated: Creation of services can lead to additional revenue by exposing internal
processes/functionality externally.

Time-to-Market: Using SOA to enable re-usable and standardized services to access legacy
systems should reduce time-to-market of certain functionality.

Security Key Performance Indicators (data protection-related KPIs): Especially concerning the
key SOA principle: “Ensure services have appropriate security enforcement standards”, this
metric helps to monitor frequency and severity of security incidents after modernization.
BUSINESS PROBLEM AS ARTICULATED BY THE BUSINESS LEAD
In 2009, Gartner, Inc., identified “Not Engaging the Business People” as one of the top ten Enterprise
Architecture pitfalls. “When IT and business goals are not aligned, resultant problems include nontechnical people trying to make technical decisions while enterprise architects become too reactionary
and tactical in response to projects. To overcome this, Gartner recommends that enterprise architects
get involved in the development of the business context and engage jointly with other employees in the
business architecture.”3
Successful Enterprise Architecture is linked to the business requirements. The Business Lead is the best
person to help articulate the problem EA is helping to resolve. She/he understands the environment, the
business goals and objectives, human capital, roles and responsibilities. The Enterprise Architect (EA)
can assist the Business lead in creating a business scenario that captures the problem in a concise
informative way. Thus, the scenario creates the primary roadmap for the project. The Open Group
suggests the following process for creating a Business Scenario divided among three phases. Identifying
the problem, identify the technical environment used by the business, document business objectives,
list business actors, list of enterprise actors, and documenting roles per actor.4 Error! Reference source
not found. shows the gathering, analysis and review phases for developing business scenarios.
3
4
http://www.gartner.com/newsroom/id/1159617
http://www.opengroup.org/public/arch/p4/bus_scen/bus_scen.htm
30 | P a g e
VEAF Guidebook
State of Vermont
CHAPTER 9 - ADAPTING THE ARCHITECTURE DEVELOPMENT METHOD (ADM)
FOR BUSINESS UNITS WITHIN THE STATE OF VERMONT
This Part of the VEAF Guidebook offers some instructional guidelines and principles to be used when
working with Agencies and Departments within the State of Vermont. These Agencies and Departments
are called Business Units (BU).
ADM is a method used within the TOGAF Framework for Enterprise Architecture. ADM is iterative (a
specific BU), over the whole process (Statewide), between phases (e.g., deployments, upgrades and
migrations), and within phases such as applying a specific phase to flesh out a BU problem.
ADM phases are flexible enough to allow an Agency or a Department within the State of Vermont to
offer insight as to how the BU applies its current architecture in relation to its business models. Some or
all of these phases might apply. For the purposes of this Guidebook, the State of Vermont EA Office
recognizes Phase A-F as BU Architecture Assessments.
A complete list of all TOGAF ADM Phases and Sub-Phases are located on the Open Group Web Site.5
During the process the Business Unit learns the breadth of coverage offered by the enterprise
architecture and how it functions as a service back to the business. Details concerning the BU’s goals are
defined, architectural assets are leveraged, practices and principles are honed for clarity; information
and knowledge are shared and exchanged between the EA Office and the BU.
ADM is always collaborative; it is NOT a top down. Using inductive reasoning, the EA and BU move from
specific observations about their respective technologies to a broader general understanding of how
Enterprise Architecture solves not only specific business problems but fosters the achievement of the
statewide goals and principles.6
Care should be taken by the EA Office as to not insist on too much technical detail upfront as the
business unit might not have full knowledge of all assets or procedures. ADM Phases can be applied in
different business units, they are not hard-and-fast rules to be applied but used as a guideline.
The following illustration shows the different phases of ADM and how they interact with the
Requirements for the BU. (Figure 8)
5
6
http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap03.html
http://www.socialresearchmethods.net/kb/dedind.php
31 | P a g e
VEAF Guidebook
State of Vermont
Figure 8 Phases for Vermont Architecture Development Process Based on ADM from Open Group
PRELIMINARY FRAMEWORK7 AND PRINCIPLES
As the Preliminary Phase of the architecture process for the Business Unit, the principles managed by
the EA Office will inform the constraints on any architecture work. The goal of this phase is to define the
scope and assumptions of the BU in relation to the EA. The framework phase can be adapted from a
previous successful pilot project.
This phase answers the question posed by the business, “why do we need to do this, since my entire
technology processes work fine?” and “We have a staff that handles our technology services, so what
are you offering?” and finally, “how we do architecture?” Care should be used to avoid overwhelming
the business with technical jargon, and “lessons learned” from previous enterprise architecture project.
Adapt and formulate a common vocabulary during this phase so time is not wasted on education
concerning the framework.
The Business knows their processes and functions; the EA Office functions as a service to the business as
a customer. EA gathers the following information from the business as a guideline.
A few observations on Customer Experience will help during all conversations, meetings and formal
presentations to the Business. Dissatisfaction with how technology impacts and disrupts the comfort
level of employees using antiquated systems and processes must be considered. The EA Office engages
Business Units by employing coaching, mentoring and above all empathy for how the Business sees
them in relation to changing technology
7
http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap04.html
32 | P a g e
VEAF Guidebook
State of Vermont
The EA Office is interested in how the BU “does” its own Architecture. Attention to some detail at the
BU level is important. An EA Architect will gather the following technical information:

Applications

Middleware

Code Requirements: Java, VB, etc.

Data: Business Object, MDM, Data Connectivity (ODBC, etc.), SQL, Oracle, DB2, SQL Server, ECM
(Electronic Content Management), Reporting tools

SOA

IDM

Architecture Integration: How do BU Components fit into the EA Framework? Do BU
components fit in to maturity and compliance models consistent with EA Office?
SUSTAINABILITY MANAGEMENT MODEL
A large number of factors affect project sustainability. These factors include some of the following:



Project Design and Implementation
Demonstrable Effectiveness
Financial Resources
PROJECT DESIGN AND IMPLEMENTATION
The Architecture Vision document is a great tool to put forward, in an informal way, the business case
for an enterprise architecture project. It informs the business as to the key benefits of the proposal to
decision-makers. The AV document articulates the business goals and how they are mapped to key
enterprise architecture principles. The AV document includes a high-level description of the baseline and
target architectures as envisioned by the business. This phase of the sustainability plan is essentially the
“elevator-pitch” for the project.
DEMONSTRABLE EFFECTIVENESS
The Architecture project must be able to document its success. The ADM from TOGAF is particularly
helpful in showing, advertising and measuring the effectiveness of a program. Once an architecture
project has been defined, the lead stakeholders should develop an Implementation Governance Model
uniquely adapted for the project. The governance model will guide the project toward a demonstrable,
measurable and sustainable architecture that can easily be communicated to the organization.
A key aspect of Phase G, Implementation and Governance, is ensuring compliance with governing
strategies, project scope, budget constraints and vision. The EA and business leads may offer these
types of artifacts as a method to demonstrate the effective sustainability of the architecture project:




Recommendations for Service Requirements and enhancements
Performance Metrics
Service Level Agreements (SLAs)
Updated Architecture Vision
33 | P a g e
VEAF Guidebook




State of Vermont
Review of budget requirements
Repository (SOA, BPM, Business Services) inventories and reviews for re-use
Implementation Governance Models
Contract reviews
FINANCIAL RESOURCES
The sustainability of a project is enhanced and increased when project have multiple sources of funding.
Cost containment practices such as distributing labor costs across multiple Agencies, out-sourcing labor
intensive activities, and use of shared technology services will also add to sustainability.
Once the funding is sourced, an Enterprise Architecture Assessment (EAA) can be utilized to help
establish cost modeling for the project. (See Appendix XXXX for EAA) The EAA creates a gap analysis for
existing and target architecture needs. This analysis will provide the business with costs models for
software, hardware, services, licensing, storage, cloud services for the foreseeable future.
The EAA identifies the funding sources, Enterprise Architecture Principles in use, costs for oversight, and
cost projects for five years. The Figures below X show some of the information gathered for the EAA.
BUSINESS EARNED VALUE TECHNIQUE
Earned value (EV) is a Project Management Institute definition. As such, it is a technique to measure
performance of a project as it moves from project initiation to project closure. It also provides a means
to forecast future performance based on past performance. EV is a process based on a structured
approach to planning, cost collection and performance measurement. EV provides objective
measurement of a project status, basis for estimating final costs, predictions as to when the project will
be completed and a means of managing change.
Enterprise architecture methods strongly suggest that the EV be managed by the project manager
within the scope of the architecture project. MS-Project 2010 support EV calculations and models.
34 | P a g e
VEAF Guidebook
State of Vermont
COMPONENTS
A component is defined as “an enterprise applications and infrastructure turned into specific,
reliable and modular services"8
The identification of components helps the business understand IT architecture standardizations for
their operational models. A business says, I need a payment system, or a rebate system. They don’t
say I need that software or this software. Which is what a vendor would tell the business.
VEAF Architecture is composed of thirteen identified architecture components, each with their own
governing theme. These components are listed below.
EA Component
Identity Management
Consent Management
Portal
Enterprise Information Exchange
Master Data Management
Rules Engine
Eligibility Automation Foundation
Major Theme
Ensure individuals are identified across the range of roles that
they play and human services programs that they interact
with, and have access only to information and functionality for
which they are authorized
Ensure that appropriate information is shared with only
individuals that are authorized and have a need for access by
providing explicit authorizations.
Provide a consistent user interface and access to information
and functionality
Also referred to as a gateway, or service bus, which provides a
standards based mechanism for integrating with and sharing
information among the full range of human services and
administrative applications
Includes Master Person Index, and Master Provider Index to
ensure a common view and single version of the “truth”
across Vermont’s HHS programs
Define and manage the business rules that will drive
eligibility assessments across human services programs
Provide HSE Platform shared functionality for eligibility
screening, application and determinations services for
Vermont HHS programs
Content Management
Allow management of and access to a wide range
of information and media
Analytics and Business Intelligence
Tools and Repositories
Create reports and dashboards to shed light on and manage
current operations, and to develop analytical and predictive
analyses for future planning and policy development
8
Peter Weill and Jeanne W. Ross, IT Governance. (Boston: Harvard Business Review
Press, 2004) 34.
35 | P a g e
VEAF Guidebook
State of Vermont
EA Component
Major Theme
Collaboration Capabilities
These capabilities are part of the UCM component. These
capabilities include: Service Coordination (Secure Messaging
and Shared Case Notes), Client and Provider Look-Up and
Query, Referral Management (Create Referral and Manage
Referral), and Alerts and Notifications
Service-Oriented Architecture (SOA)
Universal Customer Management
(UCM)
Enterprise Content Management
(ECM) and Customer Communication
Management
Architected services that are composed of discrete
software agents that are loosely coupled to other
enterprise components. These services are re-usable for
the construction of additional applications.
Ensure individual (member) data is managed holistically.
This is generally serviced by CRM applications that touch
multiple areas of a customer (member) activity. Services to
be used include CRM 2.0 capabilities thus offering bidirectional communications and exchanges. This is
backbone of any Care management system.
Allow for the management of structured and un-structured
data across the enterprise. The customer communication
management part refers to notifications constructed by the
business to formally communicate with members by way of
the enterprise.
BU ARCHITECTURE ASSESSMENTS (ADM PHASES A THROUGH E)
Gathering information on a BU’s architecture is needed in order for a clear baseline for growth,
migration, deployments, change management and governance. The BU and EA Architect can used the
specific phase definitions listed in this document to pick and choose which data are necessary for
moving forward. Together, the BU and the EA Architect perform the following:

BU identifies baseline Architecture

BU identifies technology leads, analysts, programmers, vendors or other resources associated
with BU Architecture

EA Architect formulates base architecture
BU MIGRATION PLANNING INTO THE EA
The Migration Planning phase is critical. It is not optional. This phase moves the business goals into a
target architectural system that explains back to the business how the targeted architecture is tailored
specifically for the business goals.
36 | P a g e
VEAF Guidebook
State of Vermont
By the start of this phase the BU and EA have clearly and concisely identified the areas of compatibility,
gaps in architecture that need to be closed, and possible decommissioning of the business’ existing
technology.
At this phase meeting minutes and/or notes generated during the Architecture Assessments phases
should be reviewed, updated, and entered into the Architecture Repository. The work package, actors
needed for deployments are identified during this phase. The following outlines some of the activities
during this phase.

Confirm Management Framework Interactions for the Implementation and Migration Plan

For each work package in the plan, assign a business value

Estimates for Resource Requirements: Project Timings, Availability and Delivery methods

Prioritize Migration work packages based on Cost / Benefit and Risk Validation.

Write EA Roadmap for Migration Plan

Business and EA Architect Generate Collaborative Implementation Migration Plan for
Deployment

Complete the ADM and Document Lessons Learned
BU / EA GOVERNANCE AND PRINCIPLES
The practice of Governance with principles adds value to the business. As with all activities of the EA
Office, the focus on Governance and Principles within the Architecture framework is paramount. The
following Business specific principles show how goals are achieved. As an example, if a principle of the
AHS business is “Cost Optimization”, a rationale and its implications within technology must be
identified up front in order for the Governance of the EA to be effective.
Cost Optimization is a State directive, and as such, the Business needs to attenuate costs without
impacting services to the citizens of Vermont. The Business identifies areas where EA can introduce
optimization and effectiveness with respect to the Business’ technology. EA thus assists the Business in
achieving their goals.
Governance is applied during all phases. However, during this phase, the BU and EA pause to assess and
monitor necessary resources, compliance checks on the target architecture against the existing EA,
setup post deployment review process and set specific deadlines.
Current EA Principles are found in Part 1 of the Guidelines.
BU / EA CHANGE MANAGEMENT COMMUNICATION METHODS9
The rate of customization and change needs to be constantly measured against the Enterprise
Architecture. Streamlining and avoiding administrative complexity in the CM method allows for rapid,
process driven methods for change within the architecture.
CM Criteria Evaluation
9
http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap14.html
37 | P a g e
VEAF Guidebook
State of Vermont

Is the change request against a wide-range of applications, devices, components, data objects?

Does the change affect the usability of the enterprise?

Does the change affect other Bus?

Are there operational modifications to be considered? Considerations might include but not
limited to: new monitors, additional 2-tier backups for production, educational materials
required from the business for users

Are the CM Actors identified and their roles clearly identified?
The Change Management process governs modifications to an established technical infrastructure and
associated information systems. Modifications to the Enterprise Architecture are made in a controlled
way and managed using a standardized change control procedure as outlined Change Control Process
document.10 A change control method ensures efficient and prompt handling of changes - from
inception to implementation and allows the Enterprise Architecture group to consider the benefits and
risks associated with a proposed change ( Figure 9). This policy is intended to provide best practice and
procedural guidelines that should be used when making changes to EA Infrastructure. The EA change
control process should satisfy the following requirements:
10
\\inside.vermont.gov@SSL\DavWWWRoot\sov\cto\info\Documents\Change
Control\Draft EA Change Control Process.docx
38 | P a g e
VEAF Guidebook
State of Vermont
Change Management for Business Unit: Business Unit Identified Change with COST Approval
Business Units
Phase
UAT Change
testing on
Staging
Platform ONLY
Review:
Approve
move on to
Impact
Vendor
Vendor
Identifies
Costs and
Resources
Enterprise
Architecture Office
Change Control
Board (midmanagement
level)
Business Unit Identifies
Change
Release to
Production
Cost Identified and
Approval Granted to
move forward.
Multiple Reviews
and Impact
Studies
Change
Development
prepared,
iterations
outlined.
Vendor /
Enterprise Office
Study Impact
Study
Modifications
requests against
Existing
Architecture
Update Change in
the Architecture
Iterations Repository. Catalog
Operational
Changes.
Technology
Review
Based on UAT
results: GO no GO
Decisions made.
Showstoppers
identified,
modifications for
future iterations
identified, release
notes and
modifications to
documents
finalized.
Change Advisory
Board (Director
Level)
Artifacts for Architecture Repository
RISK
Assessment
then move
forward to
PMO
PMO
Prioritizes and
Schedules
Figure 9 Change Control Method for Vermont EA and BU

Defines the roles, processes, and procedures to be used to manage submission, recording,
analysis and approval of changes.

Provides a mechanism for requesting a change.

Provides detailed information concerning the changes.

Provides a formal review and approval process for changes.

Provides notification to groups potentially affected by the change where appropriate.

Provides a historical record of all requested changes for review and audit purposes.

Establishes and defines one or more suitable maintenance windows during which planned
outages can be expected for major, non-routine EA infrastructure changes.
Since Agencies and Departments within the State of Vermont use various vendors for development,
testing and management of production systems; attention to vendor CM methods need to be outline as
part of the Architecture Model. In the example below, AHS business and EA Office interact with the
vendor’s CM.
Architects are encouraged to seek out and understand the CM methods for the vendor whenever
possible. Figure 9 illustrates the CM process for a BU that has achieved cost approval. Note: the swim
39 | P a g e
VEAF Guidebook
State of Vermont
line for EA Office in Figure 9 shows how EA Architects straddle the CCB, Vendor and EA Office during the
CM process.

EA and BU catalog current change management methods employed by the agency or
department
EA looks carefully for opportunities for flexibility within the BU’s methods that will allow the BU
to rapidly evolve within the EA
Change Management BU Drivers: Note EA’s apply Governance and Principles for CM here. Here
are some considerations.
1. Does BU have current technology reports?
2. Does BU manage existing technology? If so, report carefully on what is in place.
3. What methods will be employed to decommission existing technology within the BU?
4. What are the business-as-usual development needs? Who, What, How and When?


CHAPTER 10 - BU REQUIREMENTS MANAGEMENT AND THE REQUIREMENTS
REPOSITORY.11
All phases of ADM lead to the Requirements Management Phase. As indicated by the "Requirements
Management" circle at the center of the ADM graphic, the ADM is continuously driven by the
requirements management process. (Figure 8 9)
It is important to note that the Requirements Management circle denotes not a static set of
requirements, but a dynamic process whereby requirements for enterprise architecture and subsequent
changes to those requirements are identified, stored, and fed into and out of the relevant ADM phases,
and also between cycles of the ADM.
The ability to deal with changes in requirements is crucial. “Architecture is an activity that by its very
nature deals with uncertainty and change - the "grey area" between what stakeholders aspires to and
what can be specified and engineered as a solution.”12 Architecture requirements are subject to changes
in practice. Moreover, architecture often deals with drivers and constraints, many of which by their very
nature are beyond the control of the enterprise (disasters, changing market conditions, new legislation,
etc.), and which can produce changes in requirements in an unforeseen manner.
11
Note: A Requirements Repository is currently under construction on the State of
Vermont SharePoint Site. It will be managed by the EA Office.
12
http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap17.html
40 | P a g e
VEAF Guidebook
State of Vermont
The Requirements Repository is used to record and manage all information relevant to the BU
requirements for the EA. These data are derived from the BU Drivers and the enterprise components
used to implement the requirement. Requirements are constantly checked against the Solutions
Repository for compatibility.13
Figure 10 Architecture Repository
13
http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap41.html
41 | P a g e
VEAF Guidebook
State of Vermont
SPECIAL NOTE ON THE ORACLE SOA REPOSITORY.14
The Oracle SOA Repository is a critical building block in the Enterprise Architecture managed by the
State of Vermont. For our purposes this Repository and its supporting documents will be considered a
mandatory subset in the Solutions Repository.
The Oracle Enterprise Repository provides the features

Visibility into all SOA assets and their relationships

Automatically collects and populates the Oracle Enterprise Repository and Registry with existing
services and other assets through introspection and synchronization with developer tools

Provides a flexible and extensible model for categorizing SOA assets.

Provides visibility of assets that currently exist, are planned, or are in development to reduce
duplication of effort

Automatically discovers, maps, and manages new dependencies to support impact analysis

End-to-end governance throughout the lifecycle

Automates the depicted governance processes

Communicates architectural standards and tracks architectural compliance

Harvest the operational metrics from Oracle Enterprise Manager (OEM).

Analytics
i.
Tracks and reports on reuse throughout the entire service lifecycle, including development
reuse, runtime service reuse statistics and data on consumption and compliance through
scorecards
ii.
Collects and communicates vital information on service performance, quality, and
compliance with corporate standards
iii.
Supports critical decisions with feedback on SOA compliance, performance, and ROI
Activities of Requirements Management:
1. BU Business Drivers. EA Office manages Business Drivers for the Enterprise Architecture. See VEAF
Manual Part 1 for information on those drivers. Each BU might have their own drivers that might
meet the same operational principles used by the EA Office. For instance, an Agency or Department
might be driven by a need for a more simplified organization due to budgetary considerations. The
EA Architect is positioned to help assess the alignment of Business Drivers.
14
http://www.oracle.com/us/technologies/soa/enterprise-repository-ds-1953749.pdf
42 | P a g e
VEAF Guidebook
State of Vermont
2. BU Business Analyst Inputs
a. BA Communication Plan with EA Office (see CAP in Part 1)
b. Organizational Process Assets, Organizational Process Assets are “any or all process related
assets, from any or all of the organizations involved in the project that can be used to influence
the project’s success.” Examples include: plans, procedures, lessons learned, historical
information, schedules, risk data and earned value data. Organizational Process Assets fall into
two broad categories, Processes and Procedures and the Corporate Knowledge Base. The key
concept is that these are assets a project manager may use for the benefit of the project. 15
c. Requirements Compatibility, do they support the resolution of the business problem and are
compatible with the Solutions offered by the EA Office?
d. Requirements Plan (rules and policies)
e. Requirements Structures
f.
Scope and Goals
g. Stakeholder list and Responsibilities
3. BU Business Outputs
a. Application within EA per TOGAF 9
b. Future initiatives: Do they fall in line with the strategic IT Initiatives as outlined by CIO and CTO?
BU ARCHITECTURE MODEL CONCLUSION
The State of Vermont Enterprise Program (VEAF) uses ADM for Architecture Development across
business units. It will guide the BU and EA on the design for a target Architecture acceptable by the BU.
There are a few reasons ADM might need to be tailored to specific BU circumstances.
ADM is flexible enough to handle this through phase modifications. As an example, a business case
might arise where a BU does not have any defined Architecture Vision. The EA Office can assist in
offering a planning method that focuses on identifying that Vision for the BU without the need to
implement of migrate any Architecture.
Phases A-F, would serve the needs for that business case.
The ADM process can also be adapted to deal with a number of different use scenarios, such as security
improvements and the decommissioning of antiquated technology.
15
Project Management Institute. A Guide to the Project Management Body of Knowledge:
PMBOK Guide 4th Edition
43 | P a g e
VEAF Guidebook
State of Vermont
CHAPTER 11 - EA DOCUMENTATION REQUIREMENTS (ARTIFACTS) FOR
ARCHITECTURE MODELS
As the BU and EA begin the process of outlining a target architecture for the business, many artifacts will
be collected and deposited into the Architecture Repository. The EA is responsible for necessary artifacts
required for all Enterprise Architecture projects. Artifacts should be posted onto the CTO SharePoint Site
until an Enterprise Architecture Repository is available.
No single document can offer a complete view of the existing enterprise or the target enterprise as
required by the business.
To understand this approach to documentation, think of a plane landing at an airport. Both the airtraffic controller and the pilot have the same goal of landing a plane, however both only have one view
of the system. The pilot’s view of the airport makes up only part of the whole and contains some
elements not viewed by the air-traffic controller and vice versa. Together both views are needed need
to understand how the airport functions as a whole. In order to understand how the entire airport works
cohesively, multiple views are required.
APPLICATION OF VIEWS AND VIEWPOINTS
Artifacts are documented views. A view is what you see when looking at a system from a chosen
viewpoint. A viewpoint is a way of looking at a system. So in the example of the air-traffic controller and
the pilot, each sees the systems of the airport differently based on a viewpoint. Yet, the specific view is
unique to each.
For the purposes of understanding how a BU view’s its business, an Architecture Description (AD) is
necessary. The Architecture Description will include the Stakeholders and their concerns, various
Viewpoints, Views, Consistencies, In-Consistencies and data model descriptions.
It is best to start with the Architecture Description and then add the artifacts to the AD.
DOCUMENTATION REQUIREMENTS
The following table describes the supporting artifacts used in documenting enterprise, segment, or
solution architecture for the EA and BU. These artifacts will feed into the work captured in the
Architecture Vision, Architecture Description Document (aka, System Design Document & Interface
Control Document), and Architecture Roadmap deliverables. Templates for each are available on
SharePoint.
44 | P a g e
VEAF Guidebook
State of Vermont
ADM Phase
Artifacts
Architecture Domain and EA
Governance
Principles Catalog
VEAF Guidebook
Component Strategy Documents
Agency Strategy Documents
Business Architecture
Organization/Actor Catalog
Role Catalog
Business Service/Function Catalog
Business Interaction Matrix
Actor/Role Matrix
Business Footprint Diagram
Business Service/Information Diagram
Functional Decomposition Diagram
Product Lifecycle Diagram
Application Architecture
Application Portfolio Catalog Interface Catalog
Application/Organization Matrix
Role/Application Matrix
Application/Function Matrix
Application Interaction Matrix
Application Communication Diagram
Application and User Location Diagram
Application Use-Case Diagram
Information Architecture
Data Entity/Data Component Catalog
Data Entity/Business Function Matrix
Application/Data Matrix
Conceptual Data Diagram
Logical Data Diagram
Data Dissemination Diagram
Technology Architecture
Technology Standards Catalog Technology
Portfolio Catalog Application/Technology Matrix
Environments and Locations Diagram
Platform Decomposition Diagram
45 | P a g e
VEAF Guidebook
State of Vermont
ISO/IEC/IEEE 42010 ARCHITECTURE DESCRIPTION TEMPLATE FOR COLLECTING
ARTIFACTS16
The purpose of documenting the Architecture Description is communication. Shared documentation
enumerating the stakeholders, systems, data models, connectors, capabilities, architecture decision
points, and architecture in/consistencies; will allow EAs and various BUs to use a common singular
language for reuse within the Enterprise.
In Figure 11, the relationship among rules, correspondences, Views, Viewpoints, Stakeholders is outlined
and shows how information, when documented correctly feeds an accurate sustainable description of
the Enterprise Architecture.
Figure 11 Content of the Architecture Description17
16
The template is licensed under a Creative Commons Attribution 3.0 Unported License
http://creativecommons.org/licenses/by/3.0/
Contact the author Rich Hilliard ⟨[email protected]⟩ with comments, suggestions,
improvements or questions.
For more information on ISO/IEC/IEEE 42010, visit the website:
http://www.iso-architecture.org/42010/.
17
46 | P a g e
VEAF Guidebook
State of Vermont
CHAPTER 12 - CONCLUSION
The VEAF is, by definition, a model of the
The VEAF is the model of the
organization’s enterprise and its future direction. Its
organization’s enterprise and its
value to agencies and departments implies more than
simply IT investment and IT management. The
future direction.
dynamic changes in technology and business practices
impose greater pressure on an organization to
respond more rapidly. VEAF is uniquely positioned to respond to these pressures and demands.
By outlining, defining and publishing VEAF’s processes and mechanisms, a long-range view of how the
enterprise-wide use of IT will align with and enhance the achievement of the State of Vermont's
business strategies. VEAF offers the framework, governance, and guidelines through its principles that
will with the state’s organizational needs
47 | P a g e
VEAF Guidebook
State of Vermont
SUPPLEMENTAL
APPENDIX A – STATE OF VERMONT HSEP LISCENCED PRODUCTS
The SoV licensed the following products on an enterprise/unlimited basis
Pillar
Database Products
Products
Oracle Database Enterprise Edition
Real Application Clusters
Partitioning
Advanced Security
Database Vault
Oracle Advanced Compression
Oracle Active Data Guard
Diagnostics Pack
Tuning Pack
Change Management Pack
Provisioning and Patch Automation Pack for
Database
Configuration Management Pack for Oracle
Database
Oracle Datamasking Pack
Business Intelligence Publisher
Case Management Products
Siebel Public Sector CRM, Siebel Base CRM, Siebel
Public Sector Partner Portal, Siebel Public Sector
eService, Siebel Partner Manager,
Rule Engine Products
Oracle Policy Automation, Oracle Policy Modeling,
Oracle Policy Automation Connectors for Siebel
Reporting and Business Intelligence
Oracle Business Intelligence Suite Enterprise
Edition Plus
Oracle Business Intelligence Management Pack:
Informatica PowerCenter and Power Connect
Adapters
Partner Analytics Fusion Edition
Contact Center Telephony Analytics Fusion Edition
Service Analytics Fusion Edition
48 | P a g e
VEAF Guidebook
State of Vermont
The SoV licensed the following products on an enterprise/unlimited basis
Pillar
Products
Case Management Analytics Fusion Edition
Oracle Data Integrator
Oracle BI Publisher
Identity and Access Management
Identity Analytics
Identity and Access Management Suite Plus
Oracle Virtual Directory
Identity Manager
Oracle Internet Directory
Oracle Identity Manager
Oracle Access Manager
Oracle Internet Directory
Oracle Adaptive Access Manager
Identity Manager Connector - Database
Applications Table
Identify Manager Connector - Database User
Management
Identify Manager Connector - Microsoft Active
Directory
Identify Manager Connector - Microsoft Exchange
Identify Manager Connector - PeopleSoft
Enterprise Applications
Identify Manager Connector - Database Microsoft
Windows
Identify Manager Connector - UNIX
Identify Manager Connector - RSA Authentication
Manager
Identify Manager Connector - Siebel Enterprise
Applications
Identify Manager Connector - IBM RACF
Management Pack Plus for Identity Management
Portal Products
Liferay Enterprise (One gate)
Management Pack for WebCenter Suite
49 | P a g e
VEAF Guidebook
State of Vermont
The SoV licensed the following products on an enterprise/unlimited basis
Pillar
Products
WebCenter Suite (does not include Content
Management)
WebCenter Suite Plus upgrade
Enterprise Content Management Products
Oracle Web Center Capture v 10.1.3.5.1 aka 10gR3
Oracle Recognition and Content v11.1.1.7
Thunderhead Now v5.1 WCP/WLS (notices)
Service Orientation Platform Products / BPM
WebLogic Suite
SOA Management Pack Enterprise Edition
WebLogic Server Management Pack Enterprise
Edition
SOA Suite for Oracle Middleware
Includes Oracle BPEL
Includes Oracle Mediator
Includes Oracle Rules
Includes Oracle Human Workflow
Includes Oracle Service Bus
Includes Oracles Business Activity Monitoring
Unified Business Process Management Suite
Enterprise Repository
Service Registry
Healthcare Adaptor
Application Integration Architecture
MDM-CRM Integration PIP
Oracle Application Management Suite for Siebel
Master Data Management and Data Quality
Products
Oracle Customer Hub Data Steward Oracle Customer Hub B2B
Oracle Customer Hub B2C
Oracle Activity Hub B2B for Oracle Customer Hub
B2B
Oracle Activity Hub B2C for Oracle Customer Hub
50 | P a g e
VEAF Guidebook
State of Vermont
The SoV licensed the following products on an enterprise/unlimited basis
Pillar
Products
B2C
Oracle Customer Master Data Management
Integration Base Pack
Oracle Data Quality Matching Server - limited to 4
Processors
Oracle Data Quality Address Validation Server limited to 4 Processors –
Oracle Data Quality Parsing and Standardization
Server (Informatica) - limited to 4 Processors.
OEDQ is implemented instead of Informatica
though it is licensed for any data quality
Oracle Data Quality Profiling Server (Informatica) limited to 4 Processors. OEDQ is implemented
instead of Informatica though it is licensed for any
data quality
Misc.….
Oracle Governance, Risk, and Compliance Manager
UPK
Secure Enterprise Search
51 | P a g e