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 19

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. 

  • 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

  • @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?

  • 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?

  • Nick:

    As always your work is an improvement of the actual status. I am also not so happy explaining that the BArchitectURE is (about) a blueprint. Maybe it is the difference betweer the BA-URE as a deliverable and as a business capability/initiative/responsibility/Org unit... ambiguous definition.

    Only few comments not 100% exactly or completely analyzed by myself:

    1. I am not sure if Business Architecture can not exist if Enterprise Architecture is not there (the same with IT Archiítecture). Saying that it is a specialization of EA is in my mind always a secondary message, but I believe that I have not completely clear in this (also Proecss management - being part of the business architecture could exist and be institutionalized without any BA environment in the organization). When you explain that is s a specialization of EA, you need to define what EA is ("how do you define an apple?", "as something similar to a pear"...  :o)  I propose not to have as the core definition that it is a specialization of EA.

    1.1. It shows that EA is everything  and that BA is some redundancy? It is my continuous problem: exists something in Business Archi that is not inside EA? So in case that I have EA in the company - could be all "named" EAs with BA, ITA ... specialization? Or is there something to which EA should give more focus? (Governance, principles, target Architecture(s) ...)

    2. In the first definition you have "informations" in the second "data" I believe that it is with a purpose (information for decision making, data for ... less responsiblity? :o), but I ask: has this difference an intention?, I believe that the architect provides more INFORMATION, as his added value is handling/transforming the source data/information and delivering the right information.

    3. In the 2nd definition will be good to enhance with "(agility, alingment and) CHANGES, as it is the 80-90% of the BA respponsibilities here in CZ / SK - projects and similar... so I believe that it is a critical part of the BA mission/work/services/delivery.

    4. I don't see the active part of the work of a BA (both definitions has only "collects"), no one discuss about responsibilities in the business transformation (roadmapping and managing), innovation ... I understand that it is a pandora's safe, (as on this moment the counter argument will be: "will be the BA responsible or even accountable for business? for strategies? for change? for numbers?, no BA is not!), never-the-less, collecting (and documenting) can be made by any junior  analyst or even a junior coordinator... a referent. an "expensive" architect is for that, not necessary :o). Where would be the USP of a generic architect? could be in establishing commonalities, principles, patterns, that rationalizes, improves the business model? could be in Architectonic assurance that reduces architectonic debt? (a little theoretical sentence I know ...sorry) could be: Reducing the natural business complexity? could be in (5)

    5. even the sentence(s) type ... "collecting ..." shouldn't be better to change to "visualizing...."? The difference between an analytical diagram/schema and an architectonic model is, the expert ability to visualize in the right form only the relevant information, not strictly by notation, based on strict analytical schemas/data and good enough to be readed for the necessary stakeholder (depending on the needed messages, there could be good to use UML, or UML combined with Archimate, or powerpoint cliparts or even sexy girls cliparts ...). That is in my mind one of the BA USPs...

  • 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

  • @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

  • @Erik,

    I have to think about your message before responding.  

    --- N

  • @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.

  • @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.  

  • @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.

  • @Erik:  Question 3 -- about change... very good point.  I like that.  

    Question 4: what are the higher order values?  You are not the only person to ask me that... and it is a very good point.  collecting and managing information is not the right level of activity.  My other collaborator wants to see me add "design."  I hear you asked to see a measurable value like "reduce complexity."  

    One thing that I need to do is to define the greater context of the notion of business architecture so that I can reasonably distill it down to a good definition.  You have made some very salient points, and I didn't include them.  I should have done that, and I shall.  

  • "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

  • Nick

    First, I would like to point out that you posted a blog entry about a definition that is not from the Business Architecture Guild, but was cited in the Guild’s Body of Knowledge Glossary as coming from the OMG Business Architecture SIG, an international standards organization and was based on extensive debate and vetting. The definition has been adopted by the Business Architecture Institute and the Business Architecture Society. So the Guild, the BASIG, BAI and the Society all adopted this definition with the Guild merely citing it - because it is a good definition.

    To the definition - it is not perfect but why don’t we parse it? Start with "A blueprint of the enterprise" - well it is actually a blueprint of the business, which is bigger than the enterprise and therefore bigger than enterprise architecture. Blueprints as a communication tool can represent and communicate the essence of a business and this is done all the time. The capability map, value map, organization map, information map, strategy map, cross-mappings, and other extensions of business architecture are blueprints – just like a city, a ship or a building.  

    Now on to "provides a common understanding of the organization" - I used three simple standard blueprint views today to explain to a roomful of solution, data and enterprise architects how a business worked. They knew nothing when they walked in the door.  I told them, after the hour was up, that what they just learned about that business took me a year to understand going through the build out effort with the business (not IT) team of business architects. They gained a common understanding using standard blueprints.  

    And finally on to -- " and is used to align strategic objectives and tactical demands" - this is exactly what the business architecture is used for and in the above example was used by senior executives to align every business (not IT) goal and vision for that business. The business architecture is also drive solutions forward, both strategic and tactical perspective. This is not a one off, but similar to work being done by businesses across multiple industries.

    The definition may not perfect, but it has stood the test of time for a reason. Your EA perspective trivializes business architecture, slotting it into an EA box. EA has largely become an IT domain – just look at TOGAF. So we stick business architecture in a convenient box or circle off in some dark corner of the EA world (just look at TOGAF). But this is not what business architecture is about and the definition reinforces the reality of what business architecture really delivers every day to businesses that really need it.

    Bill Ulrich

  • 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

  • @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.

Page 1 of 2 (19 items) 12