8 Walk Through Architecture to Support Portfolio
8.1 Introduction
Almost all EA engagements, external or with an in-house EA team, are initiated for an Enterprise that has been in existence for a while. Whether explicitly initiated or acknowledged, an architecture is in place and solutions are being delivered against that architecture. Even when the Architecture to Support Strategy has been created for the first time, there are ongoing efforts and their impact that will have to be accounted for.
The primary objective of Architecture to Support Portfolio is to identify projects, identify dependencies and synergies, and prioritize and initiate the projects. From that perspective, it would appear that all of the work is confined to Phase F to complete the architecture work and transition to solution delivery work.
The Enterprise’s solutions are delivered on a continuum. This continuum is split into four phases, all focused on achieving the objective to meet stated goals. These phases are:
- Stay on par with other players in the market for a given capability
- Maintain the edge a capability has over other players
- Create new differentiations in capabilities
- Create new markets and revenue streams
Once a new capability or a differentiation in a capability is achieved, the incremental advantage will have to be maintained.
Figure 16: Capability and Project Continuum
It is imperative that Architecture to Support Portfolio takes into account an existing implicit or explicit Target Architecture and the impact driven by in-flight projects. Hence, in true sense, this work starts in Phase H of the ADM. The work is considered complete when all the specifications that constrain the Architecture to Support Project are defined, understood, and signed off. In other words, the need to perform Phase A for the solution delivery projects that are triggered by the portfolio is complete.
In doing to so, the architecture provides a data-driven approach to reduce the possibility of one set of decision-makers netting the majority of the available budget because of the way it has been in the past. This is achieved by developing appropriate models, like-to-like comparison, and incremental exploration of the EA Landscape to assess impacts and dependencies.
It is imperative that the Architecture to Support Portfolio concludes at least 30 days before the budget preparation. A best practice is to is offset this work by at least a quarter (three months) from the business cycle of the Enterprise.
Questions answered by this effort are:
- Is the architecture recent and current enough to guide decisions?
- What is the confidence that the allocated budget drives the Enterprise closer to target state?
- Are the controls on risks sufficient enough to trigger and guide viable alternate actions?
- How often is the solution delivered to be inspected to assure general correctness of direction?
- How to identify and initiate changes when any of the trade-off criteria are impacted?
When pivoting on program and project management concepts, a portfolio can include operational improvement efforts; not a clearly defined end-date for closure. The intrinsic value of the Enterprise is elevated when related and cohesive parts of the EA Landscape are improved. From an EA point of view, a portfolio addresses improvement of the intrinsic value and reduction of risk factors.
Table 6 summarizes the activities and use of appropriate steps from the ADM phases. The content of the table is discussed in detail in the rest of this chapter.
Table 6: Summary Table: ADM Phases and Architecture to Support Portfolio
|
Topic |
Mapping to TOGAF ADM Phase |
|
Group Work Packages to Themes |
Partial Strategic Level Phase H
Context specific for the EA Capability:
Partial Strategic Level Phase A Enterprise context:
Context specific for the EA Capability:
Partial Strategic Level Phase G Enterprise context:
|
|
Balance Opportunity and Viability |
Partial Capability Level Phases B, C, and D For each capability or project in the portfolio:
Partial Capability Level Phase E For each project in the portfolio:
Partial Capability Level Phase F For each capability in the portfolio:
Partial Project Level Phase A For each project in the portfolio:
|
|
Run Up to Budget |
Partial Capability Level Phase A For each capability or project in the portfolio:
Partial Capability Level Phase F For each project in the portfolio:
Partial Capability Level Phase G For each project in the portfolio:
|
|
Drive Confidence of Delivery |
Partial Enterprise Level Phase F Enterprise context:
Context specific for the EA Capability:
|
8.2 Group Work Packages to Themes[30]
The minimum dataset required to initiate this effort is:
- Current fiscal year’s roadmap (to the extent available)
- List of in-flight projects and relationship to objectives
- Strategic architecture (gaps, work package, and candidate roadmap) for the next fiscal year, from Architecture to Support Strategy
- Catalog of stakeholders, decision-makers, and implementers
- Risk catalog
Note: The backlog from the current fiscal year is not of concern, as the Architecture to Support Strategy has accounted for them.
Given the context surrounding the Enterprise and the EA project, develop a Baseline Architecture from the current state architecture created by the superior architecture (Architecture to Support Strategy). The Baseline Architecture is not a physical thing. It is a point of reference in time, defining a metric and a measure to enable value reporting. The baseline is a collective view that provides credit for value added by in-flight projects. All value assessment and trade-off shall be performed against the baseline.
The Baseline Architecture groups the in-flight projects against the new objectives defined in the Target Architecture. It is possible that in-flight projects may not align cleanly with the Target Architecture. When a project aligns to more than one objective, assigning credit from such an effort to all objectives to create the baseline will not impact the value reporting. The impact of gaps between current state and Target Architecture will invariably outweigh.
Using the Architecture Vision as reference and the list of work packages, develop a set of themes, if not previously defined by Architecture to Support Strategy (prior architecture work). It may be necessary to create multiple baselines, one for each theme. Themes are defined by factoring the current and target organizational structure, productivity, differentiation, and scaling objectives. The organization structure articulates stakeholders, decision-makers, and implementers, their interests and concerns. As the work packages are moved across themes, perform an assessment of impact to stakeholders, decision-makers, and implementers. The resulting grouping of the work packages can be suboptimal due to dependency on pending organizational change.
When performing EA activity for the first time in the Enterprise it is safe to assume that there were no target transition architectures that were used to create projects in the current year. The Target Architecture and gaps were inferred by whoever drove the budget preparation and budget allocation. Many of the in-flight projects could have a target completion date that extends beyond the next couple of business cycles. Altering the course of these initiatives takes time and, hence, suboptimal architectures in the first go around of the architecture effort. Revisit the gaps list created by the Architecture Project and work packages, and make appropriate adjustment due to in-flight projects and any inferred roadmap for the current fiscal year. Prioritizing, estimating, and sequencing of this list is the scope of work for the Architecture to Support Portfolio.
To identify the prioritization of the effort, build Table 7. Populating the table forms the basis for performing further elaboration of the EA Landscape. Any cell in this table without data conveys that the architecture is not complete.
Table 7: Work Package Grouping
|
Portfolio Theme |
Work Package Name |
Work Package Required |
Importance |
Impact Realization Timeline |
Effort Required |
Magnitude of Investment |
The importance of a work package is carried over from the strategic architecture. The last three columns will be populated as the architecture is developed further. As noted earlier, the work package to “theme” association is made using the lens of improving intrinsic value of the Enterprise, populating cohesive parts of the EA Landscape.
Analysis of the mapping between portfolio themes and stakeholder concerns identifies the subset of stakeholders to engage for each portfolio. For each portfolio, reaffirm that there are no changes in the internal and external forces that created the work package. Identify resources required and track the resources that cross organizational boundaries. It is typical for most organizations to require an elaborate process to move resources. Identification of such a need changes the dependencies and priorities of the work packages.
Using the stakeholder concerns from prior architecture work and the new grouping of the work packages, perform a trade-off analysis to quantify the changes to gaps and cascading impact on time to achieve the target state. Identify any new risks and develop appropriate controls. Using Table 7 and the mapping of work package to objectives via gaps, reaffirm that the value proposition delivered by the portfolio is aligned to the objectives.
The work packages carry an attribute to identify whether they are new or a carry-over from the current fiscal year’s effort. From now on, the merits of the work package in shortening the path to target state drives decisions to invest. Continuation of the current efforts may be factored in, but they are not a determining factor. Now, a reasonable candidate Architecture Vision for each theme, and hence, a portfolio is created.
8.3 Balance Opportunity and Viability
The analysis and architecture development so far has been heavily focused on an inside-out approach. It is time to seek help outside the Enterprise. For the kind of changes being driven, potentially accelerating solutions might be available in the market – within the same industry vertical or otherwise. Technological developments and environmental changes might present new options to meet the needs of the work packages. Considering business cycles of suppliers, partners, and the Enterprise, it may be prudent to initiate identification of implementers now. These implementers are not decisions-makers or stakeholders. It is not good practice to include them in the stakeholder matrix.
Develop the Business, Information Systems, and Technology Architecture specifications to the extent needed to scout the market for options. The focus is more on identifying the motivations behind the solutions than identifying a solution. If the purpose is to transmit information digitally, identify whether imaging is not an acceptable option. This still leaves the option to innovate, if needed, the right fit at the solution delivery stage. A related question would be: is the transmission of data for record-keeping purposes or transaction management purposes? Such a motivation identifies attributes of the building blocks and potential reuse of solutions already employed in the Enterprise. Assess the solution options more from an exclusion point of view, rather than narrowing down to “the solution”.
In elaborating the architecture, new risks and dependencies will arise, and so should appropriate controls. Develop a matrix of options, risks, and controls to enable viability analysis and trade-off with stakeholders. Keep populating the requirements management function with data from such elaborations. Identify the list of standards and reference architecture that can be leveraged or imposed as limiting conditions on the solution. Identification of such standards and architectures amplifies and drives specificity of the (constraints) architecture specification from the superior architecture. It may also provide an accelerated path to solution. Capture all possible attributes to inform trade-off analysis.
It is time to reach into the EA Repository for viewpoints, views, appropriate building blocks, and reference architectures to develop an approach to address the gaps. The viewpoints should provide a point of reference to the EA Landscape that is relevant for the stakeholder and decision-maker. Continuously validate that specifications for all work packages in the theme are elaborated equally, to the extent possible and necessary to decide the priority and resource needs.
Identify pockets where a solution may have to be invented. In such a case, create new work packages to perform proof-of-concept validations before scaling out. Understand that proof-of-concept work is actually implementation, not architecture. Architecture work is identifying the placeholder required to allocate appropriate funds and mitigate unknowns. The main focus of the Architecture to Support Portfolio is to maximize the mileage gained with available resources. The second objective is to identify conditions under with projected mileage gain is achievable. The third is to identify barriers to achieve the goal and build efforts to diminish the impact of such barriers. The final objective is to provide assurance of investment to reward ratio being unaltered. Populate the list of projects required to meet these four objectives.
Gather effort and resource estimates for all work packages. Revisit the dependencies across work packages. Identify the importance and impact of the work packages. The ability to authenticate the identity of the person carrying a ticket will vary with context. An Enterprise may have the same need for more than one scenario or portfolio. Or, in the case of boarding an aircraft, multiple agencies may have to be involved. Such work packages have high importance and impact, requiring early investments in the overall improvement cycle.
Perform an opportunity analysis factoring viable options to approach the solution. Remember, the focus is driving a baseline estimate and assurance of achievability of the target. The validation of the portfolio and the trade-off is focused on grouping by theme, related impact, and importance assessment. The decisions driven here impact the distribution of limited resources across the investment continuum.
8.4 Run Up to Budget
8.4.1 Internal Engagement
Other than line of business leaders, personnel from the office of the financial controller and Project Management Office (PMO) are key to driving the budget. The objectives of these two teams are fundamentally different, but converge once a year – the time of budget preparation. The convergence is around the trend on variance to budget. Enterprises develop guidance on year-on-year funding and budget trend based on statistical data, without any qualification for the value delivered. It is normal for the delivery or execution teams to ask for more than is needed or to keep the same level of ask, without sufficient demand, for fear of losing funding.
Another factor that could arise is the conflict due to gaps in the agility expectation of the service consumer (say sales team) and that of the service provider (say licensing and pricing team). Such a conflict creates duplication of capabilities and service in the guise of a different objective or effort name. Preparing for the budget, the EA team works to eliminate variations from such “opinions” or “duplications” of the past using gaps and work packages.
It is highly likely for the superior architecture to recommend organizational changes as well. In this case, the Human Resource (HR) team is going to play a more critical role in budget preparation than ever before. It is not the responsibility or the function of the EA team to drive decisions. EA has to frame the conversation and the directions to identify the right resources to lead and drive change. It is imperative that the engagement of all concerned internal teams – mainly HR, PMO, and finance – is key to the success of delivering the Architecture to Support Portfolio.
8.4.2 Has the Target been Reached?
Having driven confidence in reducing sources of artificial variance to budget, next to tackle is accuracy of the estimates. When the changes require a reasonable number of proof-of-concept efforts to be done or require employment of specialized services, veracity of the estimates would be questioned. In order to drive the level of confidence, it would appear that more time, more analysis, or more iterations are needed. Other than time, here is a short checklist that will indicate that it is time to stop iterating:
- For each “theme”, have the work packages been classified into a capability continuum (a work package cannot address both Sustain and Improve)?
- Are the dependencies and cascading impact of work packages acknowledged by decision-makers and implementers?
- Is there a contiguous elaboration and exploration of EA Landscape?
- Have the mitigations and controls for risks (unknown events) been added to the portfolio?
- Is there a blend of operational excellence and fitness for purpose within each theme?
- Are there any recency concerns?
- Is a raw estimate and contingency factor available (% buffer to account for market and external trends)?
- Is the ratio of growth in breadth of coverage architecture specification to depth of coverage diminishing between iterations?
- Is the variation in estimates between current and previous iteration less than the contingency factor?
- How many of the efforts are one-time executions to support transformations?
The point of diminishing returns is met when positive responses are given to either (8) or (9) above. Mostly during the first two to three years after initiating an architecture-driven planning cycle, the EA team will run out of time before (8) or (9) could be met. Plan for recommending a discretionary spending bucket.
To complete the architecture work, update the architecture roadmap, risk matrix, architecture definitions, and specifications to the extent needed and necessary. As needed, consult and conduct reviews with SMEs and stakeholders to validate the direction. For each theme, define the governance plan and model that is acceptable to stakeholders and decision-makers.
8.5 Drive Confidence of Delivery
Useful architecture drives change and simplifies decision-making. The objective of budget preparation is to drive confidence of estimates, confidence of delivery against the roadmap, and garner the resources required to drive change. The set of prioritized work packages grouped by themes that traces to objectives drives confidence in responses to the “why” and “what” questions. The set of estimates that is backed by variance control drives confidence to the “how” and “how much” questions. Creating a set of project governance that reduces the chances of execution decisions delaying the time to target state serves the final objective of this architecture – balancing innovation and considered controls.
Develop just enough views, models, and specifications to support the budget request. These documents are supported by a matrix of accountable parties for delivery and accountable parties for acceptance, usage, and sign-off. Success measures are articulated in value terms – controls in cost measures, and risks and outcome in value measures.
Initiate activities to complete the architecture work. This involves populating the appropriate project vision documents, project architecture definitions, project stakeholder list, communication plan, and conditions that govern trade-off. Populate the data required by monitoring the system for each project, should the project be approved for execution. Populate the dependency matrix in accordance with the boundaries set for each project and the “theme”. The Architecture Project cannot be completed until the Architecture to Support Project is delivered. Initiating the effort at this stage communicates the decisions at the strategy level that can be revisited in the future. The last validation is to define that the operating model (recovery-driven or engagement and continuity-driven) is aligned to the business model.
8.6 Request for Architecture Work Originating from a Random Idea from the Wild
In a well-run, creative organization many good ideas are not derived from gaps identified in the architecture. In these organizations, a Request for Architecture Work comes from someone with a good idea for improving the organization.
With a request from the wild, the Practitioner will typically engage with a strong champion and identify holes in the EA Landscape. There is little need to worry about bumping shoulders with other identified gaps and work packages. However, the champion often will have a limited, or myopic, view of the stakeholder’s preferences and concerns.
The Practitioner must take care to stay within the context of the wild architecture development relying on the mission, vision, and strategy of the Enterprise. Requests from the wild should be expected to challenge the status quo. The inherent creativity is welcomed by good Practitioners. Without much guidance from the strategy or portfolio to constrain the architecture development, Practitioners must ensure that identification of the correct stakeholders is completed and that the concerns reflect the stakeholder’s preferences and priorities – see Phase A: The Starting Point. Not all champions are stakeholders, and all Architecture Projects are subject to superior architecture.
There is a need for critical thinking around the preparation required to insert the architecture developed in response to a receipt of a Request for Architecture Work from the wild at the optimal point in the sequence of work within the Enterprise’s roadmap, or implementation plan. Well executed, the organization is able to balance creativity and innovation with the benefit derived from clear understanding of dependency to value realization.
While most Requests for Architecture work from the wild are for Architecture to Support Project and Architecture to Support Solution Delivery, strong champions will drive a portfolio initiative.
8.7 Conclusion
Conduct periodic value assessment and reporting to communicate lessons learned and whether the portfolio created is delivering organic change, radical innovation, or maintains the status quo. Implementation Projects deliver value a few quarters after the project is closed. It is the responsibility of those managing the portfolio to track and report value. Add to the portfolio an explicit backlog item to monitor and report value realized.
In the event this architecture is supporting a merger, acquisition, or divestiture activity, include explicit recommendations to tackle the impact of technology in easing the business operations, asset, and risk accounting.
Success is measured by alignment by the decision-makers on a number of concurrent streams, total resources required over the planning horizon period, and trade-off criteria.
return to top of pageTOGAF® is a registered trademark of The Open Group