Confusion Abounds When Aligning Business Architects
Organizations continue to struggle when identifying the role of business architects and persist in misaligning them to IT departments. Tom Graves, an Enterprise Architect at Tetradian Consulting, pointed out the problems this causes and he challenges architects to not accept the status quo but rather, try and improve the situation.
CIO Magazine pointed out the “6 Hottest Jobs in IT” that listed “business architect” in the top spot. This raised a red flag to Graves who explained in a blog post that business architecture is not an IT job but actually a role under enterprise architecture. Graves is not alone in tackling this issue as the topic of enterprise and business architecture has lit up the LinkedIn architecture forums. For instance, the discussion Six reasons why EA should not be assigned to the IT department has over 140 comments, many of which contain disagreements about how EA and business architects should be positioned.
InfoQ reached out to Graves to find out more about the impact of this confusion and how to improve the situation.
InfoQ: Tom, in your blog post you explain that there is a problem with business architects being lumped in with IT-oriented architects. What is the result of this? Where is the (negative) impact felt?
Graves: The real impact is that if this happens, business architecture and business architects lose all credibility with the business. I'm always extremely wary of anything that looks like a 'term-hijack', where a ‘natural term’ for a domain is hijacked to describe only a subset of that domain, leaving no possible term to describe the remainder of the broader domain. The 'natural' meaning of business architecture is 'the architecture of the business' - concerns such as business models and their relation to the organization’s capabilities and resources. But in TOGAF and the like, 'business architecture' is used as a kind of random grab-bag for 'anything not IT that might affect IT' - and ignores anything that doesn't connect directly with mainstream IT. Such as anything to do with people, for or person-to-person communications, or branding, or market placement, or retail and warehouse locations, just to give a few examples.
Business architecture is the architecture of the business and obviously that's going to impact IT. Yet in reality, IT is only one relatively small part of the business - typically around three to five percent for most types of organization. And if we say that 'business architecture' is only about how IT relates with the rest of the business, we're left with nothing to describe how everything in the rest of the business relates with everything else. That's a very serious problem which quickly becomes a very serious credibility problem for IT-oriented architecture, and thence for IT itself. Not a wise move.
InfoQ: For an organization that is ramping up a (formal) enterprise architecture effort, what is your opinion of the ideal organization chart? Where should the various architectural disciplines be aligned for maximum business impact?
Graves: I often say that architecture comes down to one very simple idea: that things work better when they work together. So in organizational terms, we need to place the various architectural disciplines within the respective domains, and then make sure that they too will work together.
The first point here is that we need to be much more clear about what type of architecture is in scope, at what level of expertise, and in which domains. It'll be different for different types of organization, but most large-sized organizations will need not only the various IT-architects - infrastructure, applications, data and so on - but also security architects (with a much broader scope than just IT),process/workflow architects (often known as BPM), facilities/logistics architects (buildings and physical flows), organizational architects (org-charts and a whole lot more), business architects (business models and the like), financial architects (structuring deals, accounts and other financial structures), and a whole lot more.
These will each cover different scopes, with different levels of detail. One 'must-read' article here is 'Enterprise Architecture's Quest for Its Identity' by Len Fehskens of The Open Group. He draws important distinctions between different types of architect:
- solution architects, who work at a project level, to make sure that all parts of the solution work together (typically Zachman layer 4-5, 'Physical' to 'Detailed')
- domain architects, who make sure that everything within that domain works together across a suite of projects (typically Zachman layer 3-4, 'Logical' to 'Physical')
- enterprise-scope domain architects, who deal with the linkages between their domain and other domains (often referred to as a 'T-shaped' skillset, deep in one domain, but also some depth in others, to enable conversation across a broader range) (mostly Zachman 3 'Logical',connecting 'up' or 'down' as required)
- enterprise architects, who guide connection and coherency across the entire enterprise scope (typically Zachman 1-3, 'Conceptual' through 'Contextual' to 'Logical', but able to guide 'deep-dive' wherever required).
Note the clear distinction here between enterprise architect and business architect. Business architecture is a domain architecture, one of many throughout the organization, in this case centered on 'the business of the business'. Enterprise architecture must link across every domain, creating a balance between them such that everywhere and nowhere is 'the center'.
That schema above also indicates where we would place each type of architect in the organization chart. Solution architects are assigned to project teams; they'll move around a bit as projects are formed, develop, deliver and disband, reporting to the project lead, or perhaps higher, such as the program management office. Domain architects are often assigned to a program or portfolio, but would report to the respective organizational unit that manages that domain.
Enterprise-scope domain architects typically report to their 'parent'-domain, usually at or near executive level - enterprise IT architects report to the CIO or CTO, for example - but would also have strong and explicitly-recognized links to other domains. Enterprise architects need a true whole enterprise scope, and should ideally be attached to a strategy unit or something similar that reports directly to the executive. Placing them anywhere else (such as in IT, or finance, or whatever) could cause the overall architecture to be 'skewed' to that domain, and would typically cause more problems than it would solve: again, not a wise move.
InfoQ: While "the model is not the architecture" is a well-shared axiom, what are some of the best ways to communicate business architecture views of strategy, capabilities and processes?
Graves: To me, the best way, always, is to communicate in person, to help each person build both their own view of the shared enterprise and the parts that they themselves play within it. The architects also need to demonstrate in those conversations that they are there to learn as much as to 'teach' - that it's a continual shared learning process, not a one-way broadcast of some arbitrary ivory-tower 'future state' that architects are trying to impose on everyone else.
Obviously there will be practical difficulties about person-to-person, especially in a large distributed organization, but that's the ideal we should always aim for. That's where the models and diagrams come in, to help fill that communication-gap - but yes, we need always to remember that the model is not the architecture. It's the conversations and decisions that arise from out of those models that are the real architecture.
I've found three types of diagrams especially valuable for this:
- One is a "Why we do what we do" diagram; Alex Osterwalder's Business Model Canvas is a very good example of this, in a commercial context. I've seen government departments use a more vertical Results Logic Diagram, which also helps here.
- Another is a 'big-picture' overview-diagram, placing the organization and its business in a broader context: the OV-1 'Operational View' diagram in DoDAF is a good example of this.
- The other type of diagram I recommend focuses more on 'What we do' or 'How we do what we do'. This can take several different forms and goes under various names such as Functional Business Model, Capability Map or High-Level Service Model. The Capability Overview in DoDAF V2 is one example; the telecomms architecture framework eTOM is another. These can be fairly high-level (as in eTOM), though we've found that to get the best impact, these do need to go at least three levels deep.
The aim here, though, is to summarize and portray 'what the organization does' on one page - a single large sheet of paper. (See here for a Visio template and instructions on how to build a simple three-tier map of this type.) It's always about communication, about getting people to talk with each other to help things work better together. In that sense, the architecture is the conversation: a model is simply a way to get that conversation going.