4 Business Cycle

All organizations have existing change processes. The EA team needs to be aligned with the organization’s planning, budgeting, operational, and change processes.[17] The Practitioner must understand that a theoretically perfect world where the EA team is engaged in all change cannot be expected. In practice, the scope of the EA team will be limited to some purposes, or will only be engaged in some changes. The TOGAF Standard says you need to configure the ADM to align to your business. This is commonly interpreted to fit the ADM as an end-to-end process as an appendage to existing business processes. Instead, the architecture development processes need to feed, and support, the existing change processes. This means the ADM is used to deliver work products useful to other processes, and just enough of the ADM is used to deliver to other Enterprise processes.

4.1 Budget Cycle

For most organizations, the budget cycle controls change in the organization. Pragmatically, the EA team will be aligned to the budget cycle. Figure 4 shows a timeline view, depicting an alignment of key decisions made during a business cycle and the purpose architectures. EA for Strategy, Portfolio, and Project need to be completed before key milestones for budget decisions are made. EA for Solution Delivery is a continuous operation around budget control. The key takeaway is architecture before the decision. If you are trapped trying to architect after the decision, see Section 11.2.1.

Figure 4 provides a simplified budget cycle for structuring what is universal.:

• Budget Planning identifies what is needed and what new initiatives will be started
• Budget Preparation is typically a top-down and bottom-up activity – guidance about expectations and initiatives will be provided from the top, and each department will develop a spending request
• Budgets provided are the subject of further decision-making

Allocating budgeted funds is a key step in executing change. A good budget is a financial embodiment of the organization's priorities for the current budget cycle. Prior to allocation to an Implementation Project everything is just an idea.

• Budget control is ongoing financial and benefits realization of an Implementation Project

Figure 4: Business Cycle and Architecture by Purpose

Keep in mind that the simple unidirectional model allows us to see the interplay between key decision milestones. This Guide uses the phrase “Architecture to Support” deliberately. The change process executes with or without a functioning EA team. The pragmatic question is what an EA team can do to guide effective change.

As mentioned earlier in this Guide, it is best to tie everything to the budget cycle. The importance of good EA on guiding and constraining the change decisions is naturally noticed and highlighted. 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.

Keep in mind that in all EA the stakeholders, decision-makers, and implementers require effective support ahead of the decision. Good architecture that informs decision is infinitely more valuable than perfect architecture that follows decision and execution.

4.1.1 Budget Planning and Architecture to Support Strategy

The linkage between budget planning and Architecture to Support Strategy is a natural fit, that like many associations is not always correct. Part of the challenge is use of the term “strategy”. Often the term is implicitly associated with the organization’s strategy. Then without warning the same term is used for something far more specific, like the staff compensation strategy. At its most basic, a strategy is simply a “central integrated, externally-oriented concept of how to achieve the objectives”.[18]

Like “stakeholder”, a good definition encompasses a broad range of potential cases, without narrowing down to effective guidance. From an EA perspective, Practitioners are supporting strategy when exploring a longer-term target, and work will be used to identify a set of change initiatives. Guide the terms of reference for the initiatives so that the organization can direct and control execution through a portfolio of work. Typically, this type of work will align with budget planning, where the organization plans to spend on new initiatives or newly identified things. Table 1 identified that this work is typically only sufficiently detailed to provide guidance over a three to ten-year period and that the guidance will be valid for short periods of time. This is where organizations switch priority – the important element to recognize is the longer-term target is rarely shifting; what is shifting is where priority is placed.

Good Practitioners know they are supporting strategy when the priority pendulum slows; when the organization is able to balance between two or more competing impulses. Effective guidance helps the organization understand what is required for the complete set of its needs.

4.1.2 Budget Preparation and Architecture to Support Portfolio

The linkage between budget preparation and Architecture to Support Portfolio is one of the strongest linkages available. Given a set of change objectives, the organization is embarking on what is a good approach – what work must be funded, what work can be deferred, and what work should be deferred. Some of the most powerful guidance to effective change an EA team can provide is to support portfolio planning and investment decision.

