Enterprise Architecture | Virginia IT Agency

What is Enterprise Architecture?

Enterprise Architecture is focused on the alignment of people, process, technology, and information across an organization.

Change is constant and occurs throughout the organization at every level. New applications cause process and people changes, information structure and meanings change, vendors change, and organizations restructure. Change causes impact to organizations, and its ripple effects can lead to operational errors, delay, costs, and frustration.

Enterprise Architecture as a planning function provides a focus on understanding, managing, and communicating the future state relative to the current state. As a risk function, it provides guardrails via approved standards and roadmaps that help to provide boundaries through trusted patterns and best practices. As a technology function, it seeks to manage the efficient application of technology within an organization by enabling re-use, cataloging capabilities, and engagement with practitioners, buyers, and other stakeholders.

How is Enterprise Architecture Applied at the Commonwealth?

Each agency has a distinct mission in support of the Commonwealth's services to the citizens of Virginia. All have unique operational structures composed of people, processes, and technology. Importantly, all of these elements are undergirded by information, which is the fuel that binds them together. The better aligned these elements are with each other, the more effectively the agency can deliver its services. The actual implementation of these elements vary – some are entirely within the agency, and some of these elements are delivered via external, shared services.

The authority of the enterprise architecture practice is found in the legal code of Virginia for the powers of the CIO. The following statements are relevant to the mission of the COV's EA practice.

Code of Virginia - § 2.2-2007. Powers of the CIO.

Support state and local government exchange, acquisition, storage, use, sharing, and distribution of data and related technologies.
Support a unified approach to information technology across the totality of state government, thereby assuring that the citizens and businesses of the Commonwealth receive the greatest possible security, value, and convenience from investments made in technology.
Provide oversight for executive branch agency efforts to modernize the planning, development, implementation, improvement, operations and maintenance, and retirement of Commonwealth information technology, including oversight for the selection, development, and management of enterprise information technology.
Direct the compilation and maintenance of an inventory of information technology, including but not limited to personnel, facilities, equipment, goods, and contracts for services.

Code of Virginia - § 2.2-2011. Additional powers and duties relating to development, management, and operation of information technology.

Manage, coordinate, and provide the information technology used by executive branch agencies.

How to engage with the EA team

Enterprise Architecture at VITA is engaged through a variety of mechanisms, which vary depending on the need. EA is active across the lifecycle of technology, starting in pre-procurement activities within the IT strategic plan process, through RFP considerations, technology selection, and architecture review and ongoing governance work via exceptions, vendor management and architectural reviews.

Enterprise Architecture also produces standards which specify required behavior and controls for the application of technology in the Commonwealth, as well as roadmaps that specify which software is current, upcoming, and outdated to assist with the management of infrastructure and planning.

More information on EA standards and policies can be found in the Resources section below.

Learn how to engage with EA team for each process by clicking on tabs to the left.

If your agency or operation is unable to comply with approved EA standards or roadmaps an Archer exception should be registered for your agency.

Some examples of exceptions are:

Your agency uses a software product version that is 2 or more versions behind the current release.
Your agency has out-of-support hardware that the agency is dependent on, or has a hardware product that is over 5 years old that is still in service.
You can't meet an enterprise requirement, such as compliance with logging or data availability.

Register your exceptions in Archer, the COV risk management system. For more information, see our Information Security FAQs section.

AI policy and AI technology standard for the Commonwealth

Executive Order 30 directs that VITA develop and publish an AI policy and AI technology standard that is adhered to by the executive branch agencies.

As part of the developed standard, all agencies and suppliers shall register their intended utilization of artificial intelligence in their operational functions for review by VITA and the secretariat.

To find out more about this process, visit our Artificial Intelligence section. Use Archer to start or access your AI records

As a governance function, Enterprise Architecture reviews architectural designs for architectural coherency and alignment to VITA rules and that the VITA rules for the service are met.

Additionally, EA validates that the exceptions referenced in the document are valid, and applicable. Enterprise architecture will also comment on technical design details if needed.

Architectural reviews happen via the MSI Holistic Architectural Review Process, or HARP. HARP is an iterative approach that is used to review and approve architectures for compliance to contracts and VITA Rules.

