Post No. 8 is all about answering those burning questions around organizational structure and such. Here goes.
First, where should the business architecture team report?
Starting with the big one. For years now, there has been a trend of business architecture teams reporting to the business—and with success, for a number of reasons. So the StraightTalk answer is: ideally the business architecture team should report within the business.
Why is that?
Business architecture is about the business and when it is closely aligned with it, business architects have more access to decision makers, more knowledge of business direction, and better buy-in. The “you’re one of us” thing helps a lot.
Who do business architecture teams typically report to?
Frequently business architecture teams report to business leaders responsible for strategy, planning, transformation, innovation (or any combination of these), though there are many other examples, such as teams who report to different C level executives.
Business leaders who have responsibilities that cross business units and care about business direction being executed well are good candidates for the business architecture boss role.
What about all the business architecture teams that report to IT then?
Of course there’s more to the story. And this does at all not mean that business architecture teams who report to IT will not be successful. In fact, many business architecture teams incubate in IT since there may be the initial buy-in and skills there to help get the practice off the ground. A lot of teams will then shift to report to a business leader later on.
The bottom line is that having the business architecture team report to the business is ideal, BUT you start where you can start, and ultimately the best answer is: where it works best for your organization. Because it has to work with your organization’s needs and dynamics.
How does everyone stay coordinated then?
Key point. Business architects essentially have a foot in two different worlds, one in the business and one as part of the enterprise architecture team (with the IT architecture disciplines of application, data and technical architecture). As a result, no matter where the business architecture team reports, they will always need to maintain close partnership with the other. For example, if the business architecture team reports in the business, they need a virtual relationship with the IT architecture teams (who may be reporting centrally to an enterprise architecture leader or the disciplines may have separate leaders). Vice versa if the business architecture team reports to the enterprise architecture leader, they need to have a very close relationship with the business which is who they are ultimately serving.
But great news. These dynamics may add more complexity for the business architecture team, but it also allows them to be a bridge between the business and IT. Business architecture can help to bring IT even closer to the business.
Got it. Next, how are business architects organized?
Simply stated:
- Business architects can report centralized – Where all business architects report to one leader (in business or IT), though they still may have focus areas like a certain business unit, product, capability / value stream or other domain to architect.
- Business architects can report decentralized – Where all business architects report to different individual leaders (in business or IT).
- Business architects can report in a hybrid structure – You guessed it, where some business architects report on a core team to one leader (e.g. to a head of business strategy and transformation) while others report to individual business leaders (e.g. for individual business units).
Which one is best?
Depends. The hybrid structure typically provides the best benefits, especially for large business architecture teams. For example, the business architects in the core team may focus on architecting across domains (e.g. for a set of enterprise-wide capabilities) while the business architects who report to individual business units or domains architect within that scope. In addition, the core team can provide a focal point for managing the practices (e.g. methodology, tools, governance, etc.) which are used by all business architects. This part is often referred to as a Center of Excellence (COE).
In fact, here’s a picture on all that for you:
Anything else?
Yep. No matter what organizational structure is utilized, all business architects across the entire organization should share one business architecture knowledgebase (unless your organization functions really differently and doesn’t share customers across business entities or units, like a conglomerate) have consistent practices and collaborate constantly.
Is that it?
One more thing. Sometimes parts of the business architect role are performed by other people, like using the business architecture as part of their jobs or contributing to the creation of it. When this happens, it is a good sign that business architecture is becoming embedded into an organization.
Keep in mind that your business architecture team structure can shift over time as your business architecture practice matures. This is normal and in fact necessary so that you can adapt and stay relevant to the organization as its needs evolve.
More good stuff…
The Evolution of the Business Architect (Mike Clark and Whynde Kuehn): Just in case you didn’t check this one out with post No. 7, here it is again. Good stuff in this one about how to deploy business architects across an organization.
How to Set Up a Center of Excellence (cleverism.com): A nice and simple overview of the what, why and how of setting up a Center of Excellence in case you are new to the concept.
The Emergent Genius of Ant Colonies (TED Talk): A TED Talk by Deborah Gordon that is oh so fascinating on the topic of organizational structure, teamwork and behavior—in ants. Just for fun.
Okay, thanks to 