Nick Malik

I made an interesting mistake, today… one that comes up from time to time.  I used a business term in one way, and some members of my audience understood what I meant, while others did not.  In this case, the word was “core”.  The word has two different definitions.  Unfortunately, the definitions are quite different, at least in an Enterprise Architecture context.

The dictionary definition of “core” reflects the problem.  Bing dictionary defines “core” as the “central” or “most important” part of something.  Notice the word “or.”  Either meaning can be intended.

This goes to an old idea of putting the most important part of something in the middle.  In ancient kingdoms, the capital city was often very centrally located, usually near a convenient transportation route (like a river) that offered quick access to all parts of the kingdom (within reason).  So, the word core can mean “most important” or it can mean “in the middle.”  In the past, those two meanings were synonymous.

But in business, the thing “in the center” is not the most important thing.  Porter illustrates this with his (now famous) value chain model:

Porter’s Value Chain.  Image source.

What is the most important part of that model?  It’s the bottom-half, illustrated as the “primary activities” or value chain.  Porter is smart enough to avoid the word “core” because it has the connotation of “in the center” when he wanted to illustrate that value chains are not “in the center.” They traverse “end-to-end”. 

Porter seems to be somewhat alone in avoiding the term “core.”  Many business books and resources use the term “core” when referring to the primary activities.  There are countless illustrations, if you bing for images with the search phrase “business core”, where you are looking either at a set of service offerings or a value chain.  The following diagram is a business architecture reference model for the hospitality industry.  The name of this model: Core Business Domains and Processes. 

Core Business Domains and Processes – Hospitality Technology Next Generation Reference Architecture

On the other hand, there are also illustrations of business where “shared” items are at the center, and non-shared items are “at the edge”.  Illustrations like this one are also quite easy to find:

Source: United Nations Office for the Coordination of Humanitarian Affairs

In business architecture, do we illustrate “core” things to be “shared things at the center of a circle” or do we mean “core” to be “the most important things?”

In Enterprise Architecture, the distinction becomes more problematic.  Shared things are often the LEAST important thing from the perspective of the business, not the MOST important thing.  For example, the HR department is often a shared function, and unless the company is an HR service provider, that business function is not part of the value stream.  On the other hand, from the perspective of information architecture, the shared things are the most important and the non-shared things are the least important.  For example, a single understanding of “customer” is critical, especially when that understanding is shared across marketing, sales, and customer service.  It is shared, common, and very important.   

Now, add a specific use of the word “core” that is used in EA:  the notion of a “core diagram” as described in the book “Enterprise Architecture As Strategy” from Ross and Weill.  In that sense, the diagram itself may vary depending on which one of the operating models is being used, but the model itself is a shared, common understanding of the key items that are shared (whether that is process, information, or both).  In that case, the thing that is important is the thing that is shared.  That is called “core.”

Two years ago, I made a presentation to the Open Group conference about creating core diagrams using a method I created called “Minimum Sufficient Business Integration.”  In that method, I use the word “core” many times to refer to “shared” items that are central to an organizations’ Enterprise Architecture. 

So, what definition should I use for “core” when having a discussion about business and enterprise architecture?  Should the word “core” refer to “the most important” thing, or “the most shared” thing?

I don’t have a good answer.  Perhaps the best answer is to avoid the word “core” altogether. 

One of the most compelling things that an EA can do is frame the vision of a better future as a story.  I’ve found this to be true many times, and others have discovered this as well, but it is not frequently discussed among architects.  I’d like to bring together some of these threads and talk about three things: a) the effectiveness of story, b) how to create a story, and c) whether you need more than one story.

The Effectiveness of Story

Enterprise Architecture is about change.  If nothing is changing, the value of EA is fairly low.  That said, very few organizations, public or private, are in a stable state these days.  Change is everywhere.  But change is not easy.

Your stakeholders need change, but they may not want it.  In some cases, they want the change, but their peers are not asking for change.  Either way, getting change to happen in an organization requires a touchstone – some common belief or idea that everyone can relate to.  It has to be more than a fact, and more emotive than a strategy.  It has to be compelling, interesting, surprising, and easy to remember.  In the words of Chip and Dan Heath, this central idea has to be “made to stick.” 

