< Back to StraightTalk — The Blog

The Good, The Bad, and The Ugly: Dos and Don’ts For Establishing a Business Architecture Practice

By Whynde Kuehn | 1 April 2019

Subscribe >

This installment gives you the straight talk on some serious dos and don’ts for establishing a business architecture practice within an organization. We’ll ground our conversation by reflecting on a fundamental concept of the business architecture discipline — often misunderstood — that will assist in guiding you and help you to stay on the right path.

Okay, so what do we need to know?

Business architecture is an enterprise discipline. This is the fundamental concept to understand and remember.


This means that an organization’s business architecture should:

  • Describe the entire scope of an organization’s ecosystem (it is created top-down—not bottom-up by individual business units or projects)
  • Represent that ecosystem at a high level of detail (allowing us to see the forest for the trees for new insights and targeted focus)
  • Be shareable and reusable (giving everyone the same mental model about what the organization does)

Can’t we just use business architecture as a set of tools and techniques that we can apply whenever we want to, such as for a specific business unit or project?

You can do anything you want.  However, creating business architecture piecemeal and in isolation for a certain business unit or project does not leverage the full power of business architecture. If you define your business architecture at an enterprise level as described above, it will give you the ability to break down and facilitate collaboration across business silos – something that almost no other disciplines or techniques can do. On the other hand, if you create and practice business architecture separately within multiple silos across your organization, it will only serve to reinforce the silos.

If there has ever been a time when business architecture is so desperately needed to look across silos, that time is now. Business architecture allows us to finally create cohesive customer experiences, work together like one organization to transform and simplify our operating environments for cost savings and future organizational agility.

Won’t it take a long time to document our business architecture at the enterprise level?

Most people assume that documenting business architecture requires a lot of time. However, there are ways to greatly accelerate the development of your organization’s baseline of capabilities and value streams, and then you can build the rest over time – driven by practical business value and usage.

If this topic is new to you, don’t worry, StraightTalk has you covered on other posts:

What does this mean to an organization’s business architecture practice then?

Based on the fact that business architecture is an enterprise discipline when you establish a practice within your organization, there are two immutable principles:

  1. There is one shared business architecture for an organization.*
  2. Business architecture practitioners utilized a shared methodology.

* Unless the organization is a conglomerate or equivalent level of structural difference.

There are many areas of business architecture where flexibility is welcomed and has no implication – but that is not the case here. These principles apply regardless of organizational structure. In fact, there are many good examples of organizations that have created effective and robust business architecture practices with only virtual collaboration (i.e., where there is no central business architecture team officially on the org chart).

So how do we know if our business architecture team is on the right path?

Below are a few common paths that organizations tend to find themselves on. Try to start on and stay on The Good path, but what’s most important is to recognize where you are — and if necessary, course correct when you can to set yourself up to have the most successful and scalable business architecture practice as possible.

  • The Good path (one single enterprise business architecture practice) – Regardless of team size, this is when you have (or are taking action to have) one business architecture and methodology for the entire organization. This will allow you to fully leverage the business architecture discipline and effectively scale your practice over time. Keep going. Stay on this path as you grow and evolve the practice.
  • The Bad path (some separate business architecture practices exist within silos) – This typically happens when you are in the early stages of your practice, but have two or more business units with different architectures and practices. Veer now. Do a business architecture maturity assessment and take full action now to shift to an enterprise practice (before it gets ugly).
  • The Ugly path (many “mini” business architecture practices exist within silos) – This is when business architecture has been deployed across all (or significant portion) of business units, each with their own separate business architecture and differing practices. This only partially leverages the true value of business architecture and unfortunately reinforces the silos. It also tends to create chronic confusion about the discipline throughout the organization. Course correct. Do a comprehensive business architecture maturity assessment and work together on an action plan to shift to an enterprise practice.

All of that is summarized here for you in this handy diagram.

Guidance for establising business architecture practice diagram

Got it. Anything else?

Regardless of which path you are on, you can always adjust. (And if you’re not on the path you’d like to be, you’re not alone.) Keep in mind that we are all on this journey and the steps we take every day continue to move our organizations — and the business architecture discipline — forward every single day.

More Good Stuff…

The Business Architecture Practice: A Practical Approach to Establish and Mature Your Internal Practice (S2E Whitepaper): A foundational whitepaper on how to establish and mature a business architecture practice within an organization.

Case Studies On Establishing and Maturing a Business Architecture Practice: Learn from your friends. Here are a few examples from previous Business Architecture Guild® Summits where business architects have shared their business architecture journeys.

On Being Wrong (TED Talk): A TED Talk by “Wrongologist” Kathryn Schultz who makes a compelling case for not just admitting but embracing our fallibility. And rediscovering wonder.