다음을 통해 공유

Taking a Careful Slice – Defining Business Architecture

  • 아티클

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

 

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.

Comments

  • Anonymous
    August 27, 2012
    After a quick read, my feedback:  you've raised excellent points and the definition that you're now considering is much improved over the original

  • Anonymous
    August 27, 2012
    @All, As I read my own "draft" defintion above, I'm struck by it's length.  It is waaaaay too long.  Please suggest shorter definitions. What about:  -- A specialization of the Enterprise Architecture business function that collects and manages business functional, structural, and strategic data to improve business readiness, agility, and alignment.   Thoughts?

  • Anonymous
    August 27, 2012
    A generalist Business Architect could work well ... one focused on the business and not the technical side.  One not focused on a specific domain but can challenge domain thinking for potential growth. Agree with your definition: "The role of the business architect is therefore to develop specific architectural artifacts needed to meet the concerns of business stakeholders.  " My question, is it only for decision support purposes? Isn't it also used to help to obtain a "at this moment in time" representative of the business to all who are part of the enterprise?

  • Anonymous
    August 27, 2012
    The comment has been removed

  • Anonymous
    August 29, 2012
    Hi Nick, I like how you get to your conclusions. What I'm trying to push is that certain aspects of the Enterprise Architecture are more related towards the business where they are accountable for creating them, as the Business and Information Architecture. Those two areas / disciplines still are part of the overall EA and need to connect to the Application, Data and Technology Architecture. Therefore I agree with the second definition you put up. The other one seems fairly hard to handle though. Benjamin

  • Anonymous
    August 30, 2012
    @Benjamin, From what I understand you saying, the business is accountable for creating some elements that the EA/BA/IA is accountable for collecting and managing, and that those elements have to be connected to the more technical aspects of architecture.  Would that be a good way to understand your statement? Let's assume that you collect the information on the "application architecture" from an IT application architect.  Who employs that person?  The business does. All of the elements of the Enterprise Architecture have business stakeholders.  Sometimes those stakeholders are employed by operational units, sometimes supporting units, sometimes product development, sometimes sales or marketing... whatever.  They are all business. That said, each element means more to one person than another.  That is the nature of functional seperation.  One person care more about data, another about process, another about products, another about segments.   They ALL have to connect.   The metamodel describes how they connect.  That is the reason for creating a metamodel... to carefully examine how things relate to one another and improve those connections to make them clear, simple, testable, and measurable. We make them connected by applying the principles of information architecture to ourselves.   Make sense? ---    Nick

  • Anonymous
    August 30, 2012
    @Erik, I have to think about your message before responding.   --- N

  • Anonymous
    August 30, 2012
    @Erik I may do seperate responses to each of your points. >>that it is a specialization of EA is in my mind always a secondary message<< is it important to describe pediatrics as a specialized form of medicine?  Yes, because by understanding medicine, there is much less to explain about pediatrics.   Look at the Wikipedia definition of the term "definition".   "A genus–differentia definition is a type of intensional definition, and it is composed by two parts: 1.a genus (or family): An existing definition that serves as a portion of the new definition; all definitions with the same genus are considered members of that genus. 2.the differentia: The portion of the new definition that is not provided by the genera. For example, consider these two definitions: a triangle: A plane figure that has 3 straight bounding sides. a quadrilateral: A plane figure that has 4 straight bounding sides." Given this (rather normal) approach, what is the genus of Business Architecture?  It is Enterprise Architecture.  Defining BA as a specialization of EA is (a) correct, and (b) meets the requirements for this type of definition. And that is why it is defined that way.

  • Anonymous
    August 30, 2012
    @Erik question 1.1, you asked >>in case that I have EA in the company - could be all "named" EAs with BA, ITA ... specialization? << How each company implements their EA program is up to them.  In practice, my team chose, on their own, to abolish distinctions and simply call everyone an EA, with some specialized in one area and some in another.  It creates an interesting readiness problem, because that left the requirement that everyone actually BECOME a full EA, even if some where not a well trained as others, but what the heck... it was their choice.  

  • Anonymous
    August 30, 2012
    @Erik Question 2: about "data" vs. "information", you asked >>I ask: has this difference an intention<< No... it was really a typo.  I should have used the word "information" both times.

  • Anonymous
    August 30, 2012
    The comment has been removed

  • Anonymous
    September 06, 2012
    "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." My two cents... I see it as a specialization of the EA business discipline not function And it uses science and engineering to design, plan & synthesize not implement Business change and strategically-aligned initiatives

  • Anonymous
    September 10, 2012
    The comment has been removed

  • Anonymous
    September 10, 2012
    Hi Bill, Thank you so much for responding.  I'll follow up with another blog post.  My response to you is simply too long to fit in the comment section. --- Nick

  • Anonymous
    September 10, 2012
    @ALL After performing an analysis on the different definitions of "business architecture" available on the web, it became clear that I could not ignore the definitions of business architecture that describe it as a "thing."  (See the blog post on 11 September 2012 for full details).  As a result, I came back and UPDATED THE DEFINITION again, this time changing the second meaning to refer to the "thing" called a business architecture. Note that I maintain that the enterprise architecture describes all aspects of an enterprise.  Since ALL businesses are enterprises, but not all enterprises are businesses (to whit: a government agency is an enterprise, but it is not a business), I cannot, in keeping with the existing meanings of those words, redefine the term business architecture as anything other than an application of enterprise architecture.   That said, Bill's point is valid.  Many if not most of the folks who have the title of "enterprise architect" are not performing ALL of the domains of "enterprise architecture."  There is a strong preponderance to perform the technical aspects but not to perform the business aspects.  Is there any wonder that folks who are meeting the needs of business stakeholders don't want to be associated with the term "enterprise architecture?" That said, let's say that I declare the definition of a throne to be: "1. A piece of furniture consisting of a seat, legs, back, and often arms, designed to accommodate one person."  You would point out that your dining room chair meets that description quite well.  In fact, that is not the definition of a throne.  It is a definition of a chair.  All thrones are chairs.  Not all chairs are thrones.   Using the definition of an entire class just to describe one member of a class is a flawed practice.  Describing business architecture as "a blueprint of an enterprise" is flawed for the same reason.

  • Anonymous
    September 10, 2012
    @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.

  • Anonymous
    October 10, 2012
    Not long ago, I attempted to create a refined definition of “business architecture.” I felt

  • Anonymous
    October 10, 2012
    Not long ago, I attempted to create a refined definition of “business architecture.” I felt

  • Anonymous
    October 10, 2012
    Not long ago, I attempted to create a refined definition of “business architecture.” I felt