In my experience, every time an organization changed, there was a story at the heart of the change.  In each case, there was a single story that helped people to see how the change would happen, or helped to see how the customer would be happier, or helped to illustrate how the new world would work. 

In the book, “Enterprise Architecture as Strategy,” Jeanne Ross described the concept of a “core diagram” which was a single image that people rallied around.  I’ve spoken about core diagrams before, and have suggested a way to create a core diagram that reflects an optimally agile organization.  However, the core diagram is only part of the story.

The story itself is what makes change possible.  The story itself is the touchstone – the “shared memory” that everyone recalls when the topic of change is discussed. 

Truly effective leaders understand this.  Steve Jobs would often use stories to get audiences (internal and external) to see the value of what he was doing.  Bill Gates, having shifted to health and education issues, still uses stories to communicate and connect.  The most effective political speeches, and most rousing situations, are always connected to a story.  At the time of this writing, Nelson Mandela recently passed away.  What are people remembering?  They are remembering his story.  They are also remembering how he used stories, as well as principles and a dedication to action, to create change. 

Successful change requires more than a story.  You also need to have a vision of what the destination of your change is.  But you cannot get to that destination unless people move, and people won’t move without an emotional connection to that destination.  Stories are necessary, but not sufficient.  Stories are the connection, not the destination… but you need both to survive.

How to Create a Story

Storytelling is an old craft, but business storytelling is fairly recent.  There are many things to consider, and it can take a while to figure out all the steps.  In general, I suggest that change agents should focus on four areas:

1. Focus first on the Content: Why do you want to change?  What must change?  How will the change occur?  What if the change happens (and what if it doesn’t)? 
    
2. Focus second on the Audience: Who must change and in what way?  Who do they listen to?  How do these folks learn?  How do they make decisions?  If you don’t know who you are telling the story to, you are reducing the odds of success.
    
3. Focus third on the story elements themselves: What is the structure of your story? Who are the characters of your story?  What drives them to move forward in the story?  And, very important, how will you tell the story to the audience?  Will you use videos?  Will you use a PowerPoint presentation?  Will you have people enact the characters?  Will you rely on signs and posters?  You have to think about all of these elements.
    
4. Focus fourth on the Design of the story and the Testing of the story.  Design is critical and important, but as you can see, we don’t jump into design first.  We first understand the story we want to tell.  We go to design late in the process, only after we’ve thought about the problem we are solving, the people we are trying to change, and the elements of story.  But even minor mistakes in design can create unnecessary distractions from your story. 

   How do you find the mistakes?  Test, Test, Test, Test, Test.  You wouldn’t “ship” a software product without testing it, right?  (unless you are the Center for Medicare and Medicaid :-).  So why would you “ship” a story without testing it.  This means rehearsal, delivery to friendly audiences, feedback from peers and the friends of your stakeholders, etc.  Any way that you can get good ideas about how well your story is connecting.

I use a simple mnemonic to remember these four steps: C-A-S-T.  Content- Audience- Story- Tell.

In all fairness, this is a simple blog post, and the topic is a bit bigger than can be placed here.  Big enough, in fact, for a good book.  If you want to actually create a story, I’d recommend readers to pick up a copy of my book from Amazon or your local bookstore: Stories That Move Mountains.  It is a visually striking book (thanks to Mark West) that tells the story of storytelling for business change. 

Note that the book is available in multiple languages, so check out your local bookstore.  (I shared a copy with one of my friends, and my wife picked up the Italian edition off my bookshelf to hand to him.  We all got a good laugh out of that).

How Many Stories Do You Need?

In telling a story of Enterprise Architecture, you may need more than one story.  You may need a story for the IT folks, and another story for your business stakeholders (especially for heavily technical stories like you’d find with BI or SOA initiatives). 

