Enterprise Architecture Services fall broadly into five categories: Strategy, Request for Proposal (RFP), Contracting, Implementation, and Operations. The bulk of enterprise architecture work is project based and occurs during the planning phase. However, enterprise architecture work also extends beyond projects, and its services are not limited to these categories. Architecture assessments, for instance, can occur before a project begins, or after a project ends; in both cases it serves to establish a baseline understanding of an application or service.
Strategy services refer to the overall course of IT development and governance across the State of Vermont. Enterprise Architects working on strategy provide Agencies and Departments with assistance and oversight by taking business process and capabilities, and using them to provide both a current, and a future state of their IT infrastructure. This provides an Agency or Department a roadmap to sustainably grow their IT infrastructure.
Center of Excellence
The Department of Information and Innovation (DII) Enterprise Architecture Office, as per its commission from the State, is a Technology Center of Excellence (CoE) for the State of Vermont.
The Enterprise Architecture CoE develops State-level strategies, for the sustainable growth of the State’s IT landscape; producing best practice guidelines for the State-wide technology infrastructure.
Change Control Board
Enterprise Architects advise the Change Control Board on the impact of, and alternatives to, changes made to applications and services within the State Infrastructure. This helps to ensure that Agencies and Departments have a full understanding of the implications, intended and otherwise, that can arise from changes to its infrastructure.
EA Project Assessments
Gathering information on an Agency or Department’s current architecture is needed in order to have a clear baseline for the growth of, migration from, and deployments to its infrastructure. Enterprise Architect’s gather business capabilities and processes in order to provide a comprehensive view of the current state; providing an organization metrics to assess the success of the future applications and services.
The Enterprise Architecture Office creates and supplies templates for Enterprise Architecture Deliverables with the State of Vermont.
Vermont Enterprise Architecture Framework
The State of Vermont Enterprise Architecture Framework (VEAF) is based on The Open Group Architecture Framework (TOGAF) and Oracle Enterprise Architecture Framework (OEAF). It provides a standardized, but adaptable, approach for State Enterprise Architects to guide the integration of IT projects into State Architecture.
EA Guiding Principles
Enterprise Architects maintain the EA Guiding Principles. The Guiding Principle serve as a cornerstone guiding the overall direction of State’s IT Infrastructure strategy. Guiding Principles are used in all aspects of enterprise architecture assessment work; including both current and future states, and the assessment of proposed IT projects within State Architecture.
Enterprise Architects provides governance via their contributions to both the Center of Excellence, and the Change Control Board. They provide state organizations have the necessary information to select the best possible solution for inclusion in the State of Vermont IT Infrastructure.
This governance applies to:
Data Governance ensures that data sources are compliant with necessary regulations and security standards and works to avoid duplicate data sources within the state.
Enterprise Architects consult with Agencies and Departments to ensure that they are aware of available common solutions when upgrading legacy systems, and that these solutions are leveraged wherever possible. As well, SOA Enterprise Architects manage the SOA Environment in accordance with industry standards and best practices.
Enterprise IT Strategy
Enterprise Architects use all of the above services in an effort to guide the overall direction of IT investment within the State at the enterprise level. Enterprise Architects furthermore, are expected to track the Agency and Departmental adherence to Statewide IT roadmaps and goals.
IT Alignment with Business Strategy
Enterprise Architects work with Business Architects within State Agencies and Departments to align Agency and Departmental IT goals and with the goals of the State Enterprise.
Enterprise Architects work with the Business in the creation of RFPs helping Agencies and Departments have the greatest possible clarity when seeking proposals.
During the RFP process, Enterprise Architects provide insight into services already in use within the State that can potentially be leveraged to lower overall implementation costs. EAs also assist the Agency or Department in understanding how their business capabilities and processes that would be effected by the addition of new application or service.
Enterprise Architects maintain the State Non-Functional Requirements (NFRs). Non-functional requirements provide qualities and constraints for an IT solution, allowing performance to be assessed for acceptance, and its overall alignment to SLAs.
At a minimum, an Enterprise Architect will provide three key artifacts during a typical engagement with an Agency, Department, or Project. These include:
The Architecture Vision is an aspirational document establishing a direction for the growth of the infrastructure of the Agency or Department. This vision reports the current state of the technology, the ideal future state, and the steps needed to get from one to the other.
The Architecture Assessment gives a Department of Agency an understanding of the current state of the of their IT Architecture. This provides a reference of the applications and services in use within an organization, as well as their interconnections.
A Governance Model defines and discloses the roles and responsibilities of all parties involved in the utilization of a service or application. It will collect metrics allowing the State to monitor successes of, and points of failure in, a given solution.
Alignment of Business Capabilities and Processes to IT Solutions
An early step of any successful project is to define its goals. This is done by understanding the requirements, both functional and non-functional, that a completed project must achieve. These requirements are informed by business capabilities and processes, what the business does and how it does it, respectively.
Enterprise Architects work with Business Architects to define business capabilities and processes that can be used to create requirements. This in turn, guides the selection of vendors, the development of solutions, and the SLAs for the final product.
Evaluation of Award
Enterprise Architects assist in the evaluation of a solution provider for its adherence to Non-Functional Requirements, Enterprise Architecture Guiding Principles, and its potential integration with the current infrastructure. As well, the EA will explain any potential risks in incorporating a solution within the current architecture.
Following the selection of a service vendor, the process moves onto contracting. At this point the EA works in an advisory and oversight role ensuring the contract includes applicable NFRs and correct deliverables from the vendor to enable architecture oversight, and to ensure the seamless transition from Implantation to Maintenance and Operations.
The Enterprise Architect will model the overall cost of the application or service over a five year period. This allows the Agency or Department know the “real” cost of the solution, and that it is reportable.
Cost modeling includes the initial implementation cost, licensing and hosting costs, and augmented staff required to maintain the application or service.
Sustainability links cost modeling with Strategy activities to ensure that vendor contracts align with the overall IT and Enterprise strategies and policies of the state.
Contract Review and Approval
Enterprise Architects work for the CIO to provide preliminary reviews of final contracts, provide feedback on the inclusion of necessary deliverables; specifically, documentation required to ensure proper handoff from development to maintenance and operation teams.
This also applies to contract renewals and extensions.
During Implementation the Enterprise Architect works closely with the Project Management Team to review applicable vendor deliverables and to ensure that they are in accordance with the terms stated during contracting. These reviews are done across design & development and implementation.
Architecture Exceptions are deviations from the accepted State Architecture Guiding Principles and can occur at any point during the service or application lifecycle. When they occur, the Enterprise Architect acts in an oversight capacity; they review exceptions, weighing potential risks and costs against the benefits of the exception.
With the backing of the CIO, Exceptions are approved or denied. Exceptions are then recorded for their effect on future integrations.
Operations is the final stage of a new service or application’s lifecycle; at this point, it is no longer in development. However, the transition from Implementation to Maintenance and Operations (M&O) is key to ensuring that a service or application continues to run smoothly.
Enterprise Architects at this stage work to collect and coalesce governing documents, roles, and responsibilities. As well, EAs advise the Change Control Board of the impact of new services or applications on the platform.
Vendor Relation Management
EAs work closely to manage relations between Implementation and M&O teams. They work to ensure standardization of deliverables.
Service Level Agreement Oversight
Enterprise Architects monitors SLAs based on Architecture Guiding Principles and Non-Functional Requirements.
Enterprise Architects advise the Change Control Board on the impacts of changes to Enterprise systems and applications.
Change Request Review and Approval
Enterprise Architects review Change Requests for their impact on the Enterprise Architecture. Where applicable, they can call for Architecture Exemptions when changes will deviate from the approved architecture.