Providing Architecture to Support Portfolio requires working outside the corporate planning and execution cycle. When everyone else is executing on this year’s budget, the EA team must be working on next year’s budget; they have to be ready with a roadmap at the start of the budget preparation process.

The key questions every portfolio and budgeting process struggles with is a priority. Most portfolio and budget cycles are swamped in noise and cheerleading. They desperately need to know what work, in what areas must go forward and why. What work can be safely deferred? What work must proceed as a package?

Some of the highest value work a Practitioner can provide is supporting portfolio and budget preparation.

However, it requires the roadmap to be available as the initial budget materials are being prepared, with an ongoing update from trade-off during the budget discussions. TOGAF Phase E and Phase F align directly to this use of Architecture to Support Portfolio. Phase E prepares the architecture roadmap for the budgeting process; work with all decision-makers in the budget preparation to finalize the Target Architecture, and the Implementation & Migration Plan.

A key use of the EA is to sustain a well-considered target. Budget and capacity to change determine what is planned for realization.

4.1.3 Budget Allocation and Architecture to Support Project

Architecture to Support Project is the first time you can see that work to effect change is about to be done. Before the release of funding to an Implementation Project, no change is going to happen. The classic alignment of this purpose in Phase F is the development of an Implementation Project business case or Implementation Project charter.

Architecture work facilitates the organization’s final decision-making about the use of funding and other scarce change resources. The tendency of implementation teams to focus exclusively on the creation of tactical business value needs to be balanced with the roadmap purpose and value against the target. It is common for implementation teams to sacrifice substantive organization value to provide what might be considered “decorative” features to the operational team the implementers work with.

Balancing the bottom-up change needs with broader initiative needs is an important role. Will the organization’s priorities and values be realized by a particular Implementation Project? If so, the organization’s budget allocation process should release the funds. If not, parochial departmental interests are capturing scarce organizational improvement resources. Ensuring delivery of value is one of the most important reasons to perform Architecture to Support Project. If bottom-up business case justification built end-to-end efficiency, agility, or eliminated the need for transformation projects, no one would need the profession of EA.

The other role is ensuring completeness. Far too many projects build metaphorical half bridges; building everything but the last piece to cross the obstacle. The justification is usually to “make progress”. Bluntly, an organization is not making progress when it embarks on a change it will not finish. The organization is simply wasting resources.

Figure 5: Half a Bridge

The TOGAF concept of the Architecture Contract provides the linkage between the value and the implementation through the target. The Architecture Contract provides traceability in terms of context, the complete work required, and conformance tests. Focusing attention on what will produce value and enabling architecture-supported governance is a chief outcome from Architecture to Support Project.

4.1.4 Budget Control and Architecture to Support Solution Delivery

Architecture to Support Solution Delivery is directly aligned with work to implement effective change.[19] In the business cycle, the budget control provides ongoing financial control and benefits realization. Architecture to Support Solution Delivery is directly aligned to the governance of the Implementation Project. Enabling direct association of spend with benefits realization is the contribution to the budget cycle.

Architecture to Support Solution Delivery is dependent on traceability through the EA Landscape. Definition of acceptable boundaries for design and implementation, as well as boundaries for design and delivery, facilitate procurement and third-party contracting.

Similar to Architecture to Support Project, Architecture to Support Solution Delivery will use the TOGAF concept of an Architecture Contract to constrain design and implementation choices tightly to value.

Most Architecture to Support Solution Delivery will be performed in the TOGAF ADM Phase G. The need to fully iterate the ADM makes little sense when there is a superior architecture that develops the outline of the target, the stakeholders, a roadmap, and an implementation plan. If you are not getting value, you are creating busy-work and self-confusion about the ADM.

4.2 Business Cycle Conclusion

The business cycle is one of the core business activities that an EA team must align to. It provides a common reference point that is central to how an organization plans, authorizes, and executes change. Performing process alignment and alignment to other Enterprise frameworks is one of the central activities of establishing an EA Capability. For a broader discussion of other alignments, see the TOGAF^® Leader’s Guide to Establishing and Evolving an EA Capability (see Referenced Documents). This Guide uses the business cycle as a simplification of the myriad of business activities that an EA team supports, to align with the practical work requirements of a Practitioner.

return to top of page

---

---