For each story, you will go through the process above, and in each, you would consider the audience.  But for the sake of this blog, I’d suggest that an Enterprise Architecture story needs to consider each of the changes being suggested.  Typically EA impacts each of the BAIT areas, but you probably only need two or three stories: one to tell about the IT changes and one or two stories for business stakeholders (a low-level story for impacts to business processes, and a high-level story illustrating alignment and customer centricity).

Conclusion

I don’t have any better advice to give to an Enterprise Architect seeking to increase his or her level of impact and influence than this: learn to tell effective stories.  The story never stars the Enterprise Architect.  At best, you are the helper, the assistant.  You are not Frodo, but Samwise (or Gandalf).  But the story compels the mind, and engages the heart.  The story holds the vision and makes it easy to communicate.  Wrap your vision in a story.  It is not a promise of success, but it helps. 

Since 2009, when I first published my open source metamodel of enterprise architecture (the Enterprise Business Motivation Model), I’ve had numerous conversations with architects, business analysts, consultants, technologists, and the occasional student about models.  I frequently hear things like “I have an update to your model that makes it better,” to which I reply “cool, let’s see it.”

After seeing about a dozen now, I’ve begun to realize that I need to ask better questions.

Some models are simply more interesting than others.  Some have relationships that are more appropriate for specific situations.  (for example, one friend sent me his version of my model with specific elements related to government organizational structures and interrelationships).  That is very interesting, because I can see a value in capturing distinctions related to different types of organizations.  Another friend sent me an update to my model with greater focus on customer relationships, which is great if the goal is to highlight the importance of customer-first modeling.  Another person sent me an extension he did to Osterwalder’s model to include additional aspects needed to develop a business that is sustainable in the world environment.

Those are the good examples.  They add unique value.  They consider new things.

Some not-so-interesting examples often come from students or usually young architects (less then three years in field), who simply feel that one set of relationships is “better” than another, without any particular rationale other than “it looks better to me.”  Note: that’s fine.  It means the model represents their way of thinking, and their use of terminology.

But what do I say when they expect me to rewrite the EBMM to match their thinking processes?

I say “yes” in very narrow circumstances.

So for those folks who want to propose an alternative model or an update to the EBMM, let me lay out some basic concepts and guidelines.

Prove that the model extension answers questions that need to be answered

The first and foremost problem is a simple one: adding stuff just because we can.

The EBMM can certainly be “bigger” if that were my goal.  But it isn’t my goal.  My goal is to ask specific questions and produce a model that answers them.  The list of questions is far more interesting than the model itself. 

So before you send me a model, send me the list of questions you need to answer with that model.  THINK ABOUT IT.  Don’t create the model and then go hunting for questions that justify it.  These need to be legitimate questions that are of demonstrable concern or value to an enterprise-level stakeholder. 

The EBMM was designed to answer a specific set of questions.  Those questions are included in the model itself.  If you want to extend the EBMM, ask different questions.  Then, we can extend the model to answer them if necessary. 

“All models are wrong.  Some models are useful.” 

Many of us are already familiar with this quote, from George Box, noted British statistician and author.  While he was referring to statistical models, his advice is worth considering on a deeper level.  In his 1976 article, Science and Statistics, he provided a very useful bit of advice to the would-be creator of models. 

