TOGAF - Architecture Capability Iteration

In previous post I wrote about TOGAF ADM Iterations and this post is a note on the first iteration; Architecture Capability Iteration.

Preliminary Phase

The preliminary phase's main goal is to establish the enterprise's architecture capability, which necessitates the creation of a multitude of architecture partitions with defined boundaries, ownership, and governance. Keep the end state in mind in this phase. Another thing you should do is determine the architecture capability organization's desired, and then create or change the architecture capability to guarantee it is still relevant to the particular needs.

An approach to developing the architecture capability might include:

• To understand the enterprise organizations impacted by their business drivers and internal and external forces acting on the business in order to scope the impact.
• All risks pertaining to goals and forces relevant to the business vision, objectives, and targets must be outlined.
• To define and put in place an enterprise architecture team and an organization to create business blueprints.
• Creating a team structure because each architecture initiative necessitates different skill sets dictated by the initiative's complexity.
  • Dictating team structures, responsibilities, accountabilities and availability.

In summary, this approach includes the following major activities.:

• Scope the enterprise organizations
• Development a high-level view of the target state architecture
• Confirm governance
• Establish a team
• Adapt and work with other enterprise frameworks

The aforementioned approach would include a tailored architecture, framework, iterations, and capabilities, as well as other relevant architecture frameworks, to satisfy the requirements of key stakeholders in addition to business drivers.

This phase's output should allow for cross-functional collaboration and include business, data, application, and technology architectures. Moreover, confirmation on governance and support frameworks that'd retain business units accountable.

Techniques and Guidelines

TOGAF defines architecture as a structured set of components in relationships, as well as the principles and guidelines that govern their design and evolution. By time, the principles and guidelines govern how the architectural components are assembled and how the design is allowed to keep evolving.

Practically principles limit architectural options to ensure that decisions are made in accordance with the business's goals and priorities. Furthermore, the principles result in significant agreement and consistency.

Enterprise Architect is the one who determines and implements the principles typically, and it would be endorsed by key business stakeholders and the architecture board. As an EA try to develop the principles in the early stages of introducing enterprise architecture within your organization and always maximize use of expert opinions in that process. Despite the fact that the principles are timeless, they should be reviewed on a regular basis and updated as needed to fit the requirements of the business.

TOGAF recommends a template for architectural principles. Based on that template you need:

• A principal name, which is a clear and memorable name that encapsulates the core of the principle.
• You should also include a principal's statement in which you clearly state the limits of architectural options, provide guidance, and enforce governance.
• And you should be prepared to explain the rationale behind the principle briefly and clearly. The rationale is the portion of the principle that explains why the principal is needed in terms of business benefits and includes any relationships to other related principals to support the statement.

Principles are not cast in concrete, but they should also not be taken lightly too!

Inputs and Outputs

Among the possible inputs are:

• Business strategic objectives, as well as business drivers, aims, and principles.
• You could also use or should work with other enterprise frameworks based on your enterprise architecture requirements.
• Understanding the current organizational structures is beneficial.
• You should also include any architecture, frameworks, and architectural principles that you have previously used or are currently using.
• Ultimately, you should make sure to investigate any other architectural artifacts that are currently in use.

The output of this phase's analysis is a formal deliverable known as the Request for Architecture Work (RAW).

RAW is a Request for Architecture Work is a document sent from the sponsoring/steering organization to the architecture organization that initiates the architecture development cycle.

Architectural work requests might be generated not just as an outcome of the preliminary phase, but also as an outcome of approved architectural change requests. In general, keep all the information in this document high-level and you may want to include:

• Organization’s sponsors and mission statement.
• Business objectives and required changes.
• Strategic plans and business limits (such as: time limits, environment, organizational, budget information, financial, external, so forth).
• Descriptions of current business systems.
• Descriptions of current IT system architects.
• Description of organization in the process of being developed.
• Describe the resources that are available to the developing organization.

Moreover, an initial architectural repository is one the important outputs of this phase. Architectural repository is a place for storing a lot of documents and information (I may write about this further on).

Phase A - Architecture Vision

The preliminary phase results in the activation of Architecture Vision. This phase focuses on clarifying the vision for the upcoming work. The primary goals of this phase include developing a high-level architecture, as well as a vision of the capabilities and business value that will be delivered as a result of the proposed changes to the enterprise architecture developed in the previous phase. In addition, the architecture vision must define the scope of a specific architecture effort as well as the constraints that must be understood and dealt with. Another goal is to obtain endorsement in order to move forward with the architectural work. This is documented in the architectural work statement.

Approach

An approach to this phase, is to validate the business context and change drivers by illustrating benefits or instituting a value proposition that will establish how the proposed architectural work will meet expectations. At this point, as an enterprise architect, you may want to validate the business change drivers and context by identifying risks, unknown factors, challenges, hypotheses, and proposed mitigation actions; or it may be validated by identifying architectural limitations and evaluating business readiness. (primarily from a cultural and regulatory standpoint).

In addition, the approach to this phase would include:

• Sharpening the view on the high-level target state to be attained, resulting in greater clarification on the specific building blocks and capabilities that must be enhanced or forced to retire in order to meet the stated vision and objectives.
• Defining success criteria, metrics, and key performance indicators (KPIs) to track progress, as well as developing an architecture vision and statement of architectural work deliverables (that would be the main outputs of this phase and will be reused to raise funds for proposed work)

Techniques and Guidelines

Enterprise Architecture is a forward-thinking mechanism that is inextricably linked to the business. Because business-led enterprise architectures are intrinsically tied to an enterprise's strategy, specification, and execution, TOGAF motivates use of scenario planning for architecture development. Since scenario planning creates a safe environment for decision makers to acknowledge uncertainties and start debating credible capabilities that the enterprise will require to deal with those uncertainties. TOGAF, following the same fashion, recommends using Scenario Planning in ADM Phases, with a focus on Phases A and B. Let's go over Scenario Planning:

• Understanding the business scenarios.
• Identifying SMART objectives.
• Creating a view of the business surroundings, such as stakeholders and business processes affected by the scenario.
• As the scenario unfolds, identifying architectural principles and constraints in their context, as well as any limitations and restrictions.
• Translate the scenario into an actionable architectural requirement based on the stuff mentioned.

EA does not develop business scenarios. Those are frequently defined by the company's leadership and strategy teams, with insight from stakeholders involved, along with the enterprise architect which ensures that the scenarios are plausible and pertinent to the business problems at stake.

The following are some of the importance of business scenario planning:

• Business can identify and respond to changes that are more accurately aligned with their aims and priorities.
• Stakeholders will be involved in the process, which results in a well-defined architecture that ultimately ensures business process to support the enterprise's mission and goals.

Inputs and Outputs

The outputs from the preliminary phase are key inputs for this phase. The following are the key deliverables of the architecture vision phase:

The Statement Of Work (SOW)

The statement of work, that is usually the document against which the architecture project is rated, is a critical ADM document. The SOW articulates the value proposition, which may even be a legal contract with the vendor or customer of architectural services, and includes an overview of the architecture, vision, roles and responsibilities, deliverables, and measurements to monitor performance and progress. It also required signatures from the appropriate levels of leaders and managers to endorse the architectural work.

The Architecture Vision

The vision explains the problem and the key high-level stakeholder requirements, which will include the main objective of the architectural work statement. The scope of the proposed statement of work would also be included in Architectural Vision. It is possible to have a value chain diagram and a solution concept diagram, which describe the target state capabilities and demonstrate the correlation to the business scenario under consideration.

In the next post Architecture Development Iteration (second iteration) is summarized which worth it to have a look at.

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.