It's time for governance! The Implementation Governance iteration covers Phase G of Implementation and Phase H of Architectural Change Management. Folks in enterprises have a love-hate relationship with governance because it is deemed as clunky, expensive, and tedious, despite the fact that it holds people accountable for business-aligned exercises, which keep the business legitimate and running effective and efficient manner if processes are well defined.
Phase G – Implementation Governance
Implementation Governance Phase G will provide architectural oversight to enable the implementation stay on course. Simply said, it provides general oversight of the implementation and ensures conformity to the target architecture while conducting related implementations, as well as being actively involved in the facilitation of architectural and technical decisions during implementation and deployment. An Enterprise Architecture, according to TOGAF, is a vehicle for strategy formulation and execution. TOGAF ADM phases A through D enable strategy formulation by producing a precise blueprint for the project that incorporates multiple portfolios. Phases E through H are devoted to putting the approach into action. Well said; strategy, tactics, and operations all work together in enterprise architecture.
Approach
The methodology and sequence of the procedures for this implementation phase will differ considerably on the designs' strategy, project scope, and established architectural governance:
- verifying the deployment scope and priority with stakeholders and in accordance with the architectures created thus far.
- Identifying deployment resources and skills is critical; if not, training could be a possibility as part of the deployment and deployment architectures.
- drafting applicable agreements and contracts to ensure that stakeholders understand exactly what is expected from the architecture and implementations,
- executing compliance checks to ensure that work is done in accordance with the specified architecture governance This gives stakeholders assurance that the job will be completed as planned and designed.
- And doing actual implementation!
- Conducting post-implementation reviews to determine what went well, what went wrong, and what could be improved for the next round.
Architecture Contract
The following are the terms used by TOGAF to describe contracts:
Architecture contracts are joint agreements between development partners and sponsors on the deliverable’s quality and fitness for purpose oven architectures.
To ensure that the system is constantly monitored, a governed method is necessary:
- Making an audit of all architectural-related activity well within organization impacts the decision's legitimacy.
- Verifying that the existing or developing architectures' principles, standards, and requirements are followed.
- Identification of risks in all facets of architecture development and implementation, including internal development against accepted standards, policies, technologies, and products, along with operational aspects of architectures, so that the organization can continue to operate in a resilient environment.
- Assuring the establishment of a set of processes and practices which will assure accountability, responsibility, and consistency in the generation and use of any of architectural artifacts.
- Assuring that there is a formal understanding of the governance organization responsible for their contract, their level of authority, and the extent of architecture there under control of this authority.
- Guaranteeing integrity, policy adherence, risk management, proper use of artefacts, and awareness of governing authority.
Architecture Vs. Implementation
The degree of conformance, compliance, and consistency can be used to understand the relationship between an architecture and its implementation (to ensure that what's delivered is what has been agreed and documented).
TOGAF States of Conformance
Six states of conformity are defined in TOGAF, and they are:
- irrelevant,
When an implementation has no features in common with the architecture's standards, it is irrelevant.
- consistent,
The implementation is consistent when it shares some features with the architecture's specifications and those features are implemented in compliance with the specifications. However, portions of the architecture's specifications are not implemented, and the implementation includes features that are not addressed by the specifications.
- compliant,
A compliant implementation is one in which some elements in the architecture's specifications are not implemented, but all features implemented are covered by and in line with the specifications
- conformant,
conformance occurs when all features in the architecture's specifications are implemented in accordance with the standards. However, some additional features are incorporated that are not in compliance with it.
- fully conformant
Full compliance refers to the complete correspondence between the specifications of the architecture and the implementation. That is, all defined features are implemented in line with the standards, and no features that are not covered by the specifications are implemented.
- Non-conformant
occurs when any of the aforementioned features in the architecture standards are implemented in a manner that is not in compliance with the specifications.
Inputs and Outputs
This phase's inputs are summarized in the following list:
- Frameworks for corporate IT and architecture governance,
- capability assessments,
- enterprise architecture organizational models:
- the scope of organizations that will be affected,
- maturity assessment,
- gaps,
- a resolution approach,
- roles and responsibilities for architecture teams,
- constraints on architectural work,
- budget requirements,
- governance and support strategy,
- requests for architecture work,
- statement of architectural work,
- architecture roadmap
- implementation migration plan,
- architecture vision and repository.
Additionally, Phase G could yield the following results:
- solutions deployed that achieve specified levels of conformance:
- the architecture-compliant system that has been implemented (Actually, the implemented system is an output of the development process, but due to its significance, we can consider it an output of the ADM here)
- A populated architectural repository could be one of the deployed solutions that meet the necessary level of conformity,
- recommendations and exemptions for architectural compliance,
- guidelines on the prerequisites for service delivery,
- suggestions for performance metrics,
- agreements concerning service levels,
- the architecture vision,
- post-implementation update.
As a result, such outputs were included in the delivered solutions. However, additional outcomes of this period could include:
- architecture contracts,
- conformance assessments,
- change request,
- operations frameworks.
Phase H – Change Management
Architectural change management is the process of developing methods for managing change to new architectures. Because change management in this context is centered on enterprise designs, the enterprise ought:
- create change management practices,
- Give guidance after assessing the impact of various types of changes that occur over time,
- Provide feedback on whether changes should be approved, rejected, or postponed,
- keeping an eye on the architecture, which is being transitioned,
- ensuring that the architecture achieves the initial business value aim.
The goal of this phase of change management is to ensure that the architecture lifecycle is maintained so that the enterprise architecture capability meets current requirements and adapts to changing requirements.
Approach
Architecture Change Management helps achieve intended business value. Moreover, architectural change management guarantees that modifications are not buried in committees. As corporate objectives, policies, and technology evolve, this architecture change process will investigate the potential benefits to architectures, which will then influence business processes, technology, and how it is used, among other things.
There is also the requirement to assess if a change is minor, simply requiring an update to a specific aspect of the architecture, or major, necessitating a new cycle of the architecture development technique. As a result, the governance body will create criteria for making that choice (a compliance report will be useful in this case). Changes are broken down into three broad categories under the TOGAF framework:
- simplification,
Change management approaches are typically used to address a simplification change.
- incremental
Depending on the nature of the change, an incremental change may be manageable using change management approaches, or it may necessitate substantial redesign.
- rearchitecting
A rearchitecting change necessitates taking the entire architecture through an architecture development cycle.
Inputs and Outputs
Inputs to this phase include outputs from earlier stages, change requests, and requests for architectural work, which might involve both technical and business changes. A signed architecture contract, governance model, architecture vision, roadmap, architecture definitions, and architectural needs are all inputs.
Authorization would be denied, or modification requests would be postponed as outputs. Architecture evaluations, including compliance assessments, would be another result of changes to the architectural framework and principles.
Architecture Requirement Management
This phase is more akin to a process that ensures requirement identification and management throughout all phases of ADM. As the iteration progresses through various iterations, either requirements are generated, confirmed, or activities and processes are submitted to requirements, or adjustments to requirements are requested. In accordance with TOGAF:
A requirement is a quantitative statement of business need that must be met by a particular architecture or work package.
Using the Preliminary and architecture Vision phases guidelines and architecture capability required to take on the business change; would be determined and established. The following steps would be to define the project's scope, identify stakeholders, construct the architecture vision, and secure approvals to proceed. This includes developing requirements for future work, which are defined in the requirements specifications document and stored in the Requirements Repository.
With the Preliminary and Architecture Vision phases completed, the focus turns to the second iteration in the ADM, which is made up of phases B, C and D.
Phase B would involve gathering requirements for the business domain. These would be documented in a draft version of Architectural Requirements Specifications and stored in the Requirements Repository for easy access by relevant stakeholders.
More requirements would be added in Phase C, but only in relation to information systems. This is related to application requirements and data storage, ensuring that the best apps are picked. Then there are budgeting criteria that apply to all iterations. As a result, the requirements are being added in order to improve the project.
The prior requirements would be analyzed in phase D so that the technological requirements could be identified. The technology must be created to meet the needs of the data and applications. Security, failovers, continuity planning, availability, capacity, maintainability, performance needs, and technology budgets are just a few examples.
The transition planning iteration in phase E has its own set of requirements. As a result, this phase may be concerned with collaboration across business units and may include participation at change meetings. In this phase, there are also requirements for the development of work packages, budget requirements, and IT service management requirements.
In phase F, it is vital to describe the resources needed and the timeline for each project. It is also necessary to define the implementation phases and estimate expenses, as well as cost categories. The Requirements Specifications are one of the key outputs of Requirements Management phase. They provide a quantitative view of the solution by providing quantifiable criteria that must be met during an architecture implementation. Success measures, architectural requirements, business service contracts, application service contracts, implementation guidelines, implementation specifications, implementation standards, assumptions, and restrictions are typical contents of Architectural Requirements Specifications.
In phase G, the cost and time requirements will be assessed alongside the requirements for the actual deployment, including business and operational requirements, to ensure that other IT and business services are not disrupted.
During the change management phase, architectural requirements management will ensure that the proper procedures are in place to allow change management to gather and understand requirements in order to guarantee that modifications meet their authorization.
The distinction between functional and nonfunctional requirements should be made here. Usable features are represented by functional requirements. Business requirements, for example, may indicate that data must be entered before a modification request needs to be authorized. Nonfunctional requirements are quality characteristics. For example, availability, performance, capacity, and serviceability. Nonfunctional requirements have a significant impact on information systems and technology architectures.
As a reminder you may wanna take a look back at Transition Planning Iteration and Architecture Development Iteration.
Cheers,
Mohammad Malekmakan
Disclaimer:
All opinions and content published in my blog and my social networks are solely my own, not those of my employer(s) and the communities I am contributing in.