“Since all models are wrong the scientist cannot obtain a “correct” one by excessive elaboration. On the contrary following William of Occam he should seek an economical description of natural phenomena. Just as the ability to devise simple but evocative models is the signature of the great scientist so overelaboration and overparameterization is often the mark of mediocrity.” (Journal of the American Statistical Association, 1976, http://www.jstor.org/stable/2286841,  retrieved 26 Sept 2013)

George Box said that so much better than I would have.  While he was referring to science and statistics, his advice applies to Enterprise Architecture rather well. 

What it means is this: if you have two models, both that capture the USEFUL elements needed to describe something, and one is simpler than the other, go simple.  In other words, I don’t care what is “correct.”  I care what is useful. 

Be forewarned: you send me a model that is a more detailed elaboration of my own model, with more elements and more relationships but which does not capture USEFUL knowledge more clearly, or convey information in a more accurate manner, I will reject it.  Additional detail is not useful unless you can demonstrate value. 

In order to demonstrate value, you need to show me two sets of information: one captured in the existing model and one captured in your more elaborate model.  You then need to describe to me how that information, in context, is less useful the way I captured it, and more useful the way you captured it.   Then, I will add complexity to the EBMM.  Yes, it’s a high bar.  The EBMM is complex enough as it is.

On the other hand, if you send me a model and you can demonstrate that you can use fewer elements to capture knowledge or describe intent than I did, I will not only listen, I’ll probably take a swing at removing stuff from the EBMM.  That’s a much lower bar for you, and a high bar for me.  I need to prove to myself (and you, if you are willing to put up with me) that the complexity in the EBMM is justified.  I will make things as simple as possible, but no simpler.

Simplicity in practice

Many folks have asked me why the EBMM doesn’t have entities for “database” or “network node” (or name your IT entity-of-the-day).  “It’s not a complete Enterprise Architecture model”, is the usual cry.  I usually point out that they are not looking at the right viewpoint.  The primary viewpoint, which most people are aware of, doesn’t show every element.  On the other hand, the IT Traceability viewpoint (below) has all the technical elements that an enterprise architect needs to model the technology landscape at an architectural level. (click the image to enlarge).

Simplification one: the model is for Enterprise Architects, not IT management

But wait, they cry, where’s the entity for a database!  Where’s the SharePoint Server (or the active directory server or the service bus, yada yada yada). 

Challenge accepted.  In the metamodel view above, information is managed within the context of an application.  Prove to me that you need to illustrate the element that gives you heartburn in a different way than I have captured.  Consider two questions: (a) Can an existing element be used? or (b) Is that element relevant in an enterprise architecture setting?

I can consider SQL Server, BizTalk, SharePoint, SAP, Dynamics, and many other systems to be “platforms” to be used by applications.   I can consider a server to be a “host” but I can also consider entire environments (like a DMZ or even the Azure cloud) as a host.  

So, no, I don’t have elaborate details that go further “down the stack” to the point of illustrating network nodes, because I don’t need them.  IT management does need those details.  That’s what a Configuration Management Database (CMDB) is for.  The EA repository may overlap with the CMDB but these two critters are quite distinct.  (topic for another post).

Simplification two: the model minimizes transitive relationships

A transitive relationship is of the form

A relates to B, B relates to C, therefore A relates to C.

I want to see the relationships between A and B, and between B and C. 

However, if you send me a model, please be aware of your transitive relations.  Don’t ILLUSTRATE the relationship between A and C unless it is NOT easily derived.  For example, look at the diagram above.  We could say that a Business process demands a system interaction point.  A system interaction point is described in a use case or user story.  Therefore, the relation between a business process and a use case can be easily derived.  Note, however, there is no “relationship arrow” on the model.  It is transitive, so there is no need to add the relation.

Minimizing transitive relationships reduces the complexity of the model substantially.  Realize that this is a conceptual model.  Nearly all concepts can be described using transitive relations (and many are). Rather than have a model where “everything relates to everything,” this simple practice makes the model readable and usable. 

On the other hand, some transitive relationships should be captured.  These would be the relationships that are NOT easily derived because of their complexity or underlying meanings.  For example, in the diagram above, an application uses a platform, and a platform is deployed on a host. I also illustrate the transitive relation (application is deployed on host).  Why?  Because platforms are optional.  It is possible to create an application that is NOT on a platform.  However, the relationship to a host is not optional.  Since this detail is not easily derived from observing the model, I illustrated both relations. 

Important note: when I discuss business capabilities, I say things like “you should map people, process, tools and information” yet in the model, I only illustrate the connections between the capability and process, and capability and tools.  That’s because the relation between capability and people is transitive (through process).  The relation between capability and information is similarly transitive (also through process).  I follow my own rules. 

Conclusion

For those folks kind enough to offer feedback on the Enterprise Business Motivation Model, I want to say, first and foremost, thank you.  I listen to every opinion and I care about every detail.  It is a labor of love.  Each new insight offers me an opportunity to refine the model, and I may make changes simply because you taught me something.

That said, if you are focused on seeing a change to the model as a result of your research, I will expect you to be cognizant of the context and concepts expressed in this blog post.  I certainly will be.

One of the most common mistakes that people make about Enterprise Architects is the notion that we are problem solvers.  Yes, EA solves problems, but to frame EA in those terms is like saying that an ER Doctor is a bandage changer. 

To help clarify the distinction between a “problem solver” and an Enterprise Architect, I will illustrate the logical argument for both, and show their differences.

Problem Solver	Enterprise Architect
Task: understand the problems and solve them	Task: understand the opportunities for the enterprise to be better aligned to its vision and focus attention on them.
Methods: Find people who know what the problems are, and ask them. Look for root causes to those specific problems, narrowing focus to the ones that contribute to a desirable outcome. Describe solutions to those problems	Methods: Collect and analyze information to understand the organization. Design the organization to meet the desired level and type of value delivery. Design ways to change the organization and ask why they didn’t already change on their own. Look for root causes and underlying challenges. Focus attention on the obstacles that prevent normal mechanisms from addressing the problem.
Results: well understood problems that are commonly ignored get  solved (without addressing “why they were ignored”).	Results: opportunities that no one wants to see or problems that people are afraid to solve are discussed and addressed.

 

The left column is what business analysis is for.  It is what solution architecture is for.  It is NOT what Enterprise Architecture is for.  I don’t care how good you are at doing the stuff on the left.  I don’t care how well it has worked for you in the past while working as an EA.  The “raison d’être” of EA is not to solve well-understood problems.  It exists to find out why the organization hasn’t seen the obstacles that actually prevent success, hasn’t removed them,  and hasn’t figured out how to cope with them.

Five blind men describe an elephant, each in different ways.  The EA is the sixth blind man.  He listens to the other five and says “the problem is not that an elephant is like a fan or a rope or a wall… the problem is that it is standing in the living room, and dropping large amounts of waste on the floor.  Problem solvers try to find a better way to feed the elephant and remove it’s waste.  Enterprise Architects asks why everyone is standing in the same room as an elephant.

Frequently, when reading articles or books on business architecture, the following advice emerges:

Business architects start with the strategy of an organization.  They take that strategy and map it to the capabilities of the enterprise to clarif…

It still surprises me to see various discussions of business architecture where there is a poor understanding of the relationship between business models and business capabilities.  The vast majority of discussions of business architecture, including books, articles, and blogs, make very little mention of business models, and nearly never discuss their relationship with business capabilities, organizations, stakeholders or resources. 

To me, the concept of a business model is fundamental to using business capabilities.  I cannot imagine attempting to understand a commercial organization without understanding the business models of that organization as a first step. 

In this post, I will discuss the reasons why business architects must consider business models.  I’ll start with some definitions to minimize confusion, given the fact that everyone has different definitions of these concepts.  I’ll then discuss the concerns that I have about the lack of integration of core concepts.  In a future post, I will discuss the various information models for including business models into business architecture as well as needed changes to business architecture methods (including capability analysis) in order to correctly place this role.

Caveat Emptor: The following discussion of business models will focus on commercial systems.  If you are examining this space from the standpoint of a non-profit organization or government agency, your needs may not be well represented.  My apologies.  The reason for this will be immediately apparent when you read the definition of “business model” below.

Definitions

The Business Architecture Society and the Business Architecture Guild have joined forces and created a common definition of a “business capability.”  From the Business Architecture Body of Knowledge Handbook: “A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.”  Note that the BIZBOK cites Ulrich Homann as the originator of the definition.  For the sake of this discussion, let’s take this definition as a given.

There are many definitions of a business model.  Perhaps the most popular definition today comes from Alexander Osterwalder, author of the popular business book “Business Model Generation.”  However, his book doesn’t have the same level of discussion of a definition as the Ph.D. thesis that he wrote in which he defines a business model as follows.  “A business model is a conceptual tool that contains a set of elements and their relationships and allows expressing a company’s logic of earning money.  It is a description of the value a company offers to one or several segments of customers and the architecture of the firm and its network of partners for creating, marketing and delivering this value and relationship capital, in order to generate profitable and sustainable revenue streams.” [Osterwalder, 2004]

Osterwalder carefully notes that a business model is not a representation of the business organization itself.  He states, and I concur, that the business organization is the “material form that the conceptual business model takes in the real world”. [Osterwalder, 2004]

I will also take a moment to define business strategy.  This time, from Kaplan and Norton: Business strategy is a description of how an organization intends to create value for its shareholders, customers and citizens.  Note that this is not the same as a business model. Osterwalder addresses this distinction by illustrating that one can view strategy, business model, and process model as a three-tier hierarchy.  The top level, business strategy, describes the conceptual approach to business change.  The business model goes into more detail, describing the relationships between various components.  The third level, process, illustrates the association of activities to the people and business functions that will perform them.  All three are necessary, but all three are different in level of detail and analysis.  The following picture is directly from his Ph.D. thesis (click to enlarge for readability).

 

Concerns

One of the challenges in bringing together these concepts is the fact that most business architecture references make no mention of business models or describe business models as a “side concern”, and most of the business model literature makes no reference to business capabilities.  I attempted to address this gap in the paper where I introduced the Enterprise Business Motivation Model, back in 2008.  While the model has dramatically improved since then, the core motivation remains the same: to integrate these two concepts into a single coherent approach to understanding and modeling a business.

Business architecture cares about the organization of a company.  It also cares about the resources or tools in a company.  Business architecture cares about the processes, and the information.  These elements are all brought together in the understanding of a business capability.  Business architecture also cares about strategy.  However, as Osterwalder notes, connecting strategy to organization or processes without an understanding of the business models is a partial understanding at best.

Let’s be clear about one thing.  Business strategy is related to business models.  In fact I will go further to say that all effective business strategy applies to one model at a time.  Business strategy that applies to more than one model is not strategy.  It is either a goal, a principle, or a vision of some kind.  A strategy, by definition, has to express “how” the goal will be achieved, and that requires the context of a business in which to achieve it.  I know that this may be controversial, but it is CORE to my understanding and the experience I want to share.

So let’s look at the viewpoints of business model proponents and business architects.

So what if these two viewpoints differ?  What’s the downside?

There are a number of problems within large organizations that cannot be solved by business architects without a consistent and careful understanding of business models.  These problems are tenacious and challenging.

1. Conflicting strategies: Most large organizations have many business models.  Frequently, there are senior leaders who are focused on making one business model successful without any concern for other business models.  Those leaders will create strategies for improving their model, sometimes to the detriment of other leaders and their models.  This leads to political infighting and friction as teams reporting to different leaders are left to “fight it out” when one strategy directly conflicts with another.
2. Inconsistent understanding among Leaders: It is common for business leaders to be only vaguely aware of the potential for interaction between their model and the models of other leaders.  Therefore, their words and actions will not reflect a consistent and mature understanding of those other models.  This drives serious inconsistencies into their organizations.  This lack of consistent understanding turns into poor assumptions, simplistic rationalizations, and invalid arguments. 
3. No prioritization produces confusion among shared services: Without understanding what the models are, it is impossible to rationally prioritize the relative importance of those models to the success of the enterprise.  However, it is quite common that multiple leaders leverage shared services within an enterprise (like human resources, legal and IT).  Without the ability to prioritize and create constructive conversations, these “shared functions” are driven to create complex and conflicting services that are expensive to maintain and resistant to change.

I would like to suggest that three of the key value propositions for business and enterprise architecture lies in addressing these specific challenges.  In other words, Business architecture is only effective if it copes with conflicting strategies, inconsistent understanding, and indecisiveness caused by poor prioritization.

Conclusion: Including business models directly into the business architecture practice is critical to quality.  Failure to include them is a recipe for disaster.