The Big Mistake With Business Architecture

There’s a big mistake often made with business architecture — a very big mistake, yet a very subtle mistake. As you might expect, there are a number of mistakes one might make with business architecture, but there’s a particularly big and common one that multiplies its effect through all the others.

The mistake is this: To position business architecture as a new layer on top of your existing processes and structures for EA domains such as application architecture, information architecture, and infrastructure architecture.

Here’s the issue: The traditional way many organizations have pursued EA, it should have been called “enterprise technical architecture” — ETA. The central focus has been on the likes of technical standards and reference architectures for application implementation — i.e., on the technology — and not on the enterprise itself. In a phrase, ETA is “technology-centered,” leading us to odd behaviors like assuming it’s only natural that business users, product data, customer data, and the rest will be fractured and split across multiple applications. We put applications at the center and make the business gyrate and adapt around our siloed and broken applications.

To avoid the mistake: Business architecture is inherently business-centered (although by other mistakes we can get that wrong, too), yet as a layer on top of an ETA-like architecture program, all your good business-centered work will be transmogrified for implementation using yesterday’s grotesque, technology-centered silos. It’s “new wine in old wineskins.” Instead, the business capabilities, processes, and other structures designed into your business architecture should infuse and reshape the other architecture domains. Rather than solution reference architectures framed around technical design concepts such as applications, integration, platforms, and user interfaces, we need solution reference architectures framed around business design concepts such as user roles, transactions, processes, and capabilities. To wit: We should position our business as the design center and use technology and architecture (e.g., service-oriented architecture, business process management, business rules, many others) to make our siloed and broken applications gyrate and adapt to our business. In this way, business architecture is not simply a layer on top of the other domains, but rather a driver of their renewal and transformation.

In other words, business architecture should be the spark for a makeover from ETA to business-centered EA (BCEA). Forrester is on the case: We are building Forrester’s BCEA as a guide to what this transformation means, how a business-centered approach to EA operates, and, most importantly, how to take pragmatic steps from where you are now toward a future built around your business rather than your technology.

At Forrester’s upcoming Enterprise Architecture Forum 2012 in Las Vegas in May and in Paris in June, I’ll be leading an extended 90-minute interactive session on BCEA. With a mix of peer discussion, stand-up presentation, and practical next steps, we’ll dive into how to start and accelerate your BCEA transformation.

I'll see you there. But hey, why wait until then? Let's get started talking about this stuff now (community discussion):

  • What are the subtle (or not so subtle) ways that you see architecture done in technology-centered ways?
  • Where and how do you see architects extending their business architecture initiatives in business-centered EA directions?

P.S. Roger Martin's book, The Design of Business: Why Design Thinking is the Next Competitive Advantage (or: iTunes link) is an interesting corollary to conversations about centering on business design and optimization.


Randy, I complettely disagree


I complettely disagree with your conclusion. This kind of thinking of business versus IT is fostering the silo thinking that has first got us in the mess. Your argument was true 20 years ago but today take IT out of most business and you have no business left. Most business is today driven by technology invention, for example cost savings on the clasical business processes such as Order 2 Cash, Record 2 Report, etc. The notion to isolate business requirements and then hand them over to IT does not work any longer in 50 % of the cases at least if you are looking to seriously reduce costs (so working in a large bank that has never done any PA or ABC (as in activity based controlling) and only changes to technolgy if the external presure is getting to much does not count). The notion of an BA within the EA domains is therefore even more important so that the dialog can go forward and backward all the time (preferable across a desk) is therfore not only to be tolerated, but a sign of a healthy forward looking enterprise.

Somehow, we're not connecting

Cay - I very much appreciate your taking the time to comment. However, I'm very puzzled by your remarks. Though you say you disagree, your remarks as to why you disagree seem to agree very much with my thoughts and conclusions. We seem to be saying the same thing. Let me explain, and then perhaps you can say if you still disagree.

You are concerned about "business versus IT" silos, and it is precisely such concerns that make me want to break down silos and remove the "versus" by having "business architecture. . .infuse and reshape the other architecture domains."

Your point of "take IT out of most business and you have no business left" is precisely the insight behind why I find it necessary to create "reference architectures framed around business design concepts such as user roles, transactions, processes, and capabilities" rather than around technical design concepts.

Your point that "isolat[ing] business requirements and then hand[ing] them over to IT does not work" is precisely why I pushback against having "all your good business-centered work. . .transmogrified for implementation using. . .technology-centered silos" and suggest that "business architecture should be the spark for a makeover from ETA to. . .BCEA."

And finally, if I understand your point that "The notion of a BA within the EA domains is therefore even more important," it's why the doc at the "EA domains" link in my post positions BA as properly within the bounds of an EA practice (the linked report was originally published in 2002).

