Enterprise Architecture Committee
Principles
The primary focus of these principles is business processes,
data, and technologies of the Enterprise Architecture that are
shared across the state (Tier One). However, when possible, the
application of the principles to individual agency architectures,
and sub-agency architectures (Tiers 2 & 3), improves the
consistency and cohesiveness across architectures.
1 The Commonality Principle
| Should be common where there is a clear business case; once
designated as common, justification is required to deviate |
Rationale:
We have decentralized approach to funding, people/resource
allocation, priorities, governance and management, which drives to
an uncommon architecture without a principle to support
commonality. The greater the number of agencies that use the
Enterprise Architecture the greater the ability of agencies to
leverage each other's IT investments.
Implications:
Enterprise Architecture has an obligation to ensure there is a good
business case for including a process, data, or technology in Tier
One. Agencies should have good business case for deviations from
process, data, or technology in Tier One. Mandatory compliance may
be required for some processes, data, or technologies that have
strong risk implications to the state (e.g. some security
components). The Enterprise Architecture process should be designed
to encourage participation from a broad range of agencies. May
require change in funding approach.
2 The Business Alignment Principle
| Should align projects and investments based on Priorities of
Government (POG) |
Rationale:
The State has articulated a set of priorities that guide where to
focus our efforts. Information technology decisions need to be
driven by these business priorities.
Implications:
Enterprise Architecture decisions will be made with the strongest
alignment to the Priorities of Government possible. Many
POG-related activities will require participation from Communities
of Interest in order to be successful. The perspective of these
Communities of Interest should be considered when making Enterprise
Architecture decisions.
3 The Natural Boundaries Principle
| Should be designed around natural boundaries |
Rationale:
Achieving the ability to view state government as a single
enterprise requires the ability to effectively integrate systems as
needed. Systems with well defined, natural boundaries aid in
integration.
Implications:
In order to meet its mandate in a timely manner, the state will
need to leverage and use all of its available resources including
the existing environment. Within the boundaries of an “Information
System”, tight coupling streamlines business processes. Between
“Information Systems”, loose coupling allows open, plug and play
approach. Requires definitions of what is in and out of scope of
statewide “Information Systems”. Requires enterprise-level business
and data modeling.
4 The External Linkages Principle
| Should facilitate linkages with external partners |
Rationale:
Achieving results at less cost through creative budget solutions
may require increased partnering with external entities. Many of
the approaches and techniques used for linking with external
entities can also be used within the state to improve our ability
to consolidate similar activities in different agencies. Improved
linkages to external partners can improve services to citizens.
Implications:
Will have security implications (more granular - connectivity and
sharing without compromising own security.) May require migration
to open or industry standards. May require some enterprise level
metadata. Systems should be constructed with clearly defined
interfaces.
Inter-system communication mechanisms (e.g. messaging
infrastructure) become more important.
5 The Scalability Principle
| Should be scalable to support different size organizations
and loads and handle growth or decline in business levels. |
Rationale:
Spending reprioritization, program elimination, or consolidation of
similar activities in different agencies may require systems to
scale up or down to support changes in business level.
Implications:
May affect charge-back model.
May impact user interface choices.
Will require flexibility to support different
business processes.
Will require strong capacity planning scope or
model.
6 The Security Principle
| Should protect information
assets |
Rationale:
Citizens look to government to play a key role
in safeguarding both their physical security, and their personal
information.
Will require more enterprise-level security
"minimum-level thresholds" to prevent "weakest links" from
compromising security for all.
May require consistent business rules.
May require broader risk analysis.
May require layers of security.
7 The Customer Viewpoint Principle
| Should be designed around the customers viewpoint and
provide a consistent customer experience |
Rationale:
State government is increasingly required to
be viewed as a single enterprise.
May support functions like single sign-on,
one-stop shopping, and common payment options for customers.
May require numerous systems to shift from a transactional model
to a more customer-centric model.
Will require additional understanding of customer usage
patterns.
May require additional "look and feel" standards and
compliance.
May require an enterprise portal strategy.
Should facilitate access for all users.
8 The Business Ownership Principle
| Should have a clear business
owner |
Rationale:
The Architecture will need to accommodate the
constant changes that impact the services the State delivers, and
how the State delivers those services. Understanding who owns which
piece of the architecture helps ensure those most affected by those
changes are involved up front.
High-Level Business Process and Data modeling
needs to occur in order to determine ownership.
Business leadership needs to be involved in order to accept
ownership.
As components are added to the architecture they should include
owner as an attribute.
9 The Business Continuity Principle
| Should be designed and implemented in a
way that minimizes interruptions to service |
Rationale:
Citizens expect government to take the
appropriate measures to ensure government services won't be
interrupted.
An enterprise view of Disaster Recovery and
Business Continuity will need to be developed.
10 The Interoperability Principle
| Should enable
interoperability |
Rationale:
Interoperability will be required to support
critical government initiatives such as Homeland Security or Public
Safety.
Interoperability will be required to support business drivers
such as the ability to view state government as a single
enterprise, and the ability to consolidate similar functions.
Interoperability facilitates data sharing between internal and
external partners. This supports streamlining processes, improving
service and reducing costs.
Will have security implications.
May require migration to open or industry standards.