What is Architecture to support Portfolio?
What is Architecture to support Portfolio?
- Change Initiative Portfolio Architecture
- Digital Product Portfolio Architecture
- Portfolio Architecture Relationship to Strategy
- Portfolio Architecture Relationship to Solution Delivery
Knowledge Created in TOGAF ADM Phases
Developing the Portfolio Architecture Top-Down
Improving the Portfolio Architecture Working Bottom-up
What is Architecture to support Portfolio?
Enterprise Architecture for Portfolio is an enterprise architecture use case. It is built around a portfolio of projects and digital products. The purpose of the portfolio is to reach a specific outcome.
Portfolio architecture starts with the portfolio.
There should be a strategic architecture that identified the portfolio. The superior architecture will provide an outcome and governance directions. The portfolio will deliver an enterprise strategic goal, or departmental strategic goal.
The Governance directions will provide the sponsor with three things:
- Their performance expectation
- The constraints they must deliver within
- The portfolio's risk appetite
Portfolio architecture enables choice. Hard choices between architecture alternatives. Selecting the work that is the best path forward. Selecting reasonable work packages that you won't do.
Enterprise architects engaged in the use case of supporting portfolio focus on action. The central deliverable is a dynamic architecture roadmap. The roadmap is used to govern projects and products. Cascading directions.
Change Initiative Portfolio Architecture
Portfolio architecture will either be aligned to a change initiative or digital products.
A change initiative portfolio, is something like digital transformation, or integrating an acquisition. It is a body of projects that reach an expected outcome. Then the portfolio is wrapped up and the sponsor moves onto a new change initiative.
Change initiative portfolios typically look forward 3 to 5 years.
The case study in Enterprise Architecture with TOGAF and Navigate is based on a change initiative portfolio.
Portfolio owners aim for the sweet spot between top down and bottom-up planning. Top-down ensures performance expectations, constraints, and dependencies are covered. Bottom-up captures local knowledge and creativity.
Digital Product Portfolio Architecture
A digital product portfolio is longer-lived than a change initiative portfolio. The portfolio owner may have a planning horizon of 3 to 5 years. However, they are not expecting to complete the journey and wrap-up the portfolio.
Architecture to support a digital product portfolio is often aligned with re-factoring the product portfolio. The discipline of enterprise architecture is focused on change, if the product portfolio is not undergoing meaningful change there is no reason to assign your enterprise architects to this portfolio.
Portfolio Architecture Relationship to Strategy
The relationship of portfolio architecture to strategy is all about architecture governance.
There will be controls to ensure that the change initiative is following directions.
Most people focus attention on governing outcome. Constraints and risk appetite may be more important than outcome to the portfolio's value calculation.
Portfolio Architecture Relationship to Solution Delivery
The Portfolio's dynamic architecture roadmap is the key to the relationship between the portfolio and solution delivery. For chainge initiative portfolio's the architecture should be capability-based.
Implementing governance is the main focus of the relationship.
A dynamic roadmap will have clarity of:
- transition stages
- implementation strategies
- expected value stated in terms of benefit, work, and risk
The portfolio owner will be regularly assessing their portfolio roadmap looking to the opportunity to change direction and increase their value contribution.
The concept of an architecture contract supports the implementation governance relationship. In return for the portfolio owner's support, the implementation team agrees to deliver within their constraints and the risk appetite.
It is very common for a portfolio owner to use a project to deliver something that enables other aspects of the portfolio.
As a simple example, the digital product team might be focused on launching a digital product, while the portfolio owner is using them to improve the the capability of DevOps based digital product development. In these cases implementation governance is focused on the capability development, not the product. In this case the portfolio owner may be very comfortable with a product failure that improved maturity.
When the portfolio is aimed at organizational improvements architects should look closely at the Hambrick Strategy Map concepts of staging and vehicles. They also need strong controls - after all the product team will probably accept no useful capability development in return for a product launch.
Knowledge Created in TOGAF ADM Phases
Topic | Mapping to TOGAF ADM Phase |
Group Work Packages to Themes | Partial Strategic Level Phase H
Partial Strategic Level Phase A
Partial Strategic Level Phase G
|
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
Partial Capability Level Phase F
Partial Project Level Phase A
|
Run Up to Budget | Partial Capability Level Phase For each capability or project in the portfolio:
Partial Capability Level Phase F
Partial Capability Level Phase G
|
Drive Confidence of Delivery | Partial Enterprise Level Phase F
|
Table 6: ADM Phases and Architecture to Support Portfolio from Practitioner's Guide
Developing the Portfolio Architecture Top-Down
Top-down portfolio architecture is the standard approach. The portfolio owner has a mission. The portfolio architecture should look forward to the completion of the mission, which will be 3 to 5-years. In this period, the target architecture should be stable. The target will normally be updated in response to external events and the portfolio's over performing, or failed change activity.
The critical deliverable is a dynamic architecture roadmap. To be dynamic, the roadmap requires transition stages. At a transition stage, the portfolio owner selects the next stage on the journey. It is a point where the portfolio owner can increase their investment or prune the initiative. These transition stages enable enterprise agility. The portfolio owner uses a dynamic roadmap to react to success, failure, and any unexpected opportunities or threats.
The portfolio owners use the roadmap to direct improvement projects. They understand dependency and synergy. Most importantly, they understand the places they can stop, harvest value, and change direction.
Top-down Portfolio Owner Benefits
Architecture development is focused on the path to reach the target. The portfolio owner will be:
- Selecting projects that should be in their portfolio
- Prioritizing and sequence projects
- Aligning project execution approaches
- Finding synergy and dependency between projects in a portfolio
- Manage portfolio risk
Enterprise Architect supporting Top-Down Portfolio Needs
To deliver this the enterprise architect needs:
- An end-to-end architecture to provide context, guidance, and constraints to the portfolio
- One or more focused target architectures that are aligned with the portfolio’s outcome and main components
The architect needs to know:
- How the current enterprise fails to meet the performance expectations?
Understanding the deficiency includes understanding the stakeholder concerns, priorities and risk appetite. - What is the source of deficiency?
- What changes are required to address the deficiency?
These changes are Gaps between current and target state. - What constraints limit the selection of changes?
Constraints will come from superior architecture and emerge during architecture development. - What work is necessary to realize the changes?
A portfolio architecture is distinguished by its dynamism.
There are routinely multiple systems of interest. These systems will often have multiple candidate and transition states.
The portfolio architecture level of detail is driven by the divergent needs of understanding the source of the deficiency and the finding potential changes necessary to address the deficiency.
You will need more detailed architecture development focused on value delivery. Architecture specifications should enforce the expected value delivery.
In portfolio work, architecture specifications are focused on implementation governance - work packages and architecture principles and patterns.
Top-Down and Bottom Up Portfolio Architecture Key Consumers
Top Down | Bottom-up | Key Decisions | |
Stakeholder |
|
|
|
Portfolio Owner (Sponsor) |
|
|
|
Implementer |
|
|
|
Improving the Portfolio Architecture Working Bottom-up
Portfolio owners aim for the sweet spot between top down and bottom-up planning. Top-down ensures performance expectations, constraints, and dependencies are covered. Bottom-up captures local knowledge and creativity.
The critical deliverable is a solution architecture that links the bottom-up ideas to a portfolio gap. The portfolio architecture needs to include constraints and performance expectations so the solution can be assessed. This is critical when the roadmap includes an implementation strategy.
Bottom-up Portfolio Owner Benefits
Architecture to support Portfolio in a bottom-up approach should help portfolio owners:
- Select bottom-up projects ideas that should be in their portfolio
- Prioritize and sequence selected bottom-up projects in their portfolio roadmap
- Find synergy and dependency between bottom-up project ideas and the portfolio roadmap
- Direct and control project execution to reach transition states
- Manage portfolio risk
The target architecture will be relatively stable. Bottom-up ideas will fill gaps within the portfolio target.
Enterprise Architect supporting Bottom-up Portfolio Needs
Bottom-up captures local knowledge and creativity. To deliver this, the practitioner needs:
- An end-to-end architecture to provide gaps and architecture specifications
- An architecture roadmap to provide transition points and work packages, and the expected approach
- One or more detailed architecture descriptions that are aligned with the gaps being filled by the solution and surrounding architecture decisions and specifications
The architect needs to know:
- The local and portfolio value of the bottom-up solution
- How well the solution fits into the portfolio
- Compliance with constraints limit the implementation of the solution
What You Want in an Architecture Roadmap for Portfolio
A portfolio owner needs a dynamic roadmap. To create enterprise agility they need to be able to react and deliver value.
It is easy to react and sacrifice value. Simply react. Change priorities, cancel or start change initiatives without any regard for the work required to deliver value.
It is hard to react and sustain value.
Portfolio Owner's perfect roadmap
… includes options and value statements associated with each work package. Value stated in terms of business capability, market reach and limitations …
… and provided awareness of existing roadblocks. Including why they are roadblocks and implications of addressing them head on or continuing to detour…
Portfolio owners need to react to expected and unexpected events. Projects in their portfolio will succeed or fail. Other projects will succeed or fail. Business partner initiatives will succeed or fail. Then there are the unexpected threats and opportunities.
A dynamic portfolio has the information for the stakeholder to react and sustain value. Transition stages are 'value resting points.' Points where the stakeholder can stop all work, abandon future work and still gain expected value.
Portfolio Owners Want Joint Roadmap Development
In order to have an understanding of potential value roadmap development must be done with the portfolio owner. A high portion of the raodmap's value comes from portfolio owners assessing trade-offs and making architecture decisions. They develop the perfect roadmap.
When expected and unexpected events happen the stakeholder can make the best decision.
Portfolio Owners Need Project Governance
To drive value portfolio owners need the ability to govern projects. This implementation governance is focused on the project and any solution implementation.
To govern a project the portfolio owner needs:
- transition stages
to ensure the project is not working past the transition - work package implementation strategy
to ensure the project is following the preferred approach to change - gaps & work packages
to ensure the project is delivering the needed scope, and avoiding unneeded scope - value measures
to ensure the project managers understands the definition of success and is aligned with the architecture decisions
To govern a solution the portfolio owner needs
- architecture specifications
architecture principles, patterns, standards and controls to ensure the solution is compliant - implementation strategy
to ensure the solution is evolving or replacing the current state - value measures
to ensure the solution is delivering success and is aligned with the architecture decisions
Conclusion
Enterprise Architecture for Portfolio is the best aligned use case for enterprise architecture. Portfolio architecture enables choice. Hard choices between architecture alternatives. Selecting the work that is the best path forward. Selecting reasonable work packages that you won't do.
With portfolio architecture the portfolio owner can plot a top-down implementation plan aligned to value-capturing off-ramps. They can assess bottom-up ideas for their fit with the portfolio.
The key deliverable is a dynamic architecture roadmap. Work packages and transition stages aligned to value delivery and existing roadblocks. This way the portfolio owner can choose to remove the roadblock or continue to detour.
Your next steps developing portfolio architecture are reading about developing architecture roadmaps or getting some help.