Purpose
Importance of having an Effective Governance Process in Enterprise Architecture.
Premise
During my Tenure in Information Technology as a Software Professional, I have been fortunate to work in the role of Solution Architect, performing responsibilities of Architect, Design/Develop Enterprise Applications, across different domains including financial services, insurance, Banking, Human Resources and Benefits and Claims administration. The teams/organization that I supported varied is all size categories Small, medium to Large and the Deployment of the applications were in all flavors as well (On prem, cloud native, private, hybrid). The Architecture in these domains and applications have evolved as well from Waterfall projects where the investment in Architecture and design was heavy upfront and documented before a line of code is written with little or no room for changes during the project flight to now more Agile where in an incremental and evolutionary approach is followed.
The Architecture team organization and Role were arranged in different flavors too –
Single or two role/s per team across the organization.
A separate Enterprise Architecture team used as a "Shared Service" supporting other teams (internal partners) across the organization.
Separate Architecture team across sub organizations.
Observation
In all of the different structures/paradigm the Architecture role/team are arranged – Without a centralized Governance there were always "Chaos" that ensues sooner than Later
Let me try explain what "Chaos" may seem/feel like – Most may relate to these.
No Uniformity in design of any aspect of application across any layer (front, middle, back end, integration etc.)
No systemic way to communicate the finer aspects of the reasoning behind the "why" and "how" it came about
No common Language to communicate across the team
No notion of a "portal" – One stop for all Developer Needs – I am referring Developer for this In context of a new person onboarding – A centralized place for them to know everything that is to be known to start their job – As to how and what they need to do their Job. Of course this portal is useful for any resource, especially in an Agile/API first based approach needs. Any one who needs to know anything about an API, tool, system etc.
All these will soon cause Chaos in the process with growing distress with in and also across teams.
Centralized Governance to Address Chaos
Having a centralized Technology Architect group which may also perform centralized Governance activities to Manage Architecture requirements and subsequent solution design and execution provides necessary framework to manage chaos described earlier. Described the Governing process below across the various steps during an engagement right from Ideation till Execution.
The following are the steps and responsibilities of team/resources to ensure project is centrally Governed and managed at all phases of its Life cycle.
Engagement and Architecture Review Process (EAR)
The following is what occurs during the Ideation step. This engagement model ensures architecture is involved and engaged and understands their responsibilities.
| Step | Notes | Responsibilities/Ownership |
| 1. Technology receives idea request | Technology intake is notified of a new idea to review due to technology engagement needs | Business / Product owner (Product Management) |
| 2. Architect assigned for concept review | The engagement manager / Product owner / Manager in product team will reach out to the Architecture team / Manager. Lead Architect who has a broad understanding of what’s happening not only in sponsoring organization, but also the enterprise will review and participate in the concept review process and the complexity of the Idea is evaluated as well. | Product Owner / Manager & Architecture Manager |
| 3. Concept review is held | The working team (Assigned Technical Architect) in the Architecture organization reviews the Idea, complexity of it, to determine if there is capacity and alignment to move the Idea forward | Working team / Technical Architect in Architecture organization |
| 4. Identify Impacted Applications | Assigned Technical Architect works with Aligned Technical Manager to identify impacted application/s for the Idea. | Technical Architect |
| 5. Idea is dispositioned | The working team, including the technical architect, dispositions the idea and communicates the decision to the Product / Project Team | Working team / Technical Architect |
The following occurs during the Initiation step. The setting of the architecture Impact Criteria, creation of the Architecture Direction Document (ADD) and subsequent approvals provide the traceability for Architecture Governance.
| Step | Notes | Responsibilities / Ownership |
| 1. Assignment | The technical architect to the Idea is automatically assigned to the project when the transition from Ideation to Initiation occurs | Technical Architect |
| 2. Understand Project | The Technology Architect (TA) is a key member of the team. The following are a few of the specific expectation of the TA in this step. - Engage with other participants of the Estimation team, Review Project Scope and determine the Impacted applications and teams, Evaluate project scope for Technology Impact. Work with PM to align the project scope to the appropriate Technology direction. | Technical Architect, Estimation team, Product Manager (PM) |
| 3. Initiation Assessment and Engagement | Technical Architect will determine Architecture Impact and determine answers to the following Questions and document the same - Cross CIO Impact?, Solution Type, Vendor Integration, New Vendor (provide name), New Technology,Additional notes to explain Architecture impact | Technical Architect |
| 4. Third-Party Engagement Rating | Significant – Third Party Solution. Third party is an active participant in the effort and has deliverables that are crucial to the success of the effort. Solution is hosted at third party, Significant – Internally Hosted. Third party is an active participant in the effort and has deliverables that are crucial to the success of the effort. Hosted internally. Moderate – Third party is involved in successful delivery of the solution. Minimal – Third party is making minor changes to its solution. None – No third party involvement in the solution being delivered. | Technical Architect |
| 5. Security Questionnaire | Work with Security Architecture address possible security related issues with the solution and address them | Technical Architect/Security Architect/Cyber Security |
| 6. Create ADD (Architecture Direction Document) | ADD will be required to be created and presented to ARB. Purpose of this artifact is to document the architecture approach in solving the Idea scope | Technical Architect |
| 7. ADD Approval | Review with Architecture Governance and receive approval | Technical Architect, Architecture Review Board (ARB) |
The following is what occurs during the Planning phase of the project. This engagement model ensures architecture is involved and engaged and understands their responsibilities.
| Step | Notes | Responsibilities / Ownership |
| 1. Identify any additional architects needed | Architects are brought over from the Initiation Phase. The Technical Architect identifies other architects that need to be involved. | Technical Architect, Domain Architects |
| 2. Review Requirements | Technical Architect reviews the requirements. If the requirements warrant a change to the Architecture impact, the change needs to be made and any additional artifacts that are required by the change needs to be added to the project plan. | Technical Architect |
| 3. Create Systems Architecture Specification (SAS) | Technical architect works with other identified architects and the project team to create he Systems Architecture Specification document and identify the approvers based on the teams impacted. | Technical Architect |
| 4. Review and Approve SAS | Technical Architect work with Architecture Review Board (ARB) and receives Approval | Architecture, ARB |
| 5. Review and approve Solution Design | Technical Architect reviews and approves the solution design ensuring the design is in alignment with the approved architecture. | Technical Architect |
The following is what occurs during the Execution phase of the project. The execution phases includes the creation and execution of packages that meet some deployment goals of the project. This engagement ensures that what is designed as part of the package is in alignment with the overall architecture of the project.
| Step | Notes | Responsibilities / Ownership |
| 1. Open Implementation request for the Project | Product Manager /Project manager opens an Implementation that has a set deployment date for a set number of Deliverables. | Product/Project Manager |
| 2. Review Implementation Scope | Technical Architect reviews the scope of implementation to ensure it’s in alignment with the current architecture solution and if there’s a change in architecture impact. | Technical Architect |
| 3. Solution Design for Implementation | The development team along with the identified subject matter experts create the solution design for implementation. | Technical Architect |
| 4. Review and update against SAS | Technical architect review solution design to ensure alignment with the approved SAS. | Technical Architect |
| 5. Review and approve Solution Design Implementation | Technical Architect participates and require the solution design implementation and provide approval stating it’s in alignment with the SAS. | Technical Architect |
Any changes to the architecture impact or alignment with SAS can be tracked with a separate Change request to track the required changes and also tie the approval with the required members of the impacted team and overall with the Architecture Review Board, part of the centralized Technology Architecture Group.
The process documented above helps in establishing a well Governed process to Effectively Manage Enterprise Architecture