Inside Architecture

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

August, 2012

Posts
  • Inside Architecture

    Taking a Careful Slice – Defining Business Architecture

    • 16 Comments

    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. 

  • Inside Architecture

    Podcast on the Enterprise Architecture profession–Interview with CIPS’s Stephen Ibaraki

    • 0 Comments

    Way back in April, I announced the first of two podcasts with the Canadian Information Processing Society.  I just realized this weekend that I had not announced the availability of the second of those podcasts.  Error corrected.

    The second podcast, once again hosted by the inimitable Stephen Ibaraki, focuses much more on the growth and progress of the Enterprise Architecture profession itself.  Specifically this podcast reflects upon:

    • The role of Business Architecture in Enterprise Architecture?
    • Does an Enterprise Architect have to be able to discuss technical issues like cloud computing?
    • How would you define Enterprise Architecture?
    • The value proposition of the Enterprise Architect?

     

    For full details, and a link to the podcast, visit the Canadian IT Manager’s Connection, a TechNet site. 

  • Inside Architecture

    The EA Metamodel behind the Business Model Generation

    • 4 Comments

    Back when Alexander Osterwalder was first working on the book “Business Model Generation,” I reached out to him to see if I could discuss the data elements he had chartered for his “Business Model Canvas.”  After all, from an Enterprise Architecture standpoint, he was making some pretty problematic assumptions, and missing some key opportunities, with respect to aligning to an established body of practice that he was probably unaware of.  The response, at the time, was basically: “I’m busy with the book… contact me later.” 

    As an author myself, I know how difficult it is to change course on core elements of your idea, and collaborate, when you are half-way done with writing a book based on a dissertation that was completed over a year before.  So, I backed off.  I figured he would publish a dry, boring book on business models, like all the other dry, boring books on business strategy, and then I could contact him to work on an update for the next edition.

    Little did I know how smart Alexander Osterwalder really is.  Boy did I underestimate this guy!  First off, he didn’t publish a dry tome on business models.   He published a very accessible and exciting book with rich graphical design.  Secondly, he involved a long list of folks, in a very public way, to contribute to the core ideas, giving him both credibility and momentum.  The result: his book has become the cornerstone of a small-but-energetic movement. 

    Alas, the core problems that he started out with, when he was first working on his Ph.D. thesis, are still there.  He didn’t have the architectural input he needed in the beginning when creating the ontology, and his work has been a little “out of sync” with good metamodeling practices ever since.  As a result, when it comes time to connect his research to a larger body of emerging work, we have some challenges. 

    To whit, at the Open Group EA Practitioners Conference in San Francisco (31-Jan-2012), I was discussing the notion of business models with a tool vendor whose tools are Archimate compliant and allow for flexible metamodels.  He had no metamodel for the Business Model Generation work.  Why?  Because no one had published a reasonable translation of the BMGEN ideas into Enterprise Architecture.  Similarly, when reviewing the VDML (Value Delivery Modeling Language) metamodel that is being proposed within the Object Management Group as an approach to business modeling, there is no good connection between the business model work of Osterwalder and the evolving work on value streams, capability modeling, and process improvement that forms the cornerstone of the VDML approach.

    Time to fix this.  This post will attempt to describe the metamodel that I created for Osterwalder’s BMGEN when I was working to integrate his ideas into the Enterprise Business Motivation Model.  Note that I created this metamodel originally in 2009, and updated it in 2011 through collaboration with the Business Architecture Guild.  I have NOT had a conversation with Dr. Osterwalder on this topic yet. 

    What is a Business Model

    According to Osterwalder, the definition of a business model is this: “A business model describes the rationale of how an organization creates, delivers, and captures value.”  And further: “A business model can best be described through nine basic building blocks that show the logic of how a company intends to make money.”  Still further, “The business model is like a blueprint for a strategy to be implemented through organization structures, processes, and systems.”

    The nine “building blocks” referenced by Osterwalder are:

    1. Customer Segments
    2. Value Propositions
    3. Channels
    4. Customer Relationships
    5. Revenue Streams
    6. Key Resources
    7. Key Activities
    8. Key Partnerships
    9. Cost Structure

    Osterwalder goes on to describe a simple visual mechanism for capturing these elements, which he calls the “Business Model Canvas.”  It is a simple table that can be captured on one page that allows the elements of the model to be easily elicited in a one-day business model workshop.  The following image was captured directly from the web site “businessmodelgeneration.com” and represents the Business Model Canvas.

    The Business Model Canvas

    The Business Model Canvas and it’s conceptual information model

    There are a great many clues in the BMGEN book about the conceptual model implied by these elements.  Unfortunately, these clues are somewhat inconsistent.  We will do the best we can. 

    From the definition above, it appears that a business model is described through these nine building blocks.  In information model terms, we would say that a business model is a composition of these nine elements.

    However, when we look at the relationships between the elements, it is not always clear.  For example, in the conceptual model, key resources are “assets required to offer and deliver the previous business elements.”  Unfortunately, the “previous business elements” includes about half the elements.  Also, cost structure (singular) is the result of the other elements.  This makes for a rather odd conceptual model, that doesn’t look much like the model that Osterwalder himself proposed in his thesis.   In the model below, the green boxes are the nine elements.  The red elements are described in the text as subtypes but not modeled. The yellow boxes are referred to by the elements, but are never actually captured in Osterwalder’s Business Model Canvas.   Unfortunately, one of these elements is the Voice of the Customer (VOC)!  Another is the organization itself.  Should these elements be excluded?

    The model that I derived from reading the book is as follows (click on the image to enlarge).

    Osterwalder Conceptual Model

    The model above represents the relationships between concepts captured in a single two-page spread in the book Business Model Generation that introduces the Business Model Canvas.  This model is wildly complex and needs to be rationalized.  I will walk through the process that I followed to rationalize this model.

    Rationalization phase 1: Fixing the Relationships

    In this step, we will look for missing elements, add actual relationships that were not captured in the text, and then remove transitive elements that remain.

    Step 1: Look for Missing Elements

    For each relationship, look to make sure that it makes sense from an abstraction standpoint.  There are two gaps that jump out of the model above.

    First is the relationship between value proposition and organization.  According to the model above, there is a one-to-many relationship between organization and value proposition: one organization can have more than one value proposition.  This is true, but modeling it is problematic.  Organizations actually have relationships with every single element, not just value propositions.  Every element is part of the business model.  We know, from simple observation, that most organizations have more than one business model.  But the concept of the business model itself is not on the diagram.  So we will create the concept of a business model and INCLUDE every element on the diagram.  The organization will relate to the business model (one to many).  This addresses the problem.

    The second gap in Osterwalder’s model is that he describes a value proposition, but not a product or service.  In other words, the business is valuable, but we never model the product or service that we are going to deliver in order to make it valuable.  Huge Mistake.  Probably the biggest flaw in the Business Model Canvas.

    (Note: the diagram below includes the results of all three steps of rationalization phase 1.  Please refer to it for the following two steps as well. Click the image to see it at full size.)

    2. Osterwalder Conceptual (minus transitive)

    Step 2: Look for Missing Relationships

    In the original model, there were a number of relationships to cost structure, but there were very few relationships to revenue streams.  These seem like parallel concepts.  So I considered the different elements that should impact revenue just as much as they impact cost structure.  First off, if key activities and key partnerships impact the costs, why would they not impact revenue?  Clearly, activities of the organization will impact revenue as well as cost.  Similarly, the partnerships clearly impact revenue just as they impact costs.  (Note that the Osterwalder canvas does not distinguish between supply chain partners and sales partners.  They are all just partners).

    Some of the additional relationships added:

    • Channels target segments.  For sales and distribution channels, we are targeting specific customer segments. 
    • Key activities impact revenue streams
    • Key partnerships result in revenue streams

    In the model above, added relationships are marked in red.

    Step 3: Remove Transitive Relationships

    A transitive relationship is one that makes sense to a person, but doesn’t make sense in an information model.  A transitive relationship is derived from an intermediary, and more correctly implied through other relationships.  For example, the text indicates that customer relationships result in the cost structure.  However, it is not the customer relationship itself that drives costs, but the resources required to maintain it.  Therefore, the relationship, in the model, between customer relationship and cost structure is transitive.  We can safely drop it.

    Also, the relationship between segments and resources is transitive.  Each segment requires resources, of course, but it does so because of the customer relationships demanded for those segments.  This is also a transitive relationship.

    In addition, with the addition of the "missing” relationship between channels and revenue streams, there is no need for the transitive relationship from value proposition to revenue stream.  Clearly, the revenue stream is realized through channels. 

    Rationalization Phase 2: Simplify Modeling

    When rationalizing a metamodel, it is important to consider the result.  What are you going to do with the metamodel?  Metamodels are used to define how the elements of a model work together.  In effect, you are describing a language.   The terms of the metamodel are like the parts of speech of a language.  They can relate with one another in specific ways, but they describe the structure of the language, not it’s content. 

    That said, the more terms that we add to a metamodel, the more complex our resulting models will be.  As a metaphor, if you want your language only to have simple sentences, reduce the number of parts of speech.  If there were no adverbs, consider how much simpler our sentences would be.  On the other hand, you never want to simplify your language so much that it cannot convey the ideas you need it to convey. 

    If the English language were stripped of adverbs, we would lose the ability to say things like:

    Shall I compare thee to a summer's day?
    Thou art more lovely and more temperate:
    Rough winds do shake the darling buds of May,
    And summer's lease hath all too short a date…

       (William Shakespeare, Sonnet 18)

    So we have to have as many parts of speech as we need, but no more and no less.  (Or to quote Einstein: Make everything as simple as possible, but not simpler.)

    To make our model simple, we need to look for places where we have two (or more) entities where one will do.  After all, an adverb can modify a verb and another adverb.  We could have had two different “parts of speech” there (one for modifying verbs and another for modifying other adverbs) but that would have made it difficult to use the concept of an adverb to analyze sentences.  Similarly, if we have two concepts that "overlap” or can be simplified down to one, we should do it for the sake of making simpler models.

    How do we know when two metamodel entities need to be simplified to one?  When both entities have the same relationships with surrounding objects.  Specifically, entities A and B can be combined into a new entity AB if every relationship between A and [C, D, E,…] is matched, one for one, with a relationship between B and [C, D, E, …].  What does that look like? 

    3. Financial Elements Only

    The model above is the same as the previous one except that I simply hid the elements that I did not want to illustrate, and moved things around for effect.  By doing this, it is pretty clear that the relationships between “revenue streams” and all if its neighbors is parallel to the relationships between “cost structure” and it’s neighbors.  Therefore, while it is perfectly appropriate (and in fact useful) to capture these as different “things” on a business model canvas, I maintain that they should be modeled as one object: Cost and Revenue Model. 

    There is one more opportunity for simplification.  The notion of customer relationship and customer problem or need.  This may very well be a problem of my own making as Osterwalder’s model doesn’t have a “customer problem” element, so it is entirely possible that he meant to include that concept in the “customer relationship” area.  The “duplication model” for the customer area looks like this.

    3b. Customer Elements Only

    Combining customer relationship and customer need into a generalization of “Customer Demands and Relationship” provides the last change in this phase of the rationalization process.  Note that once these changes were made, the link from Value proposition to Customer is now transitive through the new element, so it is dropped.  The model, at this point in time, looks like this:

    4. Conceptual With Combined Financials

    Also, for the sake of modeling simplicity, you may notice in this model that I dropped the subtypes for “channels.”  When metamodeling, it is a good idea to avoid subtypes that are simply lists of example types with no distinct relationships of their own.  The exception to that rule would be to illustrate the fact that a term commonly used in business literature is, in fact, a subtype of some other generalization.  (an example would be the term “Strategy” which is a subtype of “Driver” in the full EBMM).

    You may also note from the model above that act of “generalizing” the concepts of Cost structure and Revenue streams into a single object required me to generalize their relationships as well.  Therefore, when we used to say that a channel “results in” a revenue stream, we can now say that a channel “drives” both revenue and cost models. 

    I also removed, from this view, the organization object.  That relationship sits at a higher layer.

    Rationalization Phase 3: Aligning to Architectural Terminology

    All this work was simply an analysis of the model on its own terms.  However, terms already exist for these items, and the field of Enterprise Architecture is honing in on many of them.  If we don’t recognize the common terms that already exist in industry, then we will have a difficult time integrating the Osterwalder Business Model with anything else.  I am aware that Dr. Osterwalder read, and cited, a great deal of literature in developing his original ontology.  However, the literature that he read, and cited, came to him from academic and research papers.  It did not come to him from practical business discussions.  There are very few things I am certain of, but one thing I can state with certainty: most business people don’t give a flip about the terminology in academic papers. 

    Terminology matters.  If we mean the same thing, but use different terms, then we will get confused when speaking with one another.  This is the primary reason that biologists, chemists and physicians around the world have agreed on names that are shared even across language and culture boundaries.  Enterprise Architecture is not there yet, but we should at least agree among the authors within the English language about two different words that apply to the same concept.

    image

    That said, we also have to be careful.  Specifically, in this effort, I considered using the term “business capability” to use in place of “key activity.”  For one thing, the point of a “key activity” is to describe those actions that are demanded by the business model to be performed by the business (as opposed to one of the partners).  In other words, it is not an outsourced activity.  For that reason, a business capability (which includes the notions of “process", “information”, and “role”) is a very close parallel.  Unfortunately, in business architecture, the concept of a business capability plays a very specific role in the planning process.  It is needed in an overall business architecture model in a very specific and rigorous way. 

    One of the basic rules of metamodeling, derived from information architecture, is to minimize or eliminate situations where a single term appears twice in the same model.  I knew that the “capability” term needed to exist as part of the relationship between “business initiative”, “business process”, and “business application.”  Therefore, I really couldn’t use that term again as part of the business model package.   That said, the concept of a “key activity” is too limited for business modeling.  We are doing more than capturing activities.  We are capturing the need to be able to perform an activity, along with all the underlying information, processes, and systems that it will require.  As a compromise, I chose the term “Required Competency” to capture the meaning of this element.

    In addition, the business model canvas uses plural terms, where models should always use singular terms since the notion of plurality is assumed through the act of modeling.  (This is derived from information architecture principles).

    One major variation added at this point is the renaming of “Key Partnerships” to two elements: “Business Partners” and “Partner Type.”  This change is mirrored on the customer side by renaming “Customer segments” as “Customer Types”.  This parallel naming convention is designed to allow us to use the same metaphor (“a type of thing”) for both partners and customers.  The notion of segment is not often used when referring to partners.  In addition, the notion of a “key partnership” assumes that we will capture the instance of the partnership (e.g. a partnership with Amazon.com) instead of the TYPE of the partnership (e.g. partnership with an online retailer). 

    For a  business architect to use the business model to perform analysis, it is helpful to break these two concepts apart.  For example, if we say that “amazon.com” is a key partner, we may be happy.  On the other hand, if we say that “amazon.com” is a key partner, of type “online retailer,” we may ask ourselves if we should develop partnerships with other retailers.  After all, a partner type with only one partner could be considered a “single point of failure” for the business model.  By separating these concepts, weaknesses like this one are easier to spot.

    Other naming issues were not so difficult. 

    Osterwalder’s name EBMM Name Reason for variance
    Key Resources Resource / Asset Strategy literature often refers to assets or required assets.  Added the synonym.
    Key Partnerships Partner Type see above
    Customer Segment Customer Type see above
    Key Activities Required Competency see above


    5. Aligned Terminology

    Final changes in this phase involve two changes in relationships, both as transitive. 

    • With the change of “Key Activities” to “Required Competencies” we changed the scope of the entity.  It now includes not only activities but also the information and systems needed to deliver the value proposition.  Therefore, the relationship between value proposition and “key resources” is moved become a relationship between value proposition and “required competency.” 
       
    • The relationship of “channels require key resources” is true, but is now no longer interesting at the level of abstraction of the model.  With the gradual changes like “customer type” and “partner type”, the level of abstraction of the entire business model has been rising.  The business model elements can now describe a business model in an organization that has many business models, some of which share partners, customers, and resources with each other.  This is a typical situation in most organizations.  However, in order for an organization to develop a channel, key people will have to understand how EVERY other element is impacted.  This is also true of customer types, partner types, products, etc.  At a very detailed level, everything impacts everything.  So this model consciously and intentionally excludes relationships that are simply “not interesting” from the viewpoint of analysis, innovation, and improvement.  For this reason, this relationship is dropped.
       

    Rationalization Phase 4: Aligning to Architectural Frameworks

    The most important framework, from an ontological sense, is the Zachman Framework.  John Zachman, recognizing the importance of his seminal work on the definition of metamodels, even renamed his work “The Enterprise Ontology.”  While there is some debate about whether the Zachman framework is useful without methods, there is no debate about its importance in Enterprise Architecture.  All other metamodels produced to date have made an attempt to describe the differences and similarities that they have with the Zachman Framework.

    Therefore, I took the time to examine the new Business Model mechanism and compare it with the Zachman Framework and noticed that the element of “Location” is simply missing from Osterwalder’s canvas.  For the purpose of developing the core concepts of a business model, it may not be needed, and it is therefore defensible.  However, from the standpoint of analysis for weaknesses and opportunities, or for examining the impacts of Porter’s Five Forces on the model, it is essential that we add in the location elements. 

    The final evolution of the Business Model area in the Enterprise Business Motivation Model (v3.8) is:

    Business Model Viewpoint.3.8

     

    Integrating into a larger model – the EBMM

    In the Enterprise Business Motivation Model, there are twelve core elements.  They are illustrated in the following view.

    Core Elements Only View.3.8

    As you can see from this view, the Business Model is one of the core elements.  A business model is treated, at the top level, as a single entity.  All of the work that we have done in this effort was to rationalize the components of the business model.   Effectively, I was creating an understanding of how the business model elements themselves relate to one another.  However, NONE of them relate to other entities in the Enterprise Business Motivation Model.  The reason for this is simple: no company ever implements their business model.

    I will say that again.  No company ever implements their business model.  Not directly, anyway.

    Why?  Because a business model is just a model.  It is not reality.  It is a gross generalization of “how things should work.”  It reflects the intent of the owners, but not the reality of the business.  There is always a gap between where the business actually is, and where the business model says that the business should be.  This is a good thing and sometimes a bad thing.

    The positive aspect of this is that the owners of the company can change the business model readily, and then ask the organization to change to follow suit.  In doing so, the owners are like the captain on a large ship telling the pilot to take a particular heading.  The captain doesn’t turn the ship.  The pilot does, and the ship doesn’t turn right away… it takes time.  The course taken by a large vessel in the open ocean is “approximately” the same as the planned course (on a good day), but is rarely exactly the same.  The same applies for business as well.  The business model is a high level abstraction that indicates the intent of the owners, not the implementation of the organization.

    The negative aspect is that the implementation of a business model may wander, over time, to be quite different than the intent of the owners.  This is especially true when new products or services are introduced, but the owners do NOT take the time to consider the impact on the overall business model.  As a result, the implementation (the business itself) may be quite a bit less efficient, elegant, and effective than the business model would imply.  The assessment of the business model, in the EBMM, is a way to capture both the difference between the intent and the reality, and the difference between the intent and the needs of a dynamic marketplace.

    Relating Business Models to other Business Architecture Elements

    As you can see from the core elements diagram above, the concept of a business model is CENTRAL to the Enterprise Business Motivation Model.  This is not true of any other metamodels in use today.  This renders most of those metamodels problematic at best, including Archimate, VDML, Essential, and TRAK.  The need to align to strategy is simply incomplete without the concept of a business model.

    Why do we need the concept of a business model in order to align initiatives to business strategies?

    Because, in large organizations, there is no such thing as a single strategy.  It is perfectly valid to create an overall performance goal, but strategies, described at the level of the enterprise, apply unequally to each of the business models within the enterprise.  In fact, it is quite normal for a CEO to announce a series of “strategies” for the entire enterprise that, when examined in detail, are actually contradicted within the context of one of the business models within that enterprise.

    For example, I was taking a long look at Air New Zealand recently.  This is an airline in the “low cost airline” model, largely owned by the New Zealand government.  In my analysis, I found NINE different business models at play in Air New Zealand.  Not one, or two, or three.  Nine different business models.  (This is not particularly surprising to me.  My examination of Microsoft uncovered more than twenty business models). 

    The performance goal, set by the CEO, is to improve profitability of the airline by more than $195M (NZD) per annum by FY15.  That is a very well articulated goal.  Hats off to the CEO. 

    However, the strategies described do not apply equally to all nine business models.  The strategies that I gleaned from the Interim Report for 2012 include very important elements like “reducing fuel costs” and “innovation on loyalty products.”  However, one of the business models of Air New Zealand is an airline training academy where pilots, mechanics, and ground crew can learn their jobs.  Those strategies apply to the core businesses (passenger and cargo) but not to the training business.  This is normal and expected.  (Please don’t construe my words as a criticism of ANZ.  I have never seen an annual report that provided the strategies for anything OTHER than the business models that provide the lion’s share of the business revenue.)

    Therefore, when a business architect is working within the organization, trying to align the initiative to strategy, it is imperative to know WHICH STRATEGIES APPLY.  If you don’t capture the business model as an element in your business architecture, you cannot map strategies to business models to know which initiatives are actually well aligned (to their business model) vs. initiatives that are poorly aligned and should be scrapped.

    Don’t be fooled.  Failure to capture the complete list of business models in the business architecture is an error that is easily avoided.

  • Inside Architecture

    Aligning the EBMM with Archimate

    • 8 Comments

    I just recently had a conversation with a talented enterprise architect who had brought together the EA framework elements from numerous different sources in order to address the needs of his business.  Included in that list was the Enterprise Business Motivation Model which I developed and which I continue to maintain.

    He reminded me of one of the bits of feedback that I’ve been given over the years, and that is “integrate the EBMM with other frameworks.” 

    The challenge I have with that is that many other frameworks don’t have a metamodel.  The EBMM is a business architecture metamodel.  Of course, that is a quickly vanishing excuse.  The open group is largely using Archimate for their metamodel these days, and other frameworks have had metamodels from the start.  So it is time to get off my back and start taking a look at how the EBMM relates with, or differs from, standard metamodels.

    I’m starting with Archimate?  Why?  Because it is at the right level of abstraction, fits well with the gaps in the EBMM (in the IT space, where Archimate excels, there is nothing in the EBMM), and allows a good relationship with tools implementation.

    So over the course of the next few months, in my copious spare time, I’ll be diving in on Archimate and trying to improve my skills there, and find the ways to connect it to the EBMM.  If you have insight that you can share, please let me know.

  • Inside Architecture

    Speaking at TechEd New Zealand on Business Architecture

    • 1 Comments

    Haven’t  been to New Zealand yet, but I will be there soon… From September 4 through 7 in Auckland, for TechEd New Zealand.  I will be presenting two topics (Business architecture for non architects, and Aligning IT with capabilities).

    Now, normally you wouldn’t see Enterprise Architecture topics on a TechEd calendar.  However, in the NZ market, there just isn’t the demand for multiple Microsoft conferences every year.  As a result, all the conference demand is bundled up into TechEd.  Due to the efforts of Terry Chapman and the hard working architects in Microsoft New Zealand, the TechEd conference there has developed quite a reputation for hosting an advanced architecture track. 

    I’m fortunate to be attending and presenting.  If you live or work in the region, I’d love to see you at TechEd New Zealand.  If you would like to see more information about the sessions at TechEd NZ, click here.

Page 1 of 1 (5 items)