The Architecture Overview Document (AOD) templates help suppliers document their architectures in a way that reviewers can determine if the architecture is in compliance. The AOD is split into 3 sections that are completed at different times in the lifecycle of a service deployment. These sections are the High-Level Section (HLS), the Detailed Design Section (DDS), and an As Built Section (ABS).

HLS – The high-level section is required to be approved prior to starting the project and is required to build the system.
DDS – This section contains the information needed to build or rebuild the system and needs to be completed prior to the service going live. It contains the system configuration and includes the configurations from other suppliers that are required to bring the system online.
ABS – The as-built section contains any variances from the Detailed Design and the system and component configurations. It needs to be completed prior to project closeout.

IT Strategic Plans (ITSP) are required by the Code of Virginia.

One of three main types of reviews EA is active within the procurement process as a validation and approval point:

Every two years, agencies must attest to the IT activities they plan to undertake through the next two years. As part of the approval process, Enterprise Architecture reviews ITSPs for standards compliance, opportunities for reuse, activities that remediate any outstanding exceptions, and clarity of intent.

Once the review is complete, Enterprise Architecture will enter into the Planview system the recommendation to approve and, where necessary, engage with the CAM and other resources where follow up and clarifications are required.

Investment Business Cases (IBC)

Two of three main types of reviews EA is active within the procurement process as a validation and approval point:

IBC serve as the means to authorize the agency to prepare a project charter, perform an RFP, and expend funds as needed to do so. These are also reviewed by Enterprise Architecture. For these, EA looks for alignment of the IBC with the agency’s ITSP and reviews the proposed approach against the current standards and IT direction.

For example, agencies generally should be using cloud-friendly approaches that don’t unnecessarily create roadblocks for compliance or other challenges during implementation or in the future. Enterprise Architecture, as one of the reviewers, will approve the IBC if there are no identified issues. If there are some clarifications or conditions, the enterprise architect can provide these comments with an approval, or if necessary, will send back the request to the agency for more information prior to approval.

Procurement Governance Requests (PGR)

Three of three main types of reviews EA is active within the procurement process as a validation and approval point:

PGR comes after an approved Investment Business Case, where the agency is ready to spend the money on the solution they described in the IBC. Similar to the review activities of an IBC, Enterprise Architecture will participate in the review of the PGR for compliance with EA standards and alignment with the COV IT direction.

After review, the enterprise architect will either approve without comment, or will ask for more information prior to approval in the tool. Additionally, as part of this process, the EA may reach out to the contacts for clarification if needed.

EA Standard and Policy

In support of the CIO’s mission to provide a unified approach to IT across state government, Enterprise Architecture produces standards which specify required behavior and controls for the application of technology in the Commonwealth. Typically, they are constructed to provide quantifiable requirements that can be measured and governed for compliance. The value of standards is that they can reduce the amount of redundancy in approaches, provide for consistent approaches, reduce attack surface areas, and allow for focus in training and skills.

The Enterprise Architecture Policy (EA200) provides the basis for the set of standards that provide part of the technology governance framework for the commonwealth. This standard establishes direction and technical requirements which govern the acquisition, use and management of information technology resources by executive branch agencies. The diagram below shows the relationships between the standards and how they support each other.

The Enterprise Architecture Standard (EA 225) establishes an information technology framework to develop, maintain and use the EA as a tool for making decisions around information technology changes and investments.

Below find resources published under EA-225 and EA Roadmaps

For more detail on the standards categories, refer to EA 225.

Roadmaps, as published by the COV EA team, provide for guidance around planning technology investment, changes, and updates. They specify, for foundational technology categories, which product versions should be used, when they should be updated by, and when they should be no longer used.

The intent for governance of technology versions is simply to prevent last minute version updates and their consequent negative impact on delivering quality information technology that supports the Commonwealth business architecture. In fact, updating to current versions should be a recurring task for agencies and suppliers of Commonwealth information technology services, because this will result in increased staff productivity, maintaining reliable security and reducing the costs of legacy maintenance.

The following roadmaps enable agencies and suppliers to plan more predictable and scheduled updates. Because assessments are "forecasted" with best available information at the time of a decision, they are subject to change to maintain resilience with those subsequent changes occurring outside the Commonwealth's control.

Roadmaps are available for the following:

Visit EA Roadmap Definitions for more details.