I have a few foundational beliefs
First, our organizations are not broken, yet they are not happy
Second, every change proposal must earn permission to interfere with current operation
Third, enterprise architecture exists because it the right way to guide effective change.
I know it sounds simple. We work in architecture projects. Each addressing a specific deficiency in your organization. We always work in the context of superior architecture. Our method nets down to two things. First, carrying constraints from prior architecture decisions. Second, tracing contributed value through every restatement and refinement. You must be able to trace constraint and value all the way—solution, to a project, to portfolio or product, to strategy, or straight back to the fundamental drivers.
If it is so easy our profession would not have problems with effective change. Nor, would there be the challenges to our profession.
This week I'm moving to address the giant elephants in the room—why so many change programs collapse and why so many elegant candidate architectures never get actioned.
It isn't executive sponsorship. Come on. How is executive sponsorship missing if the stakeholders understood the benefit, the cost, and the uncertainty? If they didn't understand all three, what was approved?
It isn't having a mandate. It certainly isn't a seat at the table. Seriously, how was the target ever approved without engagement when the decision was made.
I guess you can see where I'm going. The root of both answers is work—unacknowledged work that proponents ignored or hand-waved out of existence.
Bluntly, change programs limp to a halt when reality strikes back. Once the level of work and tenuousness of benefits become clear, our organizations make the rational decision. They quietly abandon the initiative. They continue to wish they could have the benefits for free.
Annoyingly, the story with elegant candidate architectures never getting actioned is similar. They are based on benefits that only materialize after huge amounts of unacknowledged work are executed and hidden barriers are overcome. Just another way of saying benefits are free.
My uncomfortable observation. The difference between a strong EA team and everyone else is honesty.
The strong team engages with stakeholders about their hopes, fears, and dreams and does the math. It is why we stress celebrate every resolute no! When your company starts with acknowledging what will never work and what they will never pay for you have change energy. Change energy that can be applied to effective change.
Dynamic architecture roadmaps with harvestable value at clear stopping and pivoting points. Ooh, we all want some sticky, harvestable value. It sounds easy.
If it wasn't all wrapped up in uncomfortable facts and honesty it would be easier. Gaining permission to interfere with a successful organization is not easy. Often it is not fun.
When we have honest conversations, most plausible ideas will fail to clear your stakeholder's minimal cost-benefit-uncertainty hurdles. Yes, most. Yes, most will fail to clear the easiest hurdles.
Doubt me? I have yet to see an IT modernization, or Zero-trust, initiative that did not require clearing the most intractable problems the organization has. Yes, the most intractable. Until you can clear the most intractable what do you have? Ogre-like legacy applications reaching out and smashing your modern IT-systems and providing implicit-trust pathways around every control. You have no measurable improvement.
In our consulting work we are clear. This is a half bridge. In the right light it might look like a bridge. It cost as much as a bridge. You just can't cross the canyon. A half bridge is just an expensive narrower canyon.
This is why TOGAF, the industry standard method starts with Phase A. I know architecture vision sounds cool. An architecture vision is just a plausible idea that clears our stakeholder's minimal cost-benefit-uncertainty hurdle. That's it. Plausible and clears the easiest cost-benefit-uncertainty hurdle.
If the idea cannot plausibly clear a low-bar, stop. No amount of detailed analysis will fix fatal flaws. No amount of elegance overcomes reality. Don't do the detailed analysis. Stop. Celebrate. Move on. At best wishful thinking and hand waving will get a project that is designed to build a half-bridge.
A half-bridge is just a narrower canyon. I always think of Evel Knievel landing back on the starting side of the Snake River. Landing back on the starting side was good for Evel—drifting all the way back to the starting line saved his life. If he had not drifted all the way back to the starting line, he'd have drowned. Certainly brings home fatal flaws.
No miracle cures that ignore the real cost of implementation and sustainment. Don't get me started on silver bullet salespeople's aversion to honest discussions of uncertainty. Their silver bullets always hit the imaginary PowerPoint target.
To clear the minimal cost-benefit-uncertainty hurdles we have to understand the stakeholders' definition of value. Whatever our stakeholders value is the minimal hurdle test. They are wondering whether the candidate delivers enough of what they want for the work?
Frankly, I cannot understand what is so hard about aligning to our stakeholders' definition of value. Or accepting our stakeholders are comfortable with complex value judgements—just like we do when we buy a car, a home, or a dishwasher. My last dishwasher was assessed by brand identity, experience, reliability, cleaning quality, price, and noise. 43db is darned quiet.
Let's spend this week and look at how we make the measurements of value visible. I'll explain using a mainstream EA technique. All aimed at calculating whether architecture alternatives clear the minimum cost-benefit-uncertainty hurdle.
Summary Understanding through Capability Modelling
I love capability-based planning. In Navigate, capability is simply “the ability to do something”. It explicitly includes everything required to give the ability at the expected characteristics of the ability.
That is worth unpacking— “the ability to do something”, everything required to do it, while meeting the expected characteristics. This is why we use formal modelling—I always need to know about the big picture, the hopes, fears, and dreams. Then be able to explore different ways of delivering.
Capability sits right there. An ability to do doesn't tell you how to do something. If you need the capability to get to Victoria from Vancouver there are many choices—BC Ferries, commercial flights from airport-to-airport, or commercial flights from the harbour airport to harbour airport. Take a boat. Or, fly your own plane.
Every implementation is focused on the core problem—crossing the Strait of Georgia. Each has different characteristics. All fit into the transportation ecosystem. You have to get to the ferry terminal. Or, you need to get from YYJ to Victoria.
There you are, the ability to do something. You can look at Vancouver-Victoria in terms of crossing the Strait, or the entire journey. If you are building a comprehensive model it might make sense to look at Capability, and sub-capability, and capability interactions. It will be more productive not to. There are better modelling constructs for top-to-bottom and end-to-end. Save capability.
We reserve capabilities to be a 'management concept that facilitates planning improvement'. Capability can focus management attention on the key things that need to be improved. Capability implicitly includes everything needed—people, process, IP, infrastructure, facilities, business partners, information, even weather. Simply recognize when you talk about a capability you are talking about everything.
Complex breakdown models limit the power of a capability model. All they do is try to freeze your options and complicate talking about what you want with how it will be done.
That complication makes implementers happy, they feel the conversation is concrete and real. But, implementers live after the decision is taken on whether to improve or not. After the decision on whether we will fix a structural problem. After the conversation about the complete set of hopes, fears, and dreams.
Conversations that sit at the value center of enterprise architecture.
I use capability-based planning to open the conversation. I use it to focus on:
- Things we need to start doing
- Things we need to stop doing
- Things we need to keep doing well
- Things we need to improve how we do them
I'll never build a complex functional model, or process model, and call it capability. I build capability models that look closely at what we need the ability to do. Have a look at three Conexiam Consulting examples—NA Construction, the AI Adoption Critical Capabilities, or the EA Capability Reference Architecture.
In every case, what ability to do needs to exist, end, be sustained, or be improved.
NA Construction is an anonymized client. In their transformation, everything focused on sustaining existing excellence in building things—Project Initiation, Project Execution, and Production Execution. They were very happy with their individual ability to build. They were sad about their ability to work as one company.
Capability Properties Code
We use properties to simplify the conversation about what we want. My team will use phrases like 'S55' or 'Parity 5' to convey a huge amount of information. They are properties that can express a reasonably consistent description of current and future state.
Capability Model Properties
Competency—Relative to our peers, how good must we be?
This property is used to provide an external calibration for the ability to do. We use three measures: Parity, Advantage, Superior. Parity defines we need to be as good as our peers. Advantage defines we need to be in the top quartile of our peers. Superior, defines we will be best in class in our peer group.
This property is used to guide organization design, process, depth of intellectual property, and need for specialist IT system and facilities.
Agility—How adaptable must this capability be to unexpected threats & opportunities?
This property is used to assess the pressure to react to unexpected threats and opportunities. This property guides organization design, process, and IT systems.
Automation—How much automation is expected?
This property is used to identify the future state preferences. Higher scores indicate a preference to less human intervention.
This property guides organizational model, organizational design, process, data flows and IT systems.
Operating Model—How will we deliver this capability?
This property defines how this capability is deployed in an organization. We draw from MIT CISR's four measures: Unified, Replicated, Coordinated, or Diversified.
This property is used to define the organizational model, process, data flows and IT systems.
Performance State—How consistent and scalable is the quality?
This property is used to explain the depth, scale and predictability of this ability. We use three measures: Just starting, regular delivery, and consistent.
This property is used to define the depth of organizational support, training, standardization, management, and IT systems.
Performer—Who does this?
This property is used to define who will deliver the capability. Performer can specify the company, specific departments, a close 3rd party (business partner), a general third party (contractor), or even the customer.
This property is used to define organizational design, data flow, IT system support and the need for specialist facilities. Often developing leading capabilities requires the effective selection and inclusion of key partners with scarce skill, experience, and technology.
This property is used to define the depth of organizational support, organizational design, management, process, data flows and IT systems.
S55 / P53 / S53 Trade-off
Properties provide a high-density record of what you have, and what you want. With experience they provide cascading directions from superior architecture and business architecture.
Every time your stakeholders select a property they are providing directions—performance expectation and constraint—to every architecture domain.
Superior competency—best in class performance relative to your peer group—means you want to blow past Porter's productivity frontier. You will invest in changing organization, process, and IT systems to eke out whatever it takes to be better.
Parity—peer matching performance—means you will aggressively benchmark. You will invest in industry-best-practice process and tooling. You will squash every unique element of your organization because you want to save scarce thinking and investment resources.
S55, P53, or S53 is loaded with clues. And expresses a par of real trade-offs. Superior vs Parity and level of automation. Each capability configuration with an absolute requirement to easily react to unexpected threat or opportunity.
Think about what these choices tell you.
| Automation 3 | Automation 5 | |
|---|---|---|
| Superior | Best-in-class approach to business activity. Light automation leans to high-skill staff, and acceptance of variable process. | Best-in-class approach to business activity. High automation leans to rich custom software development, typically high-levels of standardization, and an explicit desire to de-skill the staff. |
| Parity | Match-our peers approach to business activity. Light automation leans to acceptance of variable process. Parity processes tend to have a peer-matching quality with investment focused on efficiency, or productivity. | Match-our peers approach to business activity. High automation leans to buying industry standard suite-software, and adjusting organization and process to match the software. Peer-matched quality focused investment on standard-software enabled efficiency, or productivity. |
Parity 5 we invest in out-of-the-box standard software to squeeze efficiency. Parity 3 we invest in standardizing training and supervision to drive productivity. With Superior 5 we invest in custom development; because you cannot buy a box stuffed with better than the rest.
Across all these options we have Agility 5. We explicitly will invest to gain the freedom to change. The ability to react to threats and seize opportunities. In every case we will put a fence around this capability. It cannot be constrained outside the capability. We won't be looking at a broad suite here—we need freedom to react and we need the ability to switch tools, techniques, measures and approach.
Right here we have a fascinating architecture trade-off conversation. We are asking:
- does improved mean match peer quality attributes or re-invent best?
- does best come from enabling highly skilled people, or doing cool things with software?
- does improved come from training people, or implementing industry standard software?
I can architect a S55, P53, or S53 capability. Either by investing in software development (S55) or investing in people (S35). In both cases, I will be looking for the vision leader who can define better than the best peers.
If we move to a P35 again I'm happy. We'll be investing in domain-specific software that is purchased bundled with strong industry experience. I want someone who knows peer-matching quality and can squeeze the parity benchmarks.
By the way, in both these cases the current state tells me whether we will bother gathering business requirements. Transitions that jump—Parity-to-Superior or 3-to-5—tend to invalidate existing experience. Superior requires we understand the definition of best. Selecting Parity tells us to match peer quality, then drive improvement to the productivity frontier.
As a result, if the people cannot tell me how to be best, I am uninterested in hearing how they are currently average. Or, if they cannot tell me how to reach the productivity frontier, I'm not interested in learning about existing practice. The fact there is a gap tells me existing practice does not follow industry-proven best practices that deliver peer-matching quality.
I'd like you to reflect on using scores. When a stakeholder selects S35 or P55, I have a strong set of guidance and constraint that applies to every downstream project or solution. Take a moment, think about the directions and constraints you will pass to an implementer.
Conclusion of Enabling Visible Investment Decisions
One of my consulting team always refers to S55 capabilities as a depth charge dropped from above. It doesn't matter what you have. Down the S55 comes. Boom. everything in the blast radius blown apart by the stakeholder demand to re-define best, automate, and retain agility.
An informed stakeholder decided that they will
- invest to be better
- invest for easy change
- invest in cool software
Remember last week when I said projects will take care of themselves if I can tell them how to win—whether they must take the shared system (P33 is very common), or cannot consider it. I trust you can see why I pity the fools, who assume their preference is the organizational priority.
S55 and S35 are both best in class business activity and extreme enterprise agility. S and 5 are the hard requirements we must architect to. Superior demands we know what it takes to be better than our top performing peers. Agility 5 demands we know the boundary of the capability and think about what it takes to change.
I'll be honest most Superior capabilities are Agility 4 or 5—every competitor, and industry vendor, watch the best and tirelessly work to commoditize best. It takes very little to coast from Superior through Advantage to Parity.
Value calculations are complex. Think about that dishwasher. Is 43db worth something by itself? Or, does 43db reinforce quality and brand. Does that reinforcement give them the strength to explain a higher price? It will always come down to judgement.
Judgement is why we do architecture trade-off. We need the benefit of our stakeholder's expertise. Just to answer simple questions about whether there is enough value in a value resting point. Whether we need more efficiency in a P. Less automation. Or whether to deliver efficiency or variability we must start from scratch and re-work everything into a digital work environment like Pega, or Appian.
I'm not asking my stakeholder to pick Pega or Appian. I'm asking whether it is acceptable to meet their automation and agility requirements we bin-the-lot and restart with a digital work manager. I was not joking a S55 is a depth charge. Everything inside the stakeholder demanded blast radius is a variable.
Nor was I joking that you will celebrate no. Many stakeholders want S55, yet will accept A33 as a VRP. Their acceptance will be driven by time-to-market, cost, or unacceptable uncertainty. The reason tells me about priority trade-off. Whatever the reason, I will take that resolute decision to relax VRP1 and own it like it was my favourite idea of all time. Depending on the priority, I'll keep an eye out for faster, cheaper, or more certain paths.
I want you to think about your current work. Are you holding multiple candidate targets and VRPs constantly in your head? During Phase A you must. When building an architecture roadmap you must. If you are not, I suspect you created artificial architecture decisions. Exploring real architecture alternatives means exploring the impact of adjusting expected value, work, and uncertainty.
I encourage you to look at our Capability-based Planning Guide. It goes further into the techniques I mentioned here. We use these techniques to simplify the conversation.
Next week I'll jump right into the hard work of exploring real architecture alternatives—looking at adjustments to expected value, work, and uncertainty across different time and investment horizons. Yep, you got it, the hard work of our profession—architecture alternatives and dynamic architecture roadmaps.
As always, I look forward to your feedback and comments.
Have a great week!
regards
Dave
Dave Hornford
Conexiam
PS: BC Ferries moves millions of people to and from the island for ~$100. Most sailings have room for more cars. The system cannot respond to unexpected maintenance, unusual weather, cavorting marine mammals, or Taylor Swift concerts. When the unexpected happens, you wait.
Agentic AI Playbook Conversations
Agentic AI Playbook Conversations We have been been deeply immersed in the evolving landscape of AI Adoption, engaging in a journey encompassing both technical intricacies and broader digital transformation. We developed the Business Leader’s Guide […]
Download AI Adoption Critical Capability Reference Architecture
Download AI Adoption Critical Capability Reference Architecture AI Adoption requires innovation thinking. Today we do not have proven best-practices for widespread AI Adoption that consistently improve our organizations. We require the ability to re-imagine our […]
Download Business Leader’s Guide to AI
Download Business Leader’s Guide to Artificial Intelligence Organizations that successfully apply innovative technology have had a competitive advantage. Innovative technology does not come with established success patterns and best practices. Innovative technology is novel and […]
Download the Introduction to the TOGAF Standard, 10th Edition
Download Introduction to the TOGAF® Standard, 10th Edition The TOGAF Standard, 10th Edition makes adoption of enterprise architecture best practices easier. It separates the universal concepts from proven best practice. The standard underscore where to […]
Download Capability-based Planning Guide
Download Capability-based Planning Guide Always drive to realize value. Half an improvement is 100% waste! No one teaches an Eagle to crawl, walk, or run. Eagles Fly! Download Teach your Eagles to Fly: Capability-based Planning […]
Download Business Architecture Capability Assessment Guide
Download Business Architecture Capability Assessment Guide Download a Business Architecture Capability Assessment Guide. Capability-based planning is one of the most powerful business architecture improvement techniques. Best practice of capability-based planning uses capability as a management […]
Download Sample Enterprise Architecture Principles
Download Sample Architecture Principles Download a sample enterprise architecture principles. Enterprise Architecture principles identify how to approach a problem or decision. The approach always drives you towards your enduring priorities. Download Sample Enterprise Architecture Principles […]
Download Enterprise Architecture Governance Guide
Download Enterprise Architecture Governance Guide Download the Enterprise Architecture Governance Guide to understand best practice to direct and control the development of architecture, and change to obtain the expected outcomes. Download Enterprise Architecture Governance Guide […]
Download TOGAF and SABSA Integration
Download TOGAF and SABSA Integration Bring SABSA, the world’s best security architecture framework, and TOGAF, the industry standard enterprise architecture framework together. Download TOGAF and SABSA Integration TOGAF and SABSA Integration Includes SABSA uses a […]
Download Enterprise Architecture Capability Reference Architecture
Download Enterprise Architecture Capability Reference Architecture The Enterprise Architecture Capability Reference Architecture will speed up establishing and enhancing your EA Team. Design your Enterprise Architecture Team for success. Identify and enhance the your enterprise architecture […]
Enterprise Architecture Training and TOGAF Training
Business Architecture Training Course
Business Architecture Training Effective enterprise architecture relies on business architecture. The course gives students the skills and knowledge to develop business architecture in an enterprise architecture setting. Business architecture involves describing the structure of the […]
TOGAF Enterprise Architecture Training Course
Do you want training for TOGAF Certification? Demonstrate your knowledge of enterprise architecture with TOGAF Certification TOGAF® Enterprise Architecture Training Course Take a major step to be a better enterprise architect with TOGAF Standard, 10th […]
Custom Enterprise Architecture Training
Custom Enterprise Architecture Training Custom enterprise architecture training addresses the professional development your EA Team needs. Good enterprise architects use a broad set of skills, method, in addition to specialized domain knowledge to develop enterprise […]
Enterprise Architect’s Kickstart
Enterprise Architect’s Kickstart We need to keep our skills current. More now than ever. Use the Enterprise Architecture Kickstart to improve your ability to deliver transformative enterprise architecture. This 90-day kick-start is how Conexiam Consulting […]
Effective Online Education
Effective Online Education Effective online education works. Students to access the best available instructor. Students control the pace of their learning. Instructors can share rich supplemental material without distracting from the primary topic. Effective distance […]
Avolution ABACUS Training Course
Avolution ABACUS Training Effective enterprise architecture relies on formal modeling and analysis. We provide Avolution ABACUS training from hand-on enterprise architects. Students gain skills and knowledge to create integrated enterprise and domain architectures in this […]
Go Further with Best Practice Enterprise Architecture Process and Method
Best practice enterprise architecture from Conexiam Navigate
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 […]
Discover the Power of Enterprise Architecture Patterns
Discovering the Power of Enterprise Architecture Patterns: A Comprehensive Guide Every organization wants to improve. Streamline their operations. Enhance their enterprise agility. Align change with their strategies. Succeed at digital transformation. Enterprise Architecture, a discipline […]
Everything You Need to Know About Using Architecture Alternatives
Everything You Need to Know About Using Architecture Alternatives Architecture alternatives are required for good enterprise architecture development. When you start architecture development, your enterprise has deficiencies. There are areas for improvement. You need to […]
Developing an Architecture View
Developing an Architecture View Enterprise architecture is an essential compass. It helps organizations navigate the complexities of technology, strategy, and operations. The core of enterprise architecture is a systematic approach. The objective is to ensure […]
Enterprise Architecture Work Management
Enterprise Architecture Work Management Enterprise Architecture Work Management is crucial to the day-to-day success of an Enterprise Architecture Team. Architects must deliver useful guidance before stakeholders make informed decisions. Enterprise architects need to translate the […]
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. […]
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 […]
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 […]
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. […]
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 […]
Stakeholder Engagement Workshop
Stakeholder Engagement Workshop Stakeholder Engagement Workshops start your architecture development on a firm footing. Understand your key stakeholders, their concerns, how to engage, and how to communicate. Get Help to Start Today Stakeholder Engagement Workshop […]
Enterprise Architecture Capability Workshop
Enterprise Architecture Capability Workshop The Enterprise Architecture Capability Workshop starts with your enterprise architecture use case and develops an improvement roadmap for your EA Team. The Enterprise Architecture Capability Workshop results in a designed EA […]
Scenario-Based Architecture Roadmap Workshop
Scenario-Based Architecture Roadmap Workshop Scenario-Based Architecture Roadmap Workshops develop candidate architecture roadmaps using scenario analysis. Scenario analysis tied together with architecture roadmaps are powerful tools when used early in architecture development. When you need to […]
Enterprise Architecture Governance Workshop
Enterprise Architecture Governance Workshop Enterprise Architecture Governance Workshops ensure your architecture project and implementation project have the architecture governance to succeed. You do not have time time to run failed improvement efforts. Enterprise Architecture Governance […]
Data Architecture Foundation Workshop
Data Architecture Foundation Workshop Data Architecture Foundation Workshops develop string foundations for your data architecture. Used to set the state for Data Governance Initiatives and Data Initiatives. Understand your data landscape – what are the […]
Initiative Strategy Workshop
Initiative Strategy Workshop Initiative Strategy Workshops develop a strategy for an initiative. Used for new initiatives, and initiatives that have stumbled. Understand what actions are available to reach the outcome. Be able to articulate the […]
