Develop Architecture Views
Article at a glance
What is an Architecture View?
An architecture view explains the architecture in terms of a stakeholder’s concern. A view helps a stakeholder evaluate an architecture alternative, and the entire architecture.
Architecture View is not a simplified architecture model
Architecture View explains the architecture
Architecture View explains the architecture in terms of a concern
Architecture views revolve around concerns. Something like agility. Or feasibility. Or efficiency. Or change impact. Or all four.
The view will explain the architecture in terms of agility, or feasibility, or efficiency, or change impact.
What does an Architecture View look like?
Views represent an analysis of the architecture! They are usually delivered through tables or diagrams. It depends on the information that needs to be provided.
Do not just draw a diagram and hope the audience will infer the information they need. Instead, start with the stakeholder and the concern.
Then identify what you need to know to explain the architecture in terms of the concern.
Last, select an approach to explaining.
As an example, Senior Leader and Strategic Alignment. You need to know how the architecture delivers against the enterprise’s strategy and top-level goals.
You need to know:
- Enterprise Strategy (outcome/objective/goal)
- The incremental contribution of the architecture’s change to the priority (outcome/objective/ goal)
- Inflight initiatives expected to support the enterprise priority (outcome/objective/ goal)
- The effort to deliver the contribution
They will use this to determine of the potential target is meaningful help to the strategy.
In this example we'd start with radar plot, bubble chart or a table.
- Radar plot would let us show contribution to different priorities
- Bubble chart could show contribution, effort, and time against a single priority or some form of blended contribution.
- Table would be the data underpinning the Radar plat or Bubble chart.
Architecture View is not a simplified architecture model
Most modelling tools and discussions confuse architecture views and models.
Remember, a view explains the architecture in terms of a stakeholder’s concern. Architecture Models are simplifications of the real world. Models help us understand how the real-world works. Models are critical providing you the knowledge to for a view.
It is possible that a single model will provide enough information to answer a concern. Not likely, but possible.
Go Further with Best Practice Enterprise Architecture Process and Method
Best practice enterprise architecture from Conexiam Navigate
Best Practices to Implement Enterprise Architecture Management Tools
Best Practices to Implement Enterprise Architecture Management Tools Enterprise Architecture Management Tools are designed to support the planning, design, analysis, and execution of enterprise architecture. They enable enterprise architects to examine the need for change […]
Making Smarter Choices: Why Your Business Needs Architectural Decisions
Making Smarter Choices: Why Your Business Needs Architectural Decisions Enterprises are constantly confronted with the challenge of making crucial decisions. Every day, decisions, including operational practices and technology selections, have a significant impact on a […]
Ensuring Alignment and Accountability: The Crucial Role of Enterprise Architecture Governance Checklists
Ensuring Alignment and Accountability: The Crucial Role of Enterprise Architecture Governance Checklists Enterprise Architecture Governance Checklists simplify enterprise architecture governance processes. The governance process needs to approve target architecture and provide implementation governance. A robust enterprise […]
Developing Enterprise Architecture Strategy
Developing Enterprise Architecture Strategy: Strategic Plan for Change Enterprise Architecture Strategy is action. Action your organization will take and the changes you will make to reach your strategic goals. Strategy development is all about choice. […]
Unlocking the Power of Capability-Based Planning: A Quick Guide
Unlocking the Power of Capability-Based Planning: A Quick Guide Are you looking for a more effective way to plan and execute your business strategy? Look no further than capability-based planning. Identifying and using your organization’s […]
Unlocking Your Business Potential: How to Create an Effective Capability Map
Unlocking Your Business Potential: How to Create an Effective Capability Map Are you struggling to identify the capabilities needed to take your business to the next level? Do you find it challenging to align resources […]
Using Scenario Analysis for Enterprise Architecture
Using Scenario Analysis for Enterprise Architecture A scenario is simply a plausible future. Scenario analysis looks at how we get to a plausible future and how different scenarios impact our current choices. Scenarios help leaders […]
Enterprise Architecture Roadmap as Design
Enterprise Architecture Roadmap as Design An Architecture Roadmap is a planning tool that helps an organization’s decision-makers. A dynamic Architecture Roadmap is designed to help them develop and travel the best path forward. It also […]
Understanding Enterprise Architecture and Agile
Understanding Enterprise Architecture and Agile Both agile and enterprise architecture are designed to reduce risk. Agile software development excels at building something that we have never had before and do not know how to build. […]
How to Define Enterprise Architecture Principles
How to Define Enterprise Architecture Principles To Define Enterprise Architecture Principles start with understanding what a principle is and how to apply them. Then we can develop strong architecture principles that help improve our organization. […]
How Many Architecture Views do you Need?
There is no apparent limit to the number of views that could be produced. The number of stakeholders, the number of concerns and the number of architecture alternatives, the more views.
Use a Value Hurdle
To manage the decision cycle, we are always looking for reasons to eliminate an architecture alternative. Stopping analysis of weak ideas free capacity for strong alternatives.
We are not afraid to eliminate alternatives. In Portfolio work, a very high fraction of potential changes cannot meet minimum value hurdles. From a productivity perspective, all work to continue analysis of changes that will never be funded is waste.
Value is a simple ratio of benefit divided by effort adjusted for risk. Risk architecture, helps us explore benefit adjusted by the uncertainty of harvesting it. And work adjusted by the uncertainty it is completely scoped and well estimated.
Benefit is not always financial. You will find benefit in many standard concerns – agility, efficiency, improved value proposition, and even less uncertainty.
You are right at the root of enterprise architecture governance. You are specifically working to stakeholder direction (performance expectations and constrains). The analysis and architecture trade-off are leading to the selection of the best available changes.
Design your Enterprise Architecture Framework for Architecture Views
Your enterprise architecture framework should be optimized for your enterprise architect use case. It should specify the mandatory models and views. Models create the knowledge necessary for the views you must construct.
A very common Portfolio use case is the IT Modernization Use Case. The outcome is a modernized IT Application and Infrastructure Portfolio. IT Modernization usually becomes a priority because of technical debt or acquisitions. IT Modernization faces continuous value delivery hurdles tied to Change Impact, Feasibility, Efficiency, and Agility.
Build a viewpoint library lining-up the normal stakeholder classes and concerns for an enterprise architecture use case. Then ruthlessly minimize the information demands for the required enterprise architecture models.
Drive minimizing information and analysis. We focus the EA Team development on the questions they need to answer for their use case’s stakeholder. We ensure the models and support for developing architecture views surrounds the EA Team.
Embed Views in Architecture Governance
The target architecture governance checklist checks for stakeholders understanding value, effort and uncertainty. Views that address standard concerns like Change Impact, Change Cost, or Feasibility should be embedded in your architecture review board process.
You ensure that the right analysis is done on candidate architectures to ensure stakeholders understand the value, effort and uncertainty of an architecture alternative. This leads to stronger architecture decisions.
Speed Development with Viewpoint Library
Without a viewpoint library we trap the enterprise architect without a stopping point. Without focusing on the primary stakeholders’ concerns and the associated trade-off decisions, they work on random issues.
The best enterprise architects are 50-100 times more productive. They generate this productivity with radically lower information demands. They seek less information and analyze less. They focus time and energy on stakeholder’s value hurdles.
At every stage they ask what information is needed to address the mandatory concerns. In short, they ask what architecture view will help the stakeholder make a choice.
We recommend that you challenge everything. Ruthlessly minimize the analytic load.
Pay attention to the implicit direction stakeholders provide. For example, if every trade-off decision has picked time-to-market over sustainability, there is only one thing to do. Listen to the stakeholders’ direction and develop a target that enables time-to-market. The start of enterprise architecture governance is listening to directions when developing the target.
We cannot stress enough the iterative nature of this stage. Far too many teams submerge themselves in minutia. Fun facts and minutia are distractions from the end-goal of supporting effective change. They also hinder facilitating stakeholders’ direction and control of implementation.
Navigate Viewpoint Template
When preparing a Viewpoint, we need to know:
- Stakeholder
- Concern
- Knowledge the Architect must have
- How to construct a view
The required information to form a view guides the development of a custom enterprise architecture framework. It identifies the required architecture models.
Develop your Viewpoint Library. Examine consistent significant stakeholders and their concerns. This focuses your work on value.
You will align your architecture to your organizations’ preferences and priorities.
| Concern | Stakeholder | Information Required | View Construction |
| What is the Concern? What is one criteria the stakeholder will use to assess the target architecture? |
Who is the Stakeholder? | What does the enterprise architect need to know to explain the target architecture in terms of the concern? | How will the View be constructed? |
| Example | |||
| Change Impact
What is the impact, or scope, of a change? |
Senior Leader |
|
Table, Radar Plot, Bubble Chart
You will never be able to identify Change Impact without a Gap. |
Navigate Portfolio Atlas Viewpoint Library
Navigate Atlas to support Portfolio Stakeholder classes, Concerns, and Stakeholder/Concern Matrix.
Navigate Portfolio Stakeholder Classes
- Senior Leaders have responsibility for management and oversight.
This responsibility includes approving and realigning strategic initiatives, tracking a portfolio of projects, ensuring transformative benefits are realized, and meeting operational business goals. - Portfolio Owners have responsibility for the management and oversight of strategic initiatives.
This responsibility includes approving and realigning projects, tracking project progress, and ensuring project benefits are realized. - Business Requirements Owners have responsibility for identifying and expressing business requirements.
Typically, these Stakeholders are responsible for some aspects of business operation. - Implementers are responsible for developing, integrating, and deploying the solution.
- Risk Owners are those responsible for specific risks or portfolio of risks
- Business Partners are engaged to provide services sustaining a customer value proposition.
Note: The architecture may not be provided to business partners but must be evaluated from their perspective. - Customers are the targeted consumers of products and services.
Note: The architecture may not be provided to members but must be evaluated from their perspective.
Navigate Portfolio Concerns
- Agility: What is the ability of the architecture to adapt to future unanticipated change?
- Efficiency: How does the architecture contribute to the efficiency of operations?
- Change Impact: What is the change impact of the architecture?
- Change Cost: What is the total cost of change to implement and sustain the architecture?
- Value
- Alignment: Where does the architecture contribute to strategic priorities? What is the contribution?
- Value Proposition: How does the architecture address a value proposition? Does the architecture create new value propositions? Does the architecture depend on a value proposition?
- Differentiation: How does the architecture address enable differentiation?
- Customer Intimacy: Does the architecture enable delivering products and services the customers want? What is the confidence that the new product or service will be liked by them?
- ROI: What is the financial Return on Investment of the target architecture.
- Risk (Uncertainty)
- Risk to Asset: What risks to existing assets does the architecture create? What existing risks to assets are addressed?
- Risk to Benefit: What is the uncertainty of delivering or harvesting the expected benefits?
- Confidence: What provides confidence in the benefit, change costs, and uncertainty of the architecture?
- Feasibility: What is the probability the architecture will be realized and sustained?
- Security: Will the architecture consistently address the risks and opportunities embedded in operations?
- Specification: What needs to be built to realize the architecture?
- Continuous Operations
- Dependability: How will the architecture consistently deliver value and operate safely?
- Resilience: What is the architecture's capacity to withstand or recover quickly from difficulties? Where does the architecture have lower resilience?
- Business Continuity: Does the architecture provide the appropriate level of continuity? Where are there limits in business continuity?
- Scalability: Can the architecture handle the range of demands? What are the architecture's growth or expansion restrictions?
- Self-Healing: What is the capacity of the architecture to return to full operation after an incident without external intervention?
- Ecosystem
- Compliance (Regulatory / Contract): How does the architecture address compliance. Does the architecture simplify compliance management? Where does the architecture enforce compliance?
- Competitive Landscape: How does the architecture address threats and opportunities in the competitive landscape? How does the architecture create new opportunities in the competitive landscape?
- Sustainability
- Social Responsibility: How does the architecture address social responsibility goals & requirements?
- Environment: How does the architecture address environmental goals & requirements?
Navigate Portfolio Stakeholder/Concern Matrix
| Agility | Efficiency | Value Proposition | Change Cost | Change Impact | Strategic Alignment | Feasibility | Dependability | Control (Security) | Specification | Risk (Uncertainty) | Confidence | Customer Intimacy | Scalability | Business Continuity | |
| Senior Leader | X | X | X | X | X | X | X | X | |||||||
| Portfolio Manager | X | X | X | X | X | X | X | X | X | X | |||||
| Business Requirement Owner | X | X | X | X | X | X | X | X | |||||||
| Implementor | X | X | X | X | X | X | |||||||||
| Risk Owner | X | X | X | X | X | X | X | ||||||||
| Business Partner | X | X | X | X | X | X | X | ||||||||
| Customer | X | X | X | X | X | X |
Navigate Innovation Atlas Viewpoint Library
Navigate Innovation Atlas uses the same Stakeholders and Concerns as the Navigate Atlas to support Portfolio.
Navigate Innovation Atlas Stakeholder/Concern Matrix
| Value | Risk (Uncertainty) | Continuous Operations | Ecosystem | Sustainability | ||||||||||||||||||||
| Agility | Efficiency | Change Impact | Change Cost | Alignment | Value Proposition | Differentiation | Customer Intimacy | ROI | Risk to Asset | Risk to Benefit | Confidence | Feasibility | Security | Specification | Dependability | Resilience | Business Continuity | Scalability | Self-Healing | Compliance | Competitive Landscape | Social Responsibility | Environment | |
| Senior Leader | C | X | C | C | X | X | X | X | C | C | X | C | C | X | X | |||||||||
| Portfolio Owner | X | X | C | X | X | C | X | C | X | X | X | C | X | X | ||||||||||
| Requirements Owner | X | X | C | C | X | X | X | X | C | C | C | C | ||||||||||||
| Implementer | X | C | C | |||||||||||||||||||||
| Risk Owner | X | C | X | C | C | X | X | X | X | X | X | X | C | |||||||||||
| Business Partner | X | C | X | X | X | X | X | X | X | C | X | X | ||||||||||||
| Customer | X | X | C | C | X | X | C | C | C | C | C | |||||||||||||
Navigate Innovation Atlas Viewpoint Sample
| Concern | Stakeholder | Information Required | View Construction |
| Agility what is the ability of the architecture to adapt to future unanticipated change? |
Business Partner |
|
Dependency Diagram works well to identify where agility (or inflexibility) is provided in the architecture |
| Agility
what is the ability of the architecture to adapt to future unanticipated change? |
Senior Leader |
|
Heatmap works well to identify where there is change pressure and difficulty of performing change
Dependency Diagram works well to identify where agility (or inflexibility) is provided in the architecture |
| Change Impact What is the impact, or scope, of a change to the architecture? |
Senior Leader |
|
Tables work well |
Conclusion of Developing Architecture Views
The best EA teams are predictable. They know the key questions that need answering, the information required, and they re-use previous analysis and decision. They deliver architecture views. They help their stakeholders’ select changes.
The best EA teams know their mandatory stakeholders and concerns. They work to architecture trade-offs. They drive to a decision.
Stakeholders need enterprise architecture views to evaluate architecture options according to their criteria. They will always have competing goals and objectives. Which architecture alternative is cheaper? Or more agile? Or best for value proposition? Stated as concerns, they need the architecture explained in terms of Change Impact, Feasibility, Efficiency, and Agility.
Remember, architecture develops requirements. Requirements imposed on implementers. Requirements that will be a mixture of performance expectations and constraints.
A target architect is expected to deliver value – to deliver specific benefits for approved work. Architecture views help stakeholders understand the direct impact of their choices. They provide the means for a stakeholder to confidently approve the architecture roadmap, the implementation plan, and the project charter.
All of this comes from creating architecture views. Views that describe the architecture in terms of a concern. Views that enable a stakeholder to make the best choice that best meets competing goals and objectives.
Architecture views are central to guiding effective change.
