As a profession, Business Architects are in danger of becoming defined by just one of the products that they create. Unfortunately, it reduces the value that the profession can provide to organisations and limits expectations of prospects and clients.

What went wrong?

Imagine a fine-dining chef who makes tacos once at the request of a favourite customer. The chef knows tacos will do the job, she knows they’re sustenance, she knows that there are better products and even advises the customer of what she can do instead. But the customer wants tacos, so she delivers.

Other people like tacos as well. So she becomes known as a taco chef and the world is left short one fine-dining chef. Or rather, she’s no longer unavailable to provide the fine-dining experience since she’s now cooking tacos at the request of many customers. She knows she can do more and tries to prompt customers through educating them of other ideas and concepts. But the tacos are pleasing the short-termism of the current customers. It keeps them fed for an hour until they start to feel hungry again. She’s diligent and adds as much nutrition in them as she can. She listens to each customer, understands their needs and can plan a superb meal that will keep them well-nourished for hours. But the customers want tacos and end up hungry again in a hour or so.

The tacos could be cooked by someone on a lower salary. But they may not have her knowledge of nutrition and attention to detail. So yes, they’d still be tacos but not tacos of the quality that she’s been producing.

That’s our taco

And that taco situation is what I see with Business Architects. We’re commonly requested to perform a documentation task, e.g. “document the current business”. It’s usually followed by “so that we can …..”. Look on any job boards for contract Business Architects and you’ll see the activities we’re requested to perform. It’s usually the pattern described above of “document the current business”. Roles for permanent Business Architects are usually wider since clients don’t want professional expertise for just 6 months; they’re thinking longer-term.

The contract clients request knowledge or even certification of TOGAF or Zachman, but you don’t need knowledge of those to be able to document the business.

They may want specific knowledge of their industry sector (e.g. SOX and MiFID II for finance) and they may want experience with specific tools. But if the role requires a Business Architect, then documentation will be the activity.

They may even want knowledge about Business Architecture offerings specific to their industry sector (e.g. MODAF or ETOM). That last element can assist with documentation, especially if there are reusable models in the sector-specific offering.

But in the end, the client is asking for someone to document their current business. There’s often little thought for what to do with the documentation once it’s been produced. Some clients think ahead to wanting a future model, but don’t give much thought as to what to do with the gaps between current and future or how to evaluate benefits of different future models.

That’s our taco. Documenting the current business is the Taco of Business Architecture.

How did we get here?

Let’s take a look at some of the definitions for Business Architecture and then do the same for Enterprise Architecture. We would expect them to be similar, with Business Architecture being more focussed on the business domain.

Business Architecture Definitions

• wikipedia: “a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands”
• OMG: “defines the structure of the enterprise in terms of its governance structure, business processes, and business information.”
• The BA Institute – “defines the enterprise value streams and their relationships to all external entities, other enterprise value streams, and the events that trigger instantiation.”

The common theme in these is that Business Architecture is referred to by the deliverable or product that it creates. It’s output is the definition of the enterprise business.

Whereas I’d see Business Architecture as an activity. I’d expect to see more relating to its purpose, what it does and why it does it.

Interestingly, TOGAF (also by OMG) describes the context of the first few steps of the ADM with:

• “a knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.).”

TOGAF, in the paragraph above, implies Business Architecture as an activity.

Enterprise Architecture Definitions

Let’s look at definitions for Enterprise Architecture and see if they exhibit the same characteristics.

• Wikipedia defines EA as “a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy”
• MIT CISR defines EA as “the organizing logic for business process and IT capabilities reflecting the integration and standardization requirements of the firm’s operating model.” Jeanne W. Ross, Peter Weill, David C. Robertson
• Gartner defines EA”is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes”
• Enterprise Architect Body of Knowledges defines EA as “analyzes areas of common activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and technology”

Here we see words such as discipline, practice, logic, guide. There’s a mix of nouns and verbs in that list, but they all indicate activity, for instance, you’d only have a discipline if you were to produce something.

We seem to have lost that concept with the Business Architecture definitions, although the TOGAF ADM excerpt does imply that Business Architect involves activity.

The Tao of Business Architecture

I’m going to approach this from a different direction and simplify the concept.

1. Business Architecture assists strategy

Strategy from the heart

Business Architecture only exists because of strategy. Without strategy, Business Architecture has no purpose, no reason for being. We would just be producing documents for the sake of producing documents. Either those documents have to be useful or the process of creating the documents has to be useful, otherwise Business Architecture is a waste in any organisation.

Business Architecture relates to how that strategy is developed and maintained, how that strategy is implemented, how different strategies are evaluated and indeed, even the documentation of current strategy.

Business Architecture assists strategy, and paraphrasing from Rumelt (Good Strategy, Bad Strategy):

A good strategy includes 3 parts:

1. A description of the current landscape and challenges
2. A description of the future target that can respond to those challenges
3. A plan to get you to that future

For Business Architecture (and also Enterprise Architecture), those concepts make a lot of sense and can be interpreted as:

• A description of the current architecture. In this case business architecture, specifically the BMM, organisation units, influencers, partners, governance, etc
• A description of the future target. In this case, the goals, outcomes, changes to capabilities, future organisation units
• A plan to get you to that future. In this case, the change programme and work packages (most likely later supported by programme and project plans).

Here is the crux. Business Architecture is not only those documents, but it is the activity involved in producing those documents. There is more value in a Business Architect assisting an organisation in defining their strategy, challenging, providing other options, providing analyses, etc than there is in the delivered documents. It is the analysis and the progression of the conversation and the development of knowledge within the enterprise that is of most value. For some clients, the future state doesn’t need to be written down at the end of the assignment because the organisation has developed to the point that all know the common direction. The direction has become subsumed into organisational knowledge and culture. That’s not common, but the fact that it can happen, indicates that we’ve assigned value to the wrong part of the contract.

2. Business Architecture assists the enterprise

Enterprise

When I read the EA definition earlier from the Enterprise Architecture Body of Knowledge, I found that it described Business Architecture with one element missing:

“analyzes areas of common activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and the use of technology”

The simple addition of “the use of” alters the definition to be suitable for Business Architecture. I also like the focus on “future states” rather than current.

3. Business Architecture assists goals

Directions

This is fundamental for me. When I’m explaining to people what I do, I avoid phrases such as “I architect businesses” in the same way that a programme manager may say that “I manage programmes”. Instead I simplify for the layperson and say that:

“I help organisations do what they want to achieve”

and often the first step of that is

“assisting the organisation’s executive define what it wants to achieve.”

From my perspective, the majority of large issues within organisations stem from a lack of alignment. I find that larger organisations evolve to a state of disparate, loosely connected governance models that are not aligned with a central set of themes (or goals in this case). I work to align an enterprise so that it can focus resources on what it want to achieve, briefly (or as briefly as is reasonable) documenting where it is now, developing the future vision and then assisting the executive in steering the company towards that vision.

In short, it boils down to: “What direction do you want to go in? Then let’s define what we need to do to get you there.”

Summary

Business Architects need to retake the definition of the profession, in order to move clients and prospects from the Taco of Business Architecture to the Tao of Business Architecture.

This should be done with a focus on Strategy, Enterprise and Alignment and a lesser focus on documentation for the sake of documentation.