Navigate Business Architecture—Myth of the Constant

Demolishing the Myth

I know the strength of the myth. The business—yes it is always called the business in the myth—sits in some special meeting and decides exactly what they want. Then, the business rings the order bell, states demands, and impatiently awaits delivery.

The myth is laughable.

We all work in the real world, not some mythological setting. Anyone who thinks we ever had a simple order-taking process needs to think about the internet. No one in any business said, 'Hey let's do e-commerce. Step 1, invent the Internet. Step 2, invent web-servers and browsers. Step 3, convince 500 million consumers and 50 major telecom players in EU/North America to get high-speed wires moving IP packets to their homes and businesses. Step 4...'

In the real world technology and competition crash into our organizations. Modern digitally engaged organizations react to technology. They react by reorganizing, recrafting business activity, and reskilling.

They react, by changing the business.

Stop and think about it. How would we 'grow market share with our market segment' using the same organizational design, same processes, and same skills? The organization, processes, and skills that didn't do it last year. Or, the year before.

We all know the answer. We won't. Any change plan that treats the business as a constant will fail. Yes, unequivocally it will fail.

I know, there will be a distressing session of change theatre. Flashy green PowerPoints will highlight a lot of completed activity. You know what we get. A narrower, more expensive, version of exactly the same impassable canyon—that does not deliver more market share.

What is a Business Architecture?

Architecture domains give us the power to analyze and explore part of the organization. To identify the levers, accelerators, barriers, and constraints in that domain. Then link it back through the other domains.

Business architecture gives us the ability to find what needs to change, the reality ifs, and all settled decisions in superior architecture. More importantly, it gives us a language to test whether the current change idea could deliver enough value to earn permission to interfere with our successful organization.

Conceptually, business architecture is just like any other architecture domain—it explains a system. Data Architecture explains and enables the "data needs of the enterprise". Application Architecture explains "structure and interaction of the applications that support key business capabilities and manage the data assets".

Both data architecture and application architecture are impossible in the absence of a business architecture. Bluntly, where else will you find the data needs of the enterprise and what a key business capability is?

In Navigate, we break the business architecture into three parts:

First, understanding the contour of the organization. The deepest superior architecture. Explaining the business model, the ecosystem, how the company is assembled.

Second, understanding how value is measured and created. The fundamental drivers and measures. Explaining the value chain configuration, products and services, and product family specific business models.

Third, understanding the normal levers for change. Key business capabilities, activity models, and organizational design.

As we traverse from a capability model to the fundamental business model we are moving deeper into superior architecture. A change initiative can put the foundational roots of the company on the table as a required if.

However, let's be clear. Product Family A's architecture initiative to grow share is not putting the value chain, let alone the business model, into the mix. It is looking hard at the normal change levers—capabilities, activity, organizational design, and skills.

Putting the foundations on the table takes a serious transformation. Something like the NA Construction strategy case in our EA with TOGAF and Navigate course. That digital transformation was designed to change the core business model from diversified to coordinated.

Cascade and Reverb

You may have noticed whenever I talk about the business, I include technology. Whenever I talk about technology, I include business items like organization, process, skill, and knowledge.

Everything is connected. I cannot drive a change in only one domain unless I live with the myth of the constant. Pretending I can change the business without changing technology. Or, pretending I can change technology without changing the business.

Every change requires business change. Implementing assembly line robots requires organizational change. Self-driving 200-ton trucks require different skills. Simply maintaining a building full of complex integrated medical diagnostic systems requires organization, process, skill, knowledge.

That is just the first-level visible changes. Changes cascade and reverberate across the organization. The simple first-order organization and process changes can stress HR's ability to recruit and retain. Organization, process, and HR changes may drive new digital systems. The new systems can upend decades-old IT approaches. Organization, process, HR, and IT changes inevitably impact data flow and the security architecture. At every step in the cascade there are reverberations.

Those upended decades-old IT approaches mean new organization, process, and HR change. Those upended decades-old IT approaches provide a new stratum for primary business unit changes. Remember the internet? When we started using the internet—web-clients, mobile clients, SaaS—we had new possibility, opportunity, and threat. Suddenly a SME in the business could look up and say, 'Hey, we should move into e-commerce'.

Concluding Myth of the Constant

When I see the future being explored, I see a complex weave. I see the reason our organizations invest in enterprise architecture.

We provide the tools to explore a complex weave of possibilities, hopes, fears, and constraints. We facilitate an informed conversation that crosses specialist domains. A collaboration that harvests focused attention and specialized talent—across the organization and across architecture domains.

Our profession provides the rich vocabulary to discuss change. Before the decision to act we use the concept of the architecture project to tell us where we have constants, and where we have variables.

Take a minute and think about this. Depending on the architecture project and the if, a prior decision as fundamental as the enterprise's business model can be:

• a bedrock fact to work around;
• a potential variable;
• the deficiency in the current state that must change

Our NA Construction strategy case is based on a business model change. The Product Family A example I've been using, where we need to grow market share, takes the business model, the product model, the value chain, and the product value proposition as superior architecture bedrock facts.

The scope of the architecture project determines what is a constant and variable.

Here is my bald thesis—every prior architecture decision in every architecture domain is a potential variable. Whether it is a variable—whose change corrects the current deficiency—or a constant, is a function of the cost to change. Because doing the math on every potential change every day isn't worth it I use a shorthand. I seek the smoothest, smallest change across any domain.

Seriously, the smoothest, smallest set of if-based-change in any domain. I'll change anything to deliver my stakeholders' hopes and dreams. Or, squash their fears.

The business architecture domain often is filled with deep superior architecture—business model and value chain configuration. As well, our other domains exist to enable the business architecture. Despite this, the current state holds no privileged position. Other than superior architecture, everything in every domain is a variable.

In fact, most of the business architecture is easier to change than the other domains.

My challenge this week is tied to the myth of the constant. Look at your existing work. Where have you implicitly assumed a constant? Especially, where have you privileged current organization, process, and activity as a constant you must work around?

Go further, where did you think about a system change alone? Pretending that there were no required changes in organization, process, activity, and skill to implement, maintain, operate, use, and support the system?

Next week we'll continue our journey into business architecture with 'Mapping the Landscape'. Then we'll explore understanding value, before switching to driving change. As an enterprise architect, I have the most fun with business architecture. When I do my job, I'm lined-up with the organization's foundations. I can demonstrate the value. I give my stakeholders change levers that flip massive barrier boulders out of the way.

Have a great week!

As always, I welcome your feedback and questions.

Regards,

Dave

Dave Hornford
Conexiam