Enterprise Architect Review

[Geraldine Ferraiz]

Myfirst couple of nights the howler monkeys kept me up, so I got a good start on the book. What dawned on me very early on was that the reader would have a better understanding of this book if they had previously read the SOA books in this series, otherwise some of terms may be unknown to you.

This book is really reference material, and should be delved in to find a pattern for an occurring need you have. But you will have to read 100+ pages so that you can understand the terminology and the diagramming notation.

I did not manage to read much the next couple of weeks but after eating some empanadas from a street vendor in Bolivia I was laid up in bed for a couple of days which gave me plenty of opportunity to finish reading the book.

The patterns take a large set of inspiration from existing well known industry patterns such as Enterprise Integration Patterns from Gregor Hohpe and Bobby Woolf, and apply them to SOA. In addition depending on your SOA ecosystem some of the patterns may not apply.

This book was written by 10+ authors and I would have liked them to catalog some common SOA anti-patterns. Sometimes it is easier to know what to do when you understand the mistakes other enterprises have made.

I have been lucky enough to live and travel all of the world with my work.I am an experienced senior IT leader with over 25 years of diverse, professional experience in high profile environments spanning leadership, architecture, solution delivery, software engineering, and project management roles.

What that means is that, by time someone reaches the CS-04 level and is working as a senior enterprise architect, five or ten years might have gone by since they last wrote software code on a regular basis.

The future is empowered, multidisciplinary product teams that deliver services using modern tech approaches and tools, learn from their users, and iterate and deploy frequently, the same way that product teams in leading tech companies would. Actually making that happen, in government departments, involves removing external gatekeepers and dependencies wherever possible.

Enterprise architecture is baked into government IT processes all over. Departments have EA committees and architecture review boards that gatekeep new or redesigned technology solutions and the public launch of new projects. The government as a whole has a Government of Canada Enterprise Architecture Review Board (GC EARB), chaired by senior leadership from the Office of the CIO and Shared Services Canada. Each of these are mandated by the TBS Policy on Service and Digital.

VITA equips and empowers Virginia's executive branch in IT infrastructure, cybersecurity, governance and procurement services. We drive critical business connections between Virginians and their government. VITA connects, protects and innovates for Virginia's technological future.

VITA offers a variety of IT services and products to Commonwealth and local governmental agencies and entities. The VITA service catalog contains descriptions, pricing, and service-specific ordering information for IT infrastructure, security and selected enterprise services to best serve Virginians.

VITA's supply chain management group is the Commonwealth's information technology procurement and sourcing hub. The team strives to consolidate and leverage the Commonwealth's buying power to develop value-driven IT contracts that benefit agencies and Virginians.

The VITA Customer Care Center (VCCC) is available 24 hours a day, seven days a week to provide Commonwealth customers technical support and answer questions. Connect directly or use a do-it-yourself tool to reset a password or open a service ticket.

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.

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.

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.

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).

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.

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.

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.

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.

An Architecture Review Board manages the process of approving and publishing the target enterprise architecture, assessing compliance with the architecture, and determining what action stakeholders will take to correct noncompliance.

There are many misconceptions about effective enterprise architecture review boards. It is a governing body that ensures the right stakeholders make informed decisions. The architecture review board ensures we follow best practices to develop an enterprise architecture, and when executing projects following that architecture. A governing body, not a decision-making body.

An Architecture Review Board manages the process of enterprise architecture governance. This includes the process of approving and publishing the target architecture, assessing compliance with the architecture, and determining what action stakeholders will take to correct noncompliance.

There are many misconceptions about effective enterprise architecture review boards. It is the centre of enterprise architecture governance. It ensures that best practices to develop an architecture were followed, and the stakeholders approved the target. It also ensures that best practices to review change projects were followed and the same stakeholders made choices when the architecture wasn't followed. A governing body, not a decision-making body.

3a8082e126