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.
