11 Jumping to Phase G
Many Practitioners will be regularly faced with their organization “Jumping to G”. Many organizations select leadership on their ability to get things done. This creates a bias to action. Enabling effective change requires balancing predictable planned change with innovation and creativity.
Organizations that jump to Phase G will jump either because of organizational preference for visible action or execution failure by the EA team. In both cases, good Practitioners will respond to their organizational culture or to their failures. It is outside the scope of this Guide for Practitioners to discuss effective engagement and Enterprise processes; see the TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability (see Referenced Documents).
The chapter will address classic failure patterns:
- Missing the purpose
- Missing the business cycle
- Not doing architecture
This chapter will also identify how the Practitioner addresses unpredictable change resulting from innovation, creativity, and circumstance.
An EA is developed for one very simple reason: to guide effective change. Guiding effective change involves serving decision-makers and implementers. Architecture to Support Strategy, Portfolio, and Project are focused on supporting decision-makers and are directly tied to planning stages in the business cycle. Architecture to Support Solution Delivery is primarily aimed at implementers. When the Practitioner does not provide timely support for strategy, portfolio, and project, the organization will continue to make decisions using the information at hand on the day the decision must be made.
Without a good Target Architecture to Support Strategy, Portfolio, and Project, the organization has jumped to Phase G. Typically this happens for two reasons: misalignment and missing the purpose.
Actual misalignment is outside the scope of this Guide. For advice on the alignment of the EA, see the TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability (see Referenced Documents).
Most examples of misalignment in the industry are actually Practitioners missing purposes other than solution deployment.
11.1 Failure Pattern: Missing the Purpose
As clearly articulated earlier in this Guide, different purposes require different architecture. The actual work product and analysis project to produce a view demonstrating to a change leader how a candidate architecture addresses agility for the purpose of strategy is radically different than for the purpose of solution deployment. Practitioners must adapt the basic structure and concepts to different purposes. Too much advice masks the essential differences by using terms such as high-level or aspirational or conceptual or logical. A good Practitioner will know how to distinguish high-level work for the purpose of strategy from high-level work for the purpose of solution delivery.
Every stakeholder and every concern are addressed in every purpose.
Practitioners miss the purpose when they tell themselves stories about breadth, depth, and timeframe. As discussed in Section 3.2.1, there is a set of rough guidelines regarding breadth, level of detail, and planning horizon. Further, regardless of the exact parts of the EA Landscape that must be addressed by any particular architecture development project, a Practitioner will find themselves without clean edges.
Architecture to support a purpose is typically aligned to support different points in the business cycle, and required to inform different decisions, as all work must be aligned to the purpose at hand. This may change the key work product’s essential purpose, but is unlikely to substantially change which components in the architecture must be analyzed.
11.2 Failure Pattern: Missing the Business Cycle
Most leaders are interested in receiving effective advice about complex decisions. Usually, the Practitioners are waiting for an invitation to a planning process that will never come. Leaders may be surrounded by parochial champions who wish to pitch their pet projects. In response, they actively seek to reduce involvement in planning processes to those who provide useful, balanced advice and those they wish to hold accountable for the change.
Delivering architecture to support the business cycle requires being ahead of decisions. The Practitioner works ahead of the planning cycle (see Figure 4). For many Practitioners, working ahead of the planning cycle is an uncomfortable position. They must be focused on preparing for activities that no one else is thinking about.
For example, Architecture to Support Portfolio facilitates the budget process for an organization that operates an annual budget process. With such a cycle, the budget finalization is likely done near the end of the third quarter. This requires the budget planning to be done near the end of the second quarter, which requires the first draft of the candidate Target Architecture and candidate roadmap to be available for the second quarter. Stakeholders and decision-makers are then able to use the candidate architecture and candidate roadmap in planning and preparing their budget submission and defending their submission in any resulting budget negotiations. The Practitioner then needs to understand their candidate material is used, stretched, and changed through the entire budget preparation and negotiation. In short, the Practitioner is involved in iterating through Phase E and F through the second and third quarter.
Practitioners who are unfamiliar with the give-and-take typical in most organizations’ planning processes will wait for clarity or decision. Both are only available at the end of the planning process, not in the middle. As a result, the Practitioner has missed their place in the business cycle.
11.2.1 Architecture after Decision
This Guide is designed to assist Practitioners to deliver useful architecture. Architecture produced after decisions is not only late but may cause conflict. At best, the architecture will validate the decision. Given the decision has already been made by leaders with the authority to make the decision, validation is pointless. At worst, the architecture will demonstrate the leaders made the wrong decision. It is technically useful to gain this knowledge and perform a course correction. The damage to the EA team and wasted time and effort executing the next steps following the decision are unlikely to be compensated by a better decision.
Practitioners adept at establishing value will be keenly aware of the impact time has on almost every value calculation. Lastly, Practitioners adept at estimating the cost of change will be keenly aware of how expensive misfires are on the ability of an organization to execute an effective change.
Few activities a Practitioner can perform are as dangerous as architecting after decision.
11.3 Failure Pattern: Not Doing Architecture
Practitioners will often fulfill multiple roles in the architecture development and change process. Chapter 15 identifies stakeholder, SME, architect, implementer, and auditor as the essential roles in architecture development. Practitioners will typically act as an agent for the stakeholder, making decisions by proxy through their understanding of the set of stakeholders’ preferences. Many Practitioners, by way of their growth path, would have expert knowledge in specific domains; they will tend to provide advice and guidance as SMEs to stakeholders, other architects, and implementers. Some Enterprise’s structure may demand a Practitioners to act as implementer. An implementer normally pays attention to details like product selection, configuration challenges, assuring quality and repeatability, etc. These tasks are often sufficiently time-consuming that the Practitioner does not have time to perform architecture.
Many EA teams fall into the trap of performing implicit architecture. The Practitioner is so busy acting as a stakeholder’s agent, SME, and implementer that the architecture is never described and approved by a stakeholder. A work product that is really implementation design, and implementation specification and standards definition is provided as the end result of the “Architecture Project”. These work products are the end result – they are not architecture.
Chapter 15 will discuss the need to deeply review implementation work products that exist unsupported by architecture description, views, and architecture specification. Bluntly, what evidence can a Practitioner provide that the implementation is in conformance with the architecture, provides the best available approach to addressing the stakeholders’ preferences and the organization’s mission, vision, value proposition, and objectives? The only choice is compliance by assertion.
Compliance by assertion is rife with personal bias and “tourist dashboard decisions”.
Practitioners deliver value not by tripping over the correct implementation but by facilitating the complete set of stakeholders to understand the implications of their preferences in the context of the Enterprise’s mission, vision, value propositions, and objectives. Whether this is done on the easy path by preparing views addressing concerns or by facilitating trade-off between competing decisions is immaterial. The absence of understanding means the architecture, and the value it enables, is fragile. The moment the Practitioner is unengaged on landscape, there can be no expectation that the value will be sustained by operational teams and future implementation teams who are unaware of either preference, priority, or traceability to value.
Without an architecture, the Enterprise has no choice but to jump to Phase G – completely unprepared, with no ability to exercise implementation governance.
Not performing architecture to support decision-makers and implementers is the most pernicious practice a Practitioner can perform.
11.4 Managing Innovation, Creativity, and Circumstance
Top-down direction and planning provides part of the answer for a nimble organization. It provides the guidelines, constraints, and clarity required to make tactical decisions. Sometimes the correct decision is to embark on unplanned change.
Whether the Practitioner has arrived at implementation of change unprepared because of a failure or because of a good deliberate decision, the Practitioner still needs to provide useful support of the change activity. Stakeholders simply have to have less confidence that the project will deliver the expected value with the expected cost and the projected time. The range of unknown ones precludes high confidence.
This lack of confidence simply means the architecture has more uncertainty, or risk, associated with realizing the organization’s objectives. At this point, Practitioners have to focus all of their energy on risk mitigation.
Pragmatically the Practitioner is going to be constantly performing a risk management function. Rather than diving into the details of implementation the Practitioner needs to find and expose uncertainty associated with the objective to provide tactical governance support. Every project will have some form of benefits statement. Every organization has some form of strategy. The Practitioner simply has to connect the dots without the benefit of any intermediate stepping stones. The important distinction here is that the Practitioner is not expected to correct the project regarding benefits statement and realization plan. The Practitioner is expected to mitigate uncertainty regarding realizing the benefits stated in the project.
TOGAF Phase G provides a step for this activity where the Practitioner provides guidance to the Implementation Project. The Practitioner must walk a line between guiding and performing implementation.[32] Implementers are expected to live within the constraints of the project; Practitioners are expected to look at the context of the project. The most valuable actions when the organization jumps to Phase G are identical to addressing rapid implementation methods such as agile. The Practitioner must focus on the scope of the Implementation Project, facilitating good decision-making in the context not of project benefits realization but of Enterprise benefits realization, and ensuring the stakeholders and implementers understand the implications of their choices regarding Enterprise benefits not driving them to make different choices. This is a very fine distinction and is it a reiteration of not fixing the project but ensuring stakeholders and implementation teams understand what can honestly be expected in terms of value and benefit.
Innovation and creativity are at the fore when an organization jumps to Phase G. Thoughtful architecture development providing guidance and constraints at the required level of detail will be missing. When the Practitioner’s organization is in a hurry they are focused on receiving value through differentiation and experimentation. Typically, a sustained efficiency gain is not achieved without clarifying dependency. Practitioners should expect that organizations in a hurry are usually fully aware of the difficulty sustaining experiments across time and when scaled. Hence, the Practitioner must focus on value realization. Bluntly, this is not different than a more thoughtful approach: The stakeholders’ preference and priority drives the architecture development.
In terms of the TOGAF ADM phases, the Practitioner will be running constant micro-iterations exploring discrete statements of value through to the implementation, with the purpose of clarifying the value expected and what in the implementation creates uncertainty. In order to perform this, the Practitioner will have to focus all attention on a narrow set of concerns on the critical path to value realization.
When the organization Jumps to Phase G, the Practitioner will routinely need to act as the stakeholders’ agent. Practitioners must be keenly aware of the danger acting as both the architect and the stakeholders’ agent. Care must be taken to guard against tunnel vision, personal bias, and “tourist dashboard decisions”. Specialized reporting against the narrow set of concerns on the critical path to value and the Implementation Project form the control that mitigates lack of preparation and failing to separate duties.
return to top of pageTOGAF® is a registered trademark of The Open Group