"Even though they (and we) may not know it, all organizations already have an embryonic business architecture in place. But today’s problems require a more formal business architecture to connect the business with the technologies it increasingly depends on."

Another Level of Bureaucracy

In an increasingly hypercompetitive world, where bottom-up collaboration and high-speed mashups are the order of the day, business architecture is just one more set of hoops to jump through. If organizations implement business architecture, they’ll only slow down the process of real-time systems building.

The Missing Link

Business architecture provides structure to the communication between business planning and technology planning. In the 21st century, where end-to-end business processes and IT are necessary components in the execution of nearly all major business strategies, business architecture provides an essential framework for tying the two together..

Opening Statement

"Architecture is a verb, not a noun."

-- Anonymous

Business architecture (BA) is on something of a roll. Those of us involved in business architecture over the last few years have noticed increasing curiosity on the subject from both the business and the technology sides of large enterprises. This has been demonstrated by the number of people attending BA conferences and, here at Cutter Consortium, by a growing interest in business architecture among our readers and contributors. This edition of Cutter IT Journal is a reflection of that interest. Included here are articles by some of the leading thinkers and practitioners in the field, dealing with a number of different facets of business architecture.

One of the questions that you have to ask yourself when a new domain like business architecture catches fire is why? Why are business and technology managers around the world suddenly showing an interest in business architecture? Why have there been a large number of articles in the trade press about all the other elements of enterprise architecture (data architecture, application architecture, technology architecture, etc.) and so few articles about business architecture? In this issue, we hope to address some of these questions.

Personally, I suspect that there are lots of reasons for this somewhat schizophrenic behavior (i.e., the increased interest in business architecture on the one hand, and the relative lack of published literature on the other), but here are a few possible causes:

1. The growing importance of technology in the execution of business strategies and plans. Organizations everywhere are going global and digital and interconnected, and you can't make these things happen without good IT infrastructure and systems.

2. The ever-tighter linkage between business competition and technology. The business and technology worlds are moving faster and faster, and it is vitally important that an enterprise's technology base be able to react to these competitive forces.

3. The increased importance of business process in business strategy. More and more, businesses are focusing on streamlining their business processes, and therefore business process modeling, business process analysis, and business process reengineering have to work hand in hand with IT.

4. The electronic linkage between enterprises. Enterprises are recognizing more and more that their key business processes do not begin or end within their organizations. Supply chain management stretches from producers, to vendors, to the enterprise, to the customer, and ultimately to the consumer. Electronics and the Internet are changing how all this works.

5. There aren't a lot of BA "translators." To make items 1-4 work, there needs to be at least a small group of people in the organization (or available to the organization) that speak both "biz-speak" and "tech-speak."

6. The lack of BA translators has limited the research and publication on the subject. Being a good BA translator involves knowing a lot (enough to be dangerous) about business, "the business," and technology.

7. The BA function doesn't fit neatly into traditional organization charts. There are cases for business architecture fitting within the enterprise architecture group under IT or reporting at a strategic level to the business. This often makes business architecture an organizational orphan.

So what we have here is something of a perfect (organizational) storm. Organizations have a need for business architects who can help them understand how technology can support business goals and strategies (alignment), and they also need business architects who can explain the opportunities that the organization can exploit by using the latest technology (innovation).

But even though they (and we) may not know it, all organizations already have an embryonic business architecture in place. Historically, this informal business architecture was found in mission statements, strategic plans, organization charts, job descriptions, product bills of material, the financial chart of accounts, and accounting principles, among other things. Indeed, every time a new high-level consulting project gets started, these basic components are dusted off and presented as the business architecture. But today's problems require a more formal business architecture to connect the business with the technologies it increasingly depends on.

No doubt these are some of the reasons that business architecture is beginning to capture a bigger mindshare in enterprises around the world. The articles in this month's Cutter IT Journal touch on many of the most important BA issues, including where business architecture should be located in the organization.

IN THIS ISSUE

In journalism, you are taught early that there are six fundamental questions that need to be answered by a good news report: who, what, when, where, why, and how? I believe that these questions refer to the fundamental semantic categories that exist in the world. Every good story has all, or most, of these elements. So, too, does every business architecture. As an overview, this Cutter IT Journal breaks down roughly into three major sections:

1. The first two articles, by Cutter EA Practice Director Mike Rosen and Neal McWhorter, are mostly about whys and whats. Rosen leads off with a discussion of the Business Motivational Model developed by the Business Rules Group and the OMG, focusing on "ends" and "means." McWhorter covers some of the same ground with a focus on "motivational," "analytical," and "operational" concerns.

2. The second two articles, by Ralph Whittle and Geoff Balmes, deal somewhat more with the how. Whittle sees business architecture from a high-level business process standpoint. His take on business architecture focuses on getting management to understand clearly what the major end-to-end business processes ("value streams") are and how process integration provides a strong foundation for business success. Balmes focuses on a collaborative framework for business architecture. His approach involves a more detailed understanding of how to fit business architecture within strategic planning, business planning, and business management.

3. Our last three articles, by Greg Suddreth, Jeff Dols, and Cutter Senior Consultant William Ulrich, deal with the questions of who, where, and how: Who makes a good business architect? (Suddreth); Where should business architecture fit within the organization? (Dols); and How should the governance of business architecture work? (Ulrich).

While it isn't possible to cover all the areas of business architecture in detail in a survey like this, I think there is plenty of food for thought for anyone charged with setting up a BA program in a large organization.

HAVE WE GOT A DEFINITION YET?

One of the things you won't find in this issue is a single, universally agreed-upon definition of what business architecture is. I suspect that people who have a strong need for structure will find that a problem. That said, I believe the absence of a standard definition is actually a good thing, and something that often happens during the early days of a new discipline. My experience at such times is that the search for a clear definition is a useful activity, while settling on the wrong definition can lead to a great deal of wasted effort.

Consider the following example: At the beginning of the US space program, there were many problems that had to be solved with regard to manned space flight, but by far the most important was how to get the astronauts back safe and sound. One of the root problems with getting back was the tremendous friction (and heat) that occurred when a space capsule reentered Earth's atmosphere. Millions of dollars were spent trying to find a material that would not burn up upon reentry, but attempt after attempt at solving this problem failed. Finally, someone suggested that perhaps the scientists and engineers were defining the problem incorrectly. After some serious soul searching, NASA concluded that what was needed was not a material that would not burn up upon reentry, but rather a material that would burn up at a slow enough rate that it could still provide protection during the short period of intense heat during the descent. Defining the problem in the wrong way had hampered development.

The same principle holds true in the rush to define business architecture. The space between the business side and the technology side of an enterprise is filled with a lot of things. Figuring out which ones need to be called "business architecture" is an ongoing process.

Today there are pleas for a shared definition of business architecture. Managers, researchers, and practitioners alike all want some kind of common framework. However, I've found in over three decades of IT experience that getting to a definition, like NASA's search for the indestructible nose cone material, is often an evolutionary process in which pieces of the definition are developed as different projects are executed.

As you will see in the articles in this issue, different writers have different definitions of what business architecture is. No problem -- they are all informative, if not totally exhaustive. As I've said, this is common in the early stages of a new discipline. It was true of object-oriented design, it was true of data warehousing, and it is currently true of service-oriented architecture. Working out a good definition is likely to take some years, but that's OK, as even provisional definitions are useful for framing the area we call business architecture.

Finally, there is one component to business architecture that I don't see being worked on here; namely, product architecture. Over time, I think that both business and IT management are going to see the need for IT architecture to support product architecture as a way to foster increased business agility. Suppose we could convince the business folks to engage in some future-looking product planning, asking themselves such questions as:

• What kinds of markets do we see four to five years out?
  
  
• What kinds of products will we be delivering three to four years out?
  
  
• Then what kinds of systems will we need two to three years out?
  
  

If we can get the businesspeople to think along these lines, then perhaps we IT folks can get involved earlier in the product cycle, looking ahead to the changes that will be needed in our IT systems rather than getting surprised by some business development that has been underway for a couple of years. There is an approach called "technology roadmapping" that was developed at Motorola in the 1970s. It is widely used in high-tech businesses and has the virtue of getting the business and technology folks talking about the future while there is still a chance to influence it.

WHERE IS BUSINESS ARCHITECTURE GOING?

It is pretty clear that business architecture is just getting started. It is also clear that it is vitally important. Business architecture is the place where major business strategies intersect with major technology solutions. The articles in this issue point to the principal ways in which business architecture is moving today. We hope this edition of Cutter IT Journal will help you plot the best BA course for your own organization.

ABOUT THE AUTHOR