Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

Taking a Careful Slice – Defining Business Architecture

Taking a Careful Slice – Defining Business Architecture

Rate This
  • Comments 16

I’m putting together my presentations for TechEd New Zealand, one of which is titled “Business Architecture for Non Architects.”  In that presentation, I need to provide a good, SHORT, definition of business architecture.  So, like a good soldier, I marched over to the Business Architecture Guild and dug in to the Business Architecture Body of Knowledge (the “BizBOK”), which defines Business Architect in this way.

“A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands”
– Business Architecture Body of Knowledge Handbook 2.1, Business Architecture Guild

I copied this definition into my deck and went on.  Then, as I came back and practiced the presentation, I hit this slide and realized, to my horror, that I do not think this is a very good definition.  Why?  Because of the problem of two parallel phrases: business architecture, and business architect.

Is the business architect responsible for describing the business architecture?

Here’s the problem with the BizBOK definition...  The field of Enterprise Architecture clearly includes four domains: business architecture being one of them.  Enterprise Architecture is accountable for creating a complete description of the enterprise, useful for many things.  One of those things is for the alignment of strategic objectives and tactical demands.  Therefore, to use the “model, viewpoint, view” language of the ISO 42010 standard definition of architecture, we would say

    • Model == Enterprise Architecture
    • Viewpoint == Concerns of Business Stakeholders
    • View == Business oriented architectural artifacts


Therefore, the “blueprint of the enterprise,” is the Enterprise Architecture.  There is no distinction between the “architecture of the enterprise” and the “blueprint of the enterprise.”  These concepts are identical.

Who creates the Enterprise Architecture?  All of the domains do.  Business Architects contribute, but so do Information Architects, Application or Solution Architects, and Technology Architects.  Non architects contribute as well, including process engineers, sales managers, product managers, relationship managers, and others.  A few business architects are involved.  In most organizations I’ve had contact with, business architects do not lead the effort to create the enterprise architecture. 

Conclusion: the BizBOK 2.1 defines the concept of “business architecture” in terms of an artifact that business architects do not create!  That seems a bit exuberant.  It’s a little like saying that “bricklaying is the act of building a house out of bricks.”  Um… no it isn’t. 

What is the role of the business architect?

A Business Architect is one of the four well-defined “domain” architects under Enterprise Architecture.  The other three are: Information Architect, Solution or Application Architect, and Technology Architect.  These different domains are supposed to represent “layers” in an outdated model.  While I reject the entire notion of “layers” or “tiers,” I understand that these terms have become embedded in business over the last two decades.

I’m on the fence about the value of even employing “domain-specific” architects, especially in smaller firms or at the program level.  I believe that, in many cases, a good generalist Enterprise Architect is probably the most effective use of resources and training.  That said, I understand that many large organizations have created specializations around each of the domains, with some folks being “Information Architects” only, and others as “Business Architects.”  I even wrote a job description of a business architect a number of years back that proves popular today.

That said, as we define the “activity” of business architecture, I believe we should remain clear that business architecture is an application of enterprise architecture… a careful slice of general EA skills with a focus on meeting the needs of only one of many levels of the architecture.  That level, the business level, meets the needs of different stakeholder groups (multiple business viewpoints) like strategy development, strategic alignment, process improvement, innovation management, and organizational development.  But the business viewpoints are deeply integrated into the unified model of the enterprise, one that is not complete or effective without the viewpoints of the other domains.

The role of the business architect is therefore to develop specific architectural artifacts needed to meet the concerns of business stakeholders.  Those artifacts are derived from the model of the enterprise (the enterprise architecture) which evolves as they go.  Many experts suggest (and I agree) that it does not make sense to develop the EA model as a standalone artifact, but rather to develop the parts of it that are needed to meet immediate concerns, use the model to meet those concerns, and move on to the next concern, building the enterprise architecture model as you go.   This iterative approach works well and keeps enterprise architects out of the proverbial “ivory tower.”

Clearly the concerns of the business stakeholders include “aligning the strategic and tactical demands” of the enterprise.  I would not LIMIT the scope of enterprise architecture to this one concern.   This is the other problem I have with the BizBOK definition… it is limited to alignment only.  Perhaps that was intentional.  I have not asked.  But it is clearly limiting.

How does that role affect the definition?

A couple of years ago, I defined Enterprise Architecture as a single term with three definitions.  (That’s pretty normal, if you think about it).  One of the definitions was “A rigorous model of the motivations, structures, information, processes, and systems of an enterprise created for the purpose of decision support.” 

[Updated 11 Sept 12] That model is the enterprise architecture.  Therefore, in order to create a non-overlapping and complementary definition for business architecture, I wanted to remove the artifact from the definition.  However, clearly some members of the community used the term "business architecture" to refer to part of that model.  So I left in the notion of an artifact, but defined it as a subset of the larger enterprise architecture artifact.   

[Updated, 5 Sept 12] I am considering two "definitions" at this time.  One is a full definition that provides the necessary and sufficient differentation needed to create a reasonable understanding of the term.  The other is a shorter definition useful in a business context. 

The definition I’m considering at this time is:

Business Architecture is

1. A specialization of the Enterprise Architecture business function that collects and manages functional, structural, and motivation-related information using a rigorous scientific and engineered approach for the purposes of business design, functional improvement, motivational alignment and decision support. [Updated, 5 Sept 12] 

 

2. A subset of the architectural description of an enterprise sufficient to produce models that meet the functional, motivational, and alignment concerns of stakeholders. [Updated 11 Sept 12]

And the short, "useful" definition is this:

Business Architecture -- A specialization of the Enterprise Architecture business function that uses science and engineering to design and implement business functional and process improvements and strategically-aligned change initiatives.  [Updated, 5 Sept 12]

There it is… a careful slice.  I look forward to your (continued) feedback. 

  • @Adam,

    It is interesting that you do not see business architecture accountable for implementation.  That may be true.  I have to think about that and bounce it off of others.  

    As far as the notion of "EA Discipline" vs. "EA Function," I'm not sure that I agree.  An EA discipline can be implemented anywhere in an organization, even outside of the model of enterprise architecture that has been adopted to actually manage and deliver the architecture of the enterprise (where it exists).

    Defining BA as part of the discipline but not part of the EA function supports the notion that business architecture is correctly defined in a way that is disassociated from the EA function.  Unfortunately, those people performing those activities apart from the EA function cannot actually do the BA job.  They are doing a different job (business analyst and/or solution architect).  The exception would be where there is NO EA FUNCTION, whereby the BA is actually peforming Enterprise Architecture.

Page 2 of 2 (16 items) 12