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.

Posted by Randy Heffner