Business Architecture is Management Support

It's common to read that "management support is critical to business architecture success" and to hear from business architects that "business architecture isn't working because management doesn't support it." I've said that too -- it seems to be a theme in new architecture programs.

Let's step back for a moment and ask: if management is not supporting business architecture, what exactly is this magical value that business architecture believes it offers, but that management won't support?

And even more fundamentally than the value proposition: does business architecture know who its real customer is?

Here's my hypothesis: the primary customer of business architecture is management. Therefore the question is not: "does management support business architecture?" The question is: "how does business architecture support management?"

By "support management," more specifically I mean that business architecture:

• Helps management understand the existing business and its environment
• Helps management define its vision and goals
• Help management think through problems with new methods and viewpoints
• Helps management execute on its vision and goals by extending the reach of management into activities that existing managers don't have the bandwidth to lead

In this work, the scope, vision, goals, and all the major decisions are management's. The enterprise isn't executing the vision of business architecture; it's executing the vision of management. Architecture supports management.

(It's a bit presumptuous of me, but I'll suggest for a moment that this view is broadly valid for other architecture domains: enterprise architects support management in achieving enterprise alignment; data architects support management in defining and executing a sound data strategy; solution architects support management in obtaining sustainable solutions; and so forth.)

Business architects are, after all, "architects," a job title cribbed from a much older profession. If you were an architect of houses, your fondest wish might be to build a shining white Modernist cube on a cliff overlooking the sea. But if what your client wants and can afford is to renovate a suburban bungalow, and you accept that contract, then your mission is to enable the most outstanding bungalow renovation there ever was. Get on it.

BUT. But. If it's that simple, why is it so hard in practice? And also: doesn't the architect (of any kind) have a professional responsibility and an opportunity to improve the outcome? To "educate" the client, as we like to call it?

In my observation it's very common to find a significant gap in expectations between what management thinks it's getting from architecture, and what architects think they are providing. People are generally surprised and frustrated by this, since it seems logical that if management charged an architecture program, it should be able to "support" what the program does.

Not so! There are plenty of reasons for a gap in expectations. Here are a few I've experienced:

• Managing a significant size enterprise isn't deterministic; management has to try things out. The architecture program was formed as an experiment, without management really knowing exactly what it would do. (As is management's perfect right.)
• The architects think they have some kind of mandate to create governance processes or enforce decisions. Management thinks it hasn't delegated anything -- and somehow they just haven't talked about it. (Yes, that can happen. Easily.)
• Management believes that architecture brings a set of practices that will, somehow, create alignment and "standardization" that management in the past has never been able to achieve. (Hmm.)
• The architects (and maybe even management) believe that describing the business architecture and its challenges and opportunities clearly enough will, somehow, result in change. (Sorry, no. Insight surfaces opportunities to lead; leadership is what results in change.)
• The architects think they are "partners" with management. Management thinks no such thing. (Ok, maybe after years of collaboration.)
• The architects, now frustrated with the lack of "support," have started to manage "bottom up" with their own grassroots efforts at coalition-building. Management feels subverted. (Who wouldn't?)

Based on those real-life observations, I'll venture a further hypothesis: given the complexity of the enterprise, of the work of management, and of the work of architecture, a mismatch in expectations between management and architecture is more likely than not.

Luckily, as architects, we know how to deal with this, right? We're analysts and designers and facilitators. We can try out a customer-centric approach to business architecture, with management as the customer. [1]

What are some things we might do as customer-centric architects?

• Listen to our customer's needs. Then look closely at the environment to find out even more about their real needs.
• Ask our customer: How can I help you? What do you suggest as the best way to do this? What have you tried before, and how did that work?
• Clearly understand the operating model of the enterprise. What kind of authority does management actually have to back up its goals for architecture? What is an appropriate architectural approach based on that reality?
• Build on existing initiatives or changes that already have hard-won management support, instead of just proposing new architectural initiatives.
• Be politically savvy -- find ways that management can "support" business architecture informally, without burning through political capital.
• Think like a coach -- identify where you can help managers be more effective in their own work, before layering on architectural work.

If nothing else, these actions will let your management know that you understand the challenges they face and sincerely want to support them. They might just also improve the quality of architecture deliverables by matching them more closely to the realities of the enterprise. I'm giving it a try, at any rate.

Notes:

[1] I acknowledge, by the way, that in the course of their work, architects may have other additional customers -- for example, the stakeholders in a project team the architect is part of. I'm just arguing that we be sure our work is anchored back to our primary customer.