So, I believe that we actually agree. If you still do not think so, please summarize what you believe my conclusion to be, and point to specific text in my post to elaborate on where you disagree. Thank you again for starting off the discussion.

Hi Randy, Cay, Thanks for an

Hi Randy, Cay,

Thanks for an interesting discussion and raising very pertinent points.

This reminded me of a recent discussion I had with the architects I was working on an engagement. When I asked if they had the business solution design in place before embarking on the system architecture, all I got in as a response was, "Why do we need it, we have the the system architecture in place !!! "

Many a times, when we do not have the solution (business) architecture in place, the following are bound to happen:
1. Designing a system for business processes which are better to be left alone (no technical solution is required)
2. A technical solution that struggles to adapt as business' change as per the needs of the markets in which they operate
3. Lost focus on improvements that can be had from the business process realignments / changes
4. Challenges in the OCM processes and acceptance as the system would have become complex instead of simplifying the life of the user
and most importantly
5. A delivery plan that can be completely at variance from what the business was expecting

"Why do we need it?" -- D'oh!!

Thanks, Praveen. I love it. In a conversation with one client, we determined that their "business analysts" could not really talk about the business. They were instead merely "business *systems* analysts."

Regarding your point #2, two concepts to introduce are:
A. Key agility indicators, by which one might define and measure specific business requirements for agility (see
B. Change case analysis (a corollary to use cases), by which one can test how well a business design performs (in terms of agility, finances, etc) in various possible future changes in business dynamics. This would be not unlike the recent "stress testing" performed on financial institutions by the US Federal Reserve Bank (see, which I see as a specialized form of change case analysis.

BTW, I presume "OCM" = organizational change management.

Thanks again for jumping into the conversation with some great examples.



indeed I misunderstood you there.

The one area I just wanted to point out on top of starting with the Business Architecture is that since 2 years I paralell also query the CXO's on their intend (see Comanders intend for reference) of change, as the clasical Business Architecture was developed more or less from business analysis without substitution of the clasical requirements gathering (that we all know only captures half (usually even less) of the intended outcome). So nowadays I am also asking for anti goals, the level unorthodox thinking or not that they expect (like do they want drones or creative thinkers on the task) and all the other areas that make up the comanders intend.

No problem!

Hi Cay - no problem at all! Glad we got it cleared up.

I like the "anti-goals" thing. Could be very useful, especially when it tests hidden assumptions and outdated ideas about what is important.

thanks again!

Big Mistake

Hi there, I'm sorry, but I think Randy is stating the obvious as if it's a big new breakthrough insight. Surely it's a basic, axiomatic tenet of EA that the business architecture drives the IT architecture. I'm not suggesting that what Randy is describing never happens, and I agree that there are too many EA initiatives that are technology-focussed, however my experience suggests that most EAs do "get it" that the business architecture drives the technology architecture.

My point goes far beyond the axiom

Dave - thank you for the pushback. I welcome it. Clarity as to the key point I'm making is both difficult and critical. The brevity of your reply makes it hard for me to be fully confident that I can correctly interpret how you are understanding my post, but, let me do the best I can, reacting to the words "on the page" as it were.

In your reply, two phrases seem to most indicate how you understood my post and, if I'm correct in how I read these phrases, the point I'm making goes signficantly further than the thrust of your reply. The two phrases are "axiomatic tenet of EA that the business architecture drives the IT architecture" and "too many EA initiatives that are technology-focused."

Based on these phrases, you conclude that "business architecture drives the technology architecture." This conclusion, while quite true, appropriate, and indeed axiomatic, is too vague and high level for today's realities (and especially for realities of the future). While it makes clear that the *content* of the technology architecture is dependent on business architecture (i.e., "content" = the business requirements the to-be-delivered solutions/architecture must account for), it leaves open the possibility that business architecture is merely a better way of deriving business requirements that are then implemented using the same kinds of solution structures as before (i.e., the possibility that BA does not radically change the *structure* and *key design tenets* of the technology architecture). Specifically in relation to my post, it leaves open the possibility that technology architectures remain built around application-centered technology building blocks (e.g., siloed applications, integration connections, individual siloed technologies). In my experience talking with those doing business architecture, this possibility is quite often the reality: Business architecture improves the content of technology architecture, but it does not much affect its structure.

To recognize the realities of digital business in the 21st-century (e.g., it is unwise to separate business and technology design; the need for business agility), our solution and technology architectures must be radically recast with business design tenets and business building blocks at the center (e.g., user roles, transactions, processes, etc.). IOW, we must radically rethink solution architecture to allow business design decisions to be directly embodied as artifacts in our business implementations. BPM process specs, SOA business services (e.g., a "submit order" service), business rules, and other design constructs are a good start in this direction, but more is both needed and possible (and these, BTW, can be corrupted into tech-centric assets).

Said another way, it is indeed axiomatic that EA (indeed all of IT) should be driven by the business and not derailed into a tech-for-tech's sake mode, but it is *not* axiomatic that being "driven by the business" leads to solution architecture structures, design tenets, and modularity that directly embody business design decisions and that tend to change in the same ways that businesses change. That is what my post is driving at when I say that business architecture should be not just "a new layer" of architecture, but rather it "should infuse and reshape the other architecture domains" -- that is, it should drive not only their content, but also a business-centered renewal at the very core of their structure and their design tenets.

BIG Mistake

Thanks for the thoughtful reply, Randy. I read it several times and I think/hope(?) I see what you are driving at.

I think that to suggest that EAs are making a big mistake is a perhaps bit of hyperbole, because the vast majority of EAs live with two undeniable realities:

1) The typical organization has the usual mishmash of legacy systems strung together wirh baling wire to give the appearance of integration. There are very few green field situations. The role of the Business Architecture then, is to help plot a course forward towards a Target Technology Architecture that, over time, progressively replaces this mess but will also for some time to come, incorporate many parts of it. A favourite phrase of mine is that the Target Architecture intrinsically results from compromizes and tradeoffs.

2) The business solutions are not going to be written from scratch. Application software is purchased and so while one might prefer a world in which your vision that the Business Architecture "should infuse and reshape the other architecture domains", that world does not exist for the majority of EAs and won't until software vendors enable it. Right now the Enterprise Architect therefore, uses the Business Architecture to derive a relatively unconstrained Technology Reference Architecture, which in turn informs the Technology Target Architecture that, inevitably, uses the materials to hand: legacy systems and purchased applications (compromizes and tradeoffs once again).

This being the reality of the Enterprise Architect's current life, I think it's a bit harsh to suggest that they are all making a "big mistake". What would you have them do instead - right now? Can you give an example?

One other comment/question: I'm still puzzled by your comment that the "business architecture should be not just "a new layer" of architecture". The inference is that you perceive that Business Architecture is "new". For many years it has surely been axiomatic that the Business Architecture is where any EA initiative begins? That hardly makes it new, surely?


Dave M

I hold to my call of a "big mistake"

Dave - We're on the same page; we strongly agree. And, I hold by my claim of a "big mistake" and that it is not hyperbole.

Before I put the pieces together, let me address your question re: biz arch as new. I agree it is not new to the industry: My 2002 report, "The Pillars of Enterprise Architecture Terminology" (updated in 2010) called out business architecture as a key EA domain. Yet, over the past 4 years or so, BA has had a significant uptake and expansion in the industry, making it new to many as a formal discipline. I used the phrase "new layer" to recognize this and also to emphasize the distinction between BA and the other (call them "dependent") EA domains.

You are spot on with the two realities you call out. Recognizing this, my focus is firstly on the architecture that guides decision-making, and secondly on the implementation decisions themselves (hence my use of the term "solution *reference* architecture"). A proper part of using a target architecture is to make business decisions as to how much movement toward the target is appropriate to accomplish on any given implementation. What I'm calling out as the big mistake is to start into BA (or keep on doing BA) without recasting the target architecture in the ways I describe. Conversely, it would be a big mistake to adhere religiously to the recast target architecture regardless of the realities you call out.

These considerations are covered in more detail in one of the reports I reference at the tail end of the blog post -- and then further developed in two follow-on reports referenced by that one (The link *should* be titled "The Future Of Solution Architecture: Six Business Design Focal Points" -- the link works but, unfortunately, our blog system failed me and displayed it as "Document 59048 not found"). Key excerpts from this report include:

* "Forrester does not advocate a wholesale conversion or replacement of all of your existing applications; instead, we see the focal points as a business design overlay on top of your existing applications — a design you evolve toward as you perform ongoing business improvement projects that touch each application."

* "One thing you don't do: Don't attempt a full and immediate cutover to Forrester's Business Capability Architecture and the six focal points."

* "When considering alternatives for a bought or outsourced application, examine their architectures and place an architectural business value on each alternative's ability to fit [or not] as a clean puzzle piece into your business capability implementations" (i.e., business value may direct the decision toward getting the app *even though* it does not match the architecture).

Beyond recasting solution reference architectures using business design focal points, what would I have EA do now? The report describes five key steps:

1. Use the focal points to more clearly understand your business.
2. Map existing assets to your capabilities and to the focal points.
3. Use individual focal points of the solution architecture to insulate your business from application silos.
4. Fold the focal points into your solution architectures and patterns.
5. Build the focal points into your architecture governance (as decision models, not religious rules).

A strong, governed focus on business transactions (i.e., defined the way a business person would think about "submit order" or what have you) implemented as SOA business services is a concrete example of a business design focal point mirrored in solution architecture.

It's a evolutionary process, driven by business value decisions, but the evolution won't even get started if you don't recast your target architecture, which makes it a big mistake not to do so.