I had been planning to do a segment on where business architecture fits into the enterprise org structure for a few weeks, when I happened to have a conversation with the head of global enterprise architecture for a large company. In this conversation, he shared with me the organisational structure of this discipline. I wasn’t in a good position to critique the structure, but it was fatally flawed. I’ll explain why as I articulate how I recommend adjusting this. But first, allow me to set up the narrative.
It is not uncommon for business and technology disciplines to have adversarial relationships within organisations, whether large or small—or something in between. Each feels that the other doesn’t understand the challenges of their respective workaday lives. Technology resources tend to be further removed from the business goals than their counterparts in the business. They should be aligned to the same enterprise objectives at the highest level, but because of their job functions, these objectives necessarily have a different weight and focus. A technologist’s goals are more typically filtered through the lens of the implementation and activation needed to enable the desired customer experience necessary to generate revenue and loyalty. This is less of a focus for the business folks.
Given the adversarial nature of business and technology functions, which I’m going to characterise as typical, embedding business architecture resources in a technology function is weak tea. It places the business architect on the wrong side of the divide. We can argue that this divide shouldn’t exist, and I don’t disagree, but this is easier said than done. This can be mitigated by embedding the right resource in the business unit. In fact, a dotted line or matrixed organisation structure might be a more successful implementation, though this creates its own challenges beyond the scope of this segment. In my experience, this is not a scalable solution, as it relies more on the personality of the business architect and interpersonal dynamics, so it’s not the most stable of implementations.
Trigger Alert. I’ll go out on a limb to suggest that if you are a technologist and don’t feel that the business should own certain pieces of the enterprise architecture function, this may be a vestige of this adversarial relationship, and you may have a knee-jerk reaction to disagree. But that’s OK.
One of the biggest challenges for a business architect residing on the IT reporting chain is the conflict of interest. The conflict that the resource experiences by fundamentally and necessarily focusing on the business, and on customer experience, yet reporting to a delivery organisation. I am not saying that this can’t work. I am saying that it’s playing from a weak hand. The deck was already stacked against your favour, so by placing business architecture on the IT side of the house, you’re unnecessarily creating an up-hill battle.
In a moment, I’ll describe how an enterprise architecture discipline might be more optimally structured. Before I do, here’s an apt analogy that might provide perspective. Consider the Agile roles of product owner and of scrum master. Like the product owner, the business architect is looking outward at the business through the lens of the customer whilst the scrum master, like the enterprise architect, is looking inward at the technology. Of course the business architect cares about the technology, and the solution architect cares about the business and the customer, but when push comes to shove and there’s a decision between meeting a customer promise and a delivery issue, you’ll see how true allegiance is aligned.
Now, let’s regard my recommendation on how an enterprise architecture group should be structured. Visuals are available on BarcVox.com, but I’ll try to describe this in words for those without access. You may also want to check out my segment on Defining Enterprise Business Architecture.
First, let’s lay out the components of a typical enterprise architecture with a constituent business architecture function. Obviously, we have business architecture. At the very least, whether explicitly or implicitly, we should also have architecture disciplines for information, data, applications, and infrastructure. Some organisations attempt to coalesce or blend these non-business architecture functions into a solutions architecture wrapper, which is fine. It’s a good idea to think about a cascading structure with business architecture at the top. Business architecture drives information architecture, which prescribes the data architecture, which is transported by application architecture and supported by a foundation of infrastructure architecture.
Now, let’s see how these constituent components are situated in an organisation. As it’s the most typical origin story, let’s start with the technology elements—the functions where I have no disagreement with the implementation.
Remember, all of this is encompassed in an enterprise architecture frame. It’s all one big happy family. Perhaps we’ll consider it to be a marriage. One partner is the solution architecture, sometimes referred to as technical architecture. Unequivocally, their family has as its members, data architects, application architects, and infrastructure architects. So far, so good. The other partner is, you guessed it, business architecture. It’s a marriage made in heaven. Right?
Not quite. We’ve got a contested member—information—, and information architecture. This is often situated on the technology side of the house, I’m going to argue that this is not quite right. Whilst the information systems, whether data or infrastructure, fall clearly on the technology side of the equation, the information itself should be owned and managed by the business. It’s their data. And they should have a say in the taxonomy, structure, and governance of the data. And, although this function requires specific expertise, it is decidedly not a technology function. On the other hand, data and master data management functions should be operated by technologists.
If you follow along on BarcVox.com, I’ve shared a chart that illustrates this next part.
I’m not finished yet. If you look at the images, you’ll notice that I’ve coloured business architecture orange and technical architecture green. This is more than just a nod to domain placement. What I am saying is that the business architecture function, in orange, should be owned by the business, and technical architecture, in green, should be owned by technology. As I stated at the top of this segment, it’s not enough to embed business and information architecture on the tech side of the house.
Now we’re in a place that I can circle back to the conversation I mentioned at the top of the segment. For listeners, there are illustrations on BarcVox that should help to follow along.
There are two structures represented by coloured boxes joined by lines to show relationships. The box colours represent whether the position is considered to be a function of the business, of technology, or some unknown indeterminate value.
On the left is the organisation the global enterprise architect shared with me. The organisational reporting structure extends from the CEO at the top, to a CIO, to a CTO, to the Enterprise Architecture Function, into which reports the solutions and business architecture functions. In this structure, the CEO is the only unambiguous business function. The CIO function is indeterminate. I don’t know what the intent of this CIO role is for the organisation, but in hearing him speak publicly, I would bet that his background is as a technologist. The remaining functions are necessarily technological, as they report up to the CTO.
On the right, I illustrate another possibility. I’ve retained the same functional boxes, but I’ve rearranged them and reassigned ownership. At the top, the CEO remains as before, with a focus on the business. The CIO, on the other hand, is now squarely defined as a business functionary. Under the CIO is the CTO, under which is the solutions architecture function.
I am not recommending this reporting structure of the CTO reporting to the CIO, but I am trying to work with the hand I’ve been dealt. There are many business reasons why the CTO might not report directly to the CEO, so I am not taking a particular position either way on this one. I’ve got no horse in this race. As a reporting structure however, enterprise architecture is a business function reporting to the CIO, which is itself a business function. And business architecture reports up to enterprise architecture as a business function. The relationship between the solutions architects and the business architects is an ordered pair. They are yin and yang. Together they comprise the whole.
I’ve only described the reporting hierarchy. I am not going to get into how the operating model works or how the organisation is matrixed. If anything, that’s a topic for another segment.
Let’s say you are in an organisation that, for whatever reason, won’t allow these business functions to reside on the business side of the house. What can you do to increase the odds, maybe even enough to tip the odds into your favour?
If you are in this situation, I suggest positioning yourself to operate as an internal consultant. You’ll still be challenged with the same problems an external consultancy has, which are promotion and success. Perhaps the biggest challenge apart from the trust and relationship-building aspects are the longer lifecycles of architectural designs. In the product space, one can add a new feature that can demonstrate value in a matter of days. Architects don’t have this luxury. So if you are a ‘them’ and not an ‘us’, you’ve still got an upward journey.
This translates into a lot of relationship-building, education, and roadshows. It requires allies and champions. And in any case, it requires an organisation that values the long view.
Every journey starts with the first step. Even if you’re already on a journey, your next step can be a step in a new direction. Let’s embark.