14   Phase H (Coordination and Business Cycle in Action)

An EA is developed for one very simple reason: to guide effective change. The change can be materialized only when it is adequately supported with resources. Every Enterprise has a business cycle that plans and allocates resources, normally one fiscal year. The fiscal year dates are inflexible and decisions will be made with the data available and reasonable judgment.

If the EA Capability has been requested by the Enterprise, it is an acknowledgement of the fact that “implicit” architecture and the resulting judgments that drove investments and changes are not delivering what the Enterprise wants. It is likely that the EA effort was kicked off after the budget allocation for the current business cycle or with very limited time to influence the decisions of the current business cycle. Do not waste time in the current cycle. Stay happy with the “implicit acknowledgement” and focus on building the data for the next cycle. Though not stated, the sponsor is looking to protect “future” decisions with EA. The moment the Practitioner realizes they are late for the next cycle, shift the time investment to refurbish the résumé of the entire team (see Section 11.2).

Phase H demands the Practitioner to identify the bottom-up drivers for change; change due to improvements in available technologies or conditions controlling the operations or environment of the Enterprise; and initiate the architecture work for the next target transition state (top-down driver). This does not mean that the Practitioner need to flesh out everything that is covered by the charter for the EA Capability or the budget.

Earlier chapters impressed upon “just enough architecture” and characteristics of the EA Landscape. Understand the capacity and capability of the team to scope the work. Remember, the definition of “Enterprise” is fungible and used to control the scope of analysis. If this is the first pass in developing the Architecture to Support Strategy, scope the effort accordingly. Define and distribute the work packages in proportion to the capability and readiness of the Enterprise. All of these are aimed at one thing – influencing and garnering the resources in the next cycle.

Tying everything to the budget cycle simply highlights the importance of good EA in guiding and constraining the change decisions. When there is no practical input from a good EA team before the decision an organization needs to take is made, the decision is still made. It might even be a good choice, but it was a less informed choice.

The moment there is awareness that data was available, but late, irrespective of the quality of the decision made, the EA team loses its relevance. It is a fail-fail scenario resulting in questioning the value and purpose of the EA team.

Depending on the size of the Enterprise (irrespective of the scope of the EA work), budget preparation may start two to four months before the start of the fiscal year. The Practitioner, the Implementation Project architect, and the Implementation Project manager need to play the role of SME to assess the ability of the implementation team to complete all the work packages at least two to four weeks before the start of budget preparation date.

Other than the first year of operation of the EA team, most subsequent architecture work is initiated from Phase H. Phase H provides ongoing review of value realization and monitoring of change. Change and failure to realize value provide entry points to the ADM. Never be late – four weeks before the start of budget planning is too late. The EA team needs to be aligned with the organization’s planning, budgeting, operational, and change processes. Figure 19 shows a timeline view, depicting an alignment of key decisions made during a business cycle and the purpose architectures.

Figure 19: Business Cycle and Architecture by Purpose

Once the Practitioner’s communication informs and influences the budget planning, the path forward is set. This superior architecture governs and constrains the rest of the activities.

The second most important activity is supporting budget control. The architect of the Architecture Project is the agent for the stakeholder for the implementation team; the architect is also the SME for the portfolio manager in validating the progress earned to value. It is common to see a Practitioner tripped by the duality of role in the budget control phase to lose focus on the budget planning activities. Never forget that the sole purpose of the Practitioner is to influence and guide change – not to get into the detail of implementation.

The EA team is intentional about every effort, irrespective of the name used – process improvement, operations, Keep-The-Lights-On (KTLO), growth, transformation, etc. Every effort and idea contributes to the Target Architecture. Even through the superior architecture constrains the Architecture to Support Portfolio and Project, nothing is committed and accepted as the next transition state until resources (budget) are allocated. Random ideas from the wild (see Section 8.6) will find their way into the process. The Practitioner watches like a hawk to identify such interesting work packages and triggers a review, trade-off, and governance of the “new” portfolio. Unless sufficient insight is gained about the “behavioral” patterns of the organization, it is difficult to discern “pet projects” and “random ideas” disguised as “bottom-up” effort from a legitimate initiative to bridge a gap. Perform a simple sniff test – is the architecture specification trying to accomplish more than one thing; stakeholder trade-off – are the concerns aligned or being accepted for lack of time to analyze. Create a change request and leave a bread crumb to revisit and stabilize the architecture in the next cycle.

Understand how the Enterprise employs discretionary funds; use them wisely. A practical approach would be guiding allocation of such discretionary funds for exploratory work packages, until the alignment to roadmap could be rationalized and included in the portfolio. Acceptance of such requests is an explicit change to the Target Architecture. Avoid as much as possible. Follow the change management processes. No exceptions. The role being played by the Practitioner at this stage is more of a mediator and negotiator, applying the architectural knowledge. At the end of the day, the Practitioner is responsible and accountable for the stability and integrity of the architecture.

At the time of finalizing the allocation of funds, good architecture will speak for itself. The Practitioner need not be in the room to guide the decision. When the allocation happens, the decision-makers are validating that the project manager, portfolio manager, and the implementation architect fully understand and agree to deliver the outcome in conformance to the architecture. The decision-makers are already convinced of the need for the project and its outcome. If the Practitioner enters a scenario requiring change to the architecture, it is too late. The foundation is faulty. The Architecture Project and the Implementation Project cannot proceed. Go back to the architecture specifications and stakeholder concerns. Be prepared to face the consequence of incomplete work.

If the Practitioner had followed everything in this document up until Chapter 12, everything mentioned in this chapter should appear to be a foreign concept. Otherwise, start over with this document.

return to top of page

---

---