Let’s Get This Party Started: How to Start a Business Architecture Practice


15 May 2017


07 May 2020

Learning Pathway


Published In

Knowing what business architecture is: Check.
Knowing why we do it: Check.
Knowing where it fits within the strategy execution life cycle: Double Check. Knowing where to start: Not so much.

Starting business architecture within an organization can be a fairly organic process, but there are a proven set of steps to follow.

Knowing what business architecture is: Check.
Knowing why we do it: Check.
Knowing where it fits within the strategy execution life cycle: Double Check. Knowing where to start: Not so much.

So where do we start then?

Starting business architecture within an organization can be a fairly organic process, but there are a proven set of steps to follow. The first one is to build a really solid understanding of what business architecture actually is, including its scope, how it integrates with other things, and the value it can provide. (Thank goodness for StraightTalk.) This is important. Do not pass Go. Do not collect $200 without it or you can get a bit off track and have to course correct later.

The second step is to define business architecture’s value for your organization and establish a team (which could be a team of one to start). Start formalizing it. Approach this as if you were working in a start-up, even if you are not. You’re essentially establishing a new thing here, so Step 2 is a pretty official commitment. As a result, people often have to do some work to demonstrate business architecture in action first before they can get the buy-in from leadership to actually establish a team. It takes some organizations awhile to even get to Step 2. If this is your situation, not to worry. It’s normal.

Got that part. What next after we have the team established?

After Step 2, your business architecture journey begins in earnest. Since most business architecture teams start with just a few people and have a need to continually demonstrate their value, they can’t just hang out for a year or two documenting their business architecture knowledgebase. With that reality in mind, here is a pragmatic approach to make this work in the real world. Secrets from a business architecture Sherpa who has been up this mountain many times.

First, keep in mind that there are always three components necessary to establish business architecture within an organization and they are:

  • Building your business architecture knowledgebase
  • Applying business architecture to various scenarios
  • Creating your business architecture practice infrastructure

Second, never lose sight of the fact that the most important activity a business architecture team performs is to apply business architecture for value. This is our guiding light. Honestly, building the knowledgebase and creating the supporting practice infrastructure are performed in support of this and both should be approached in a “just enough” and “just in time” manner to support the relevant business architecture application scenarios currently in focus.

Diagram representing roadmap path for business architecture practice

Business Architecture Practice Roadmap

Downloadable Media

So can we apply business architecture without having a knowledgebase in place?

Nope. There’s a critical and minimum baseline of business architecture that you need in your knowledgebase before you can actually be taking an enterprise business architecture approach. You might be doing fantastic work, but it just may not be architecturally based.

Hmmm. What is the minimum business architecture baseline then?

For most organizations, the minimum baseline includes an enterprise capability map, a set of enterprise value streams and a cross-mapping between the capabilities and value streams. Emphasis on the word enterprise. If these things are defined from a business unit, product or other siloed perspective, then we lose the power and intention of business architecture. There are lots of shortcuts, but this is not one of them.

To clarify further, some organizations will document the full scope of their capability map at the highest level of detail (called “level 1”) and only break down some of those capabilities into more detail (like down to “level 2” and “level 3”) to start. Also, some organizations will only document a few of their known value streams upfront instead of doing all of them. In most cases, they will focus on the capabilities and value streams that are customer-facing, but that’s up to you.

Talk more about what you mean by business architecture “practice.”

The concept of a “practice” is simply a way to refer to the intentional collection of activities performed to achieve the defined mission for business architecture within an organization. This is what that Track 2 is all about in the picture above.

Your business architecture “practice” includes all of the things you do to mature, measure and sustain the business architecture, the business architecture practitioners and the practice itself. Want a checklist? Here you go.

  • Business Architecture Stuff — Business architecture maps in your knowledgebase; architecture processes, methods and practices; governance; tools
  • Business Architecture Practitioner Stuff— Structure and roles; education and mentoring; resources and staffing; community and support
  • Business Architecture Practice Stuff— Practice planning; measurement; change management and adoption; organizational alignment and integration

The key is to be intentional about formalizing all of these things.

Do we have to?

Yep. As soon as you hit Step 2 on that roadmap, you need to start formalizing. There is even a “maturity model” that helps you to measure how well you’re doing these things. Many organizations do not invest in their practice and many don’t know that they need to. But as soon as business architecture’s footprint starts to expand, there will inevitably be an increasing need to tell the story of what you do and have some structure in place. Bottom line: a solid practice will help you scale to meet the demand for business architecture across your organization and the act of formalizing makes it real and gives it credibility. And business architecture requires lots of evangelizing and relationship building, just like a start-up does.

The only exception here is that if you work in an actual start-up organization, then you’ll likely keep your business architecture rigor light weight in the beginning and increase it as the organization grows.

Got it. But now I’m a little overwhelmed.

Remember that this is a journey, and journeys are taken one step at a time. Whether you are just about to embark on your business architecture journey or if you are already on your way up the mountain, know that it will be worth your effort, both personally and to your organization. You have an important destination. You’re in great company. And as mountaineer Alison Levine reminds us, sometimes you have to go backward to go forward. You do not need to have total clarity to put one foot in front of the other. And from a personal standpoint, the summit isn’t as important as the journey, and the lessons you learn along the way will make you better and stronger on the next mountain.

More good stuff.

  • The Business Architecture Practice (S2E Whitepaper): A longer version of this story to help guide you through your journey of establishing and maturing a business architecture practice.
  • Lessons From The Ledge (TED Talk): TED Talk by Alison Levine, team captain of the first American Women’s Everest Expedition. This is big-time inspiration and wisdom, even if the mountain you’re climbing is called “starting a business architecture practice” or just that great one we call “life.”