Inside Architecture

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

Posts
  • Inside Architecture

    Business Architects: What’s at the “core”?

    • 7 Comments

    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. 

  • Inside Architecture

    Climbing the ladder from EITA to EA

    • 3 Comments

    One of the most common problems in Enterprise Architecture, and one I get asked about routinely, is the “ladder” problem.  Many Enterprise Architecture teams are formed by assembling a group of talented technologists into a team and giving them a charter to “go do EA.”  The problem is that most of these teams have no credibility outside the technology group, and cannot really operate as a “bridge between business and IT” if they don’t have the relationships and knowledge that they need to be an Enterprise Architect.  Building those relationships and that credibility takes time… sometimes many years.  Until they make that transition, the team is an Enterprise IT Architecture team (EITA) and while that is useful, the value proposition of EA remains unfulfilled.

    I call this “climbing the ladder” from EITA to EA. 

    While the entire team should work on this, only a few will succeed.  Good news: That’s all you need.  However, it’s important that everyone makes the attempt to climb the ladder.  As a manager, I have no magic “test” to determine, for certain, which member of the team will make the transition and which won’t.  I once thought I did, but reality proved me wrong.  So everyone makes the attempt.  Those who remain EITA’s can continue in that role for the EA team, or they can transfer to a different group where their technical skills are valuable and needed.

    So, how is this done?  How does an individual EITA climb the ladder?

    You need four things:

    1. business knowledge
    2. empathy (and good reflective communication skills)
    3. courage
    4. air cover

    Business Knowledge

    Business knowledge is the one that should, on the surface, be the easiest of the three to acquire.  Unfortunately, it seems to be one that is sorely lacking among EITA’s who are attempting to make this transition.  What do I mean by business knowledge?  I mean the ability to understand the basic concepts of business at a working level.  In other words, can you answer these questions coherently:

    1. Explain the difference between value and cost from the perspective of the provider of a product or service
    2. For Contoso in Q4 CY2013, they saw sales to new customers increase while market share decreased.  Explain.
    3. Give an example of a disruption in bricks-and-mortar business triggered by mobile computing
    4. When your company acquires another company for cash, explain how the balance sheet is impacted
    5. Explain how opening a new channel for your customers can result in a decrease in sales
    6. Give an example of a good strategy that failed in your industry or market.  Why did it happen?

    Where do you get business knowledge?  There are a gazillion books that will give you the basics.  Universities are helpful as well.  With the wide array of support, Enterprise IT Architects should have no difficulty learning these things… yet it’s startling how many don’t.  I have some friends who insist that an MBA is needed.  I disagree with that, but college courses do help.  I hold out the most hope for success with a blended program like that offered by the Enterprise Architecture degree at Pennsylvania State University. 

    Empathy and Communication Skills

    There has been a good bit of ink spilled about technical topics: mobile platforms, SOA, security, etc.  These help with the EITA side of the job.  But they don’t do much for the architect who needs to climb the ladder.  To successfully make that move, most architects need to invest in training on their soft skills.  This means building up the following:

    • Listening – Can you elicit the emotional context behind your stakeholders strategies and goals?  Can you truly “hear” them?  There are courses, and books, and online videos, that can help you to become a more conscious listener.  Not only will this help you climb the ladder, it will also help you in your relationships with family and friends. 
       
    • Empathy – The art of empathy in business is one where you feel as your stakeholder feels.  Don’t confuse with sympathy.  Big difference.  Empathy is a selfless act, and your ego has to be put into check if you are going to learn empathy.  There are many folks in architecture who struggle with ego, ambition, and condescension.  I struggle as well.  But if you don’t tame this beast, and build your capacity for empathy, your stakeholders will have a difficult time connecting with you.  As the old saying goes: They won’t care what you know, unless they know that you care. 
       
    • Negotiation – You will be frequently called upon to find a way for two people, with different perspectives, to come to a solution where both people “win”.  These “win-win” solutions form the basis for successful endeavors of many kinds, not just in business.  But if you don’t know how to negotiate, your usefulness as a bridge-builder is seriously limited. 
       
    • Positional Awareness – this means the ability to “see” how the organization works from various perspectives, and to position yourself, and your value proposition as to provide you the ability to influence that system.  It also means being aware when other folks are doing the same thing, which has the effect of changing your landscape out from under you.  Some folks call this “politics.”  I call it necessary.
       
    • Selling – Yep, I said the dreaded “s” word.  Many architects view “sales” as a dirty word.  After all, Sales people use emotions, leverage relationships, and often don’t even understand the details of what they are selling.  The sale is more important than the actual people!  Ouch.  It’s true.  Sales professionals are often competitive individuals who have been known to compromise their integrity for the sake of the transaction.  But that doesn’t mean that the tools and techniques of sales aren’t useful, or effective, or critical to success.  These techniques are mission critical.  So take professional training in sales.  How to hook a lead.  How to build excitement.  How to connect to your stakeholders’ underlying motivations.  How to use emotion to communicate.  How to ask for the sale.  How to follow up.   The use of color, design, and simplicity to convey a message.  All of that. 

    Courage

    Did you know that courage can be learned?  I guess I always knew it was possible, but I never really considered it until I found myself with a situation where I needed to use courage, and needed others to do the same.  I was playing the role of a SOA architect, and I needed to convince development teams and technical architects to adopt a set of patterns that would help the enterprise, but may actually add complexity to their own project.  I needed to walk into rooms and see if I could demonstrate, convince, cajole, argue, and/or negotiate my way to changes that were not in the obvious best interests of the team itself. 

    I taught myself courage.  I taught others courage as well.  Part of teaching, and learning to be courageous, is to put your efforts into perspective.  See your work as necessary to a “bigger picture” and be very aware of how much you can get away with before others decide that they cannot actually follow your lead or support your efforts.

    Courage is not the lack of fear or operating outside of dangerous situations.  It is the conscious choice to move ahead despite danger.  As the Will Smith character in “After Earth” tries to teach his son, “Danger is real.  Fear is a choice.”  Sometimes, as an Enterprise Architect, you will have to tell someone powerful something that they don’t want to hear.  The situation can end badly, impacting your ability to continue working as an Enterprise Architect, or worse, resulting in you losing your job.  These dangers are very real to many EAs. 

    Courage means that you will need to move ahead anyway.  It does not mean you should be reckless in the face of danger.  It is OK to be cautious at times.  But real success often requires boldness, and your bold actions cannot be made without the courage of your convictions.      

    Air cover

    There is a difference between “being courageous” and “being stupid.”  The difference is support: do you have the support you need, by someone higher up the food chain, to take on the challenge of climbing the ladder in most organizations.  This support from above is critical to your success.  I call it “air cover” (a reference to a military situation where ground troops can request a deadly strike on an enemy to be dropped from planes, missiles, or artillery). 

    In a business setting, air cover means that you have successfully convinced leaders in various places around the company that you can be trusted.  They believe that you are valuable and that your motivations are in the right place.  So when a problem occurs, or one of your standards is challenged, or your roadmap makes a stakeholder angry, that leader can step in and sooth sore egos. 

    I cannot indicate the importance of air cover.  For architecture managers, if you don’t provide air cover for your team, you are worse than an ineffective leader… you are a disgrace.  And for architecture practitioners, if you don’t build the relationships you need to build so that you will have the air cover when you need it, you are not being courageous.  You’re being stupid, reckless, or chaotic (take your pick).  To climb the ladder, someone has to be holding the ladder.  That’s your air cover. 

    Conclusion

    Climbing the ladder is a difficult challenge for any Enterprise IT Architect (EITA).  It takes dedication, support, and some significant innate abilities.  However, for many who take on this challenge, the rewards are excellent.  I truly love Enterprise Strategy Architecture.  I hope to see many of you “in the trenches” with me, fighting to make our ecosystems healthier, stronger, and more agile every day. 

    Caveat: certification and frameworks

    You’ll notice that I never mentioned Certifications or Frameworks in the discussion above.  That’s because I’ve met and known hundreds of Enterprise Architects.  Certification was only useful to make them more effective as an EITA.  It made no difference for climbing the ladder.  Certification will help with some skills and a great deal of knowledge.   A certification may build confidence, reduce churn in your team, and make your results easier for others to read and follow.  I’m not putting down certifications.  I’m just pointing out that this step comes with experience, not certification.  At least, not yet.

    Technorati Tags:
  • Inside Architecture

    Enterprise Architecture as Story

    • 7 Comments

    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.

    imageYour 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. 

    Enterprise Architecture As Strategy: Creating a Foundation for Business ExecutionIn 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.

    image 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. 

  • Inside Architecture

    Diversity Versus Replication of Organizational Processes and Information

    • 0 Comments

    I recently had the pleasure of joining a discussion among organizational development professionals.  During that discussion, one individual asked an interesting question: in a distributed organization with multiple operating units, spread geographically around the world, should the organizational structure of each unit be similar?

    The illustration that the questioner used: organization structure (org charts).  Should the org charts look alike?

    As examples, he mentioned two business units of his own company, one that was fairly “steep” with a Managing director having two direct reports, both Vice Presidents, and each of them having a small number of VPs under them.  The alternative was a different unit of the same company where the Managing director had something like 16 functional managers reporting directly to him or her.

    Unit one looked something like this:

    image 

    Unit two looked something like this:

    image

    The questioner illustrated his example by pointing out in the “steep” structure (unit one), the director of Human Resources was somewhere down at level four.  In the “shallow” structure (unit two), the director of Human Resources reports directly to the managing director. 

    So here’s the problem he faced: the company had a hard time moving a qualified director of Human Resources from unit two to unit one, because he would be “dropping” to four levels below the managing director, and that meant less control, less access, and less effectiveness.  On the other hand, the executive in unit two, who had a large number of direct reports, frequently complained about being overworked.

    Should we force each of the units to have the same hierarchy? 

    Think about it.  The company had many structures, and they were different from one another, making it difficult for a person doing work in one of those structures to translate their work, their processes, and their efforts from one to another.  This limited mobility of workers and cross-pollination of skills.  It limited information integration and consistency.  It limited process reuse.  It meant that quality of the output could be quite variable, even though each of these different units produce the same (highly complex) product!

    image

     

    Before I go on… what do you think?  Should the company have the same structure in every one of their geographically diverse operations? 

    Would you change you mind if I told you that some of those business units were two orders of magnitude larger and more profitable than others?

    Which is better: diversity or consistency (replication)?

    The first observation I’d like to make about this “problem” is that it is a problem by choice, and not by accident.  The organization is NOT a franchise model.  This is a large organization that has grown over the past 100 years to be a very successful company.  Most of the life of the company preceded the information technology revolution… before computers and teleconferencing and instant communication.  Each of the business units had no choice but to operate independently.  Corporate management, early on, chose to allow each of the business units to structure itself as needed based on local conditions, people, culture, regulations, and resources.  In the terms of Jeanne Ross (author of “Enterprise Architecture As Strategy”), the organization was not a replication model.  It was a diversification model.

    That said, each of these business units provided essentially the same product in each of a half-dozen different locations around the world. 

    Only someone who had read Jeanne’s book would recognize that the underlying question in the room was simple.  The person posing the question saw a great many advantages to having a “replication operating model,” and didn’t see an advantage to having a “diversification operating model.”  He was seeking input on whether he was the only person who could see the advantage to making a switch.  (of course, he was not the CEO, so it was a fictional exercise, but a useful one nonetheless).

    Switching from a Diversification Model to a Replication Model

    There are many problems with making a switch from a diversification model to a replication model.

    1. It is fairly complex to do.  An “ideal” model must be created for all of the business units to follow.  Since none of the current business units is likely to have that “ideal” model implemented, you’d first have to create an “ideal” model and then implement it in one place to get feedback on how it actually works (if it does).  That takes time.  Once you’ve made changes in one place, rolling it out means moving people, recreating processes, and restructuring information and accountability across each of those units.  It’s essentially the same a tearing down a company and starting over.  Only each of those business units will have to keep operating while it is going on, and will have to show profit at the end of the year. 
       
    2. Loss of business unit innovation.  Companies making that kind of switch usually screw up at the “ideal model” stage because creating the “ideal” model rarely involves the right conversations with every one of the business units involved.  As a result, innovations that are working well in one area can be lost because those innovations were not copied to the “ideal” model, even if they would have been useful to everyone.  Importantly, innovations that were about to be implemented in any one unit, but had not been, are completely discarded.  Evolution of the business units themselves can be thrown backward by years.  Also, by the very fact that there is now “replication by policy,” it becomes very difficult for any further innovation to occur because it has to occur once and then be replicated everyone else, regardless of whether that innovation has the same ROI in each business unit.  (Hint: it nearly never does).
       
    3. Loss of local adaptations.  There is a notion that “the person closest to the work knows best how to do it.”  In the case illustrated above, the two business units being compared were in different parts of the world, with different business cultures and business expectations.  The PEOPLE in these organizations have a specific idea of the way that business operates.  They have relationships, cultural expectations, and accountabilities neatly arranged to suit those local conditions.  Your “ideal” structure will come from you, and you live in a business culture.  We all do.  Therefore, you have assumptions about what will and will not work.  If you impose your structure on a group of people, be prepared to re-educate every single person in every single business unit on the “one right way” to do business… and then you’d better hope that the “ideal” you have created will be more effective in a local environment than the one that was previously there.  (Hint: it probably won’t be).
       

    A better way

    As I have explained in my previous discussions of “Minimum Sufficient Business Integration,” I believe that many modern organizations can benefit from taking the time to find the minimum set of capabilities needed across business units to meet key corporate goals.  After that minimum set is understood, the rest of the choices can (and probably should) be left up to the people closest to their customers and suppliers.  At best, a “reference model” can be widely shared that represents your idea of what an “ideal” structure would look like… but without enforcement from above.

    Of course, it can take a little thought to understand what is the “minimum” level of commonality that should be imposed.  It should be very carefully considered because, and this is important, for there to be value in this concept, that level of commonality will be strictly imposed.  No exceptions.  On the other hand, every little thing included in that “common set” will be VERY expensive to roll out consistently across a wide array of business units, so the absolute minimum set should be included.

    Conclusion

    My recommendation for this situation is to remain in a diversification model, but to consider moving a little closer to process and information consistency through minimum sufficient business integration (MSBI).  This means having consistency for those areas that absolutely positively must have consistency, and then to allow diversity (and innovation) to grow atop that minimum set.

    In that case, the org charts would probably remain different from one another… and rightly so.

    Happy architecting!

    P.S.: I also want to point out that the notion of minimum sufficient integration takes place at the level of business capabilities.  Not business processes.  Not information elements.  Not business functions.  Capabilities.  So if your business architecture methods don’t use capabilities (or if you don’t know what capabilities are), you cannot use this methodology.  This post is not going to teach you what a business capability is, but I’ve blogged about them dozens of times, as have hundreds of other folks including the Business Architecture Guild and the Business Architecture Society.  Start there.

  • Inside Architecture

    The Purpose of an Enterprise Architecture Framework

    • 2 Comments

    Can Social Media create new ideas?  Here’s an example where the answer is “yes.” 

    I recently blogged about EA models, and what makes them interesting.  I was thinking about providing insight to people who were in the mood to send me updates to the EBMM… a rather tactical post to deal with a rather pedantic an uninspiring issue: logistics of change.  On Twitter, however, a discussion broke out among rather distinguished architects that took the logic of my post to it’s natural resolution, and it was well beyond my limited thinking to have considered it when I wrote the original blog post.  In other words, they read my post, added insight, and create a novel idea, derived from mine, that I had not considered.

    It started with consummate twitter user Mark Nielsen (manielse) noticed my blog post and recommended it.  Tom Graves retweeted Mark’s comment and added his own.

    @tetradian: MT @manielse: By @nickmalik: What makes models interesting <<blog link>> #EntArch >important for all EAs

    Richard Veryard then added his own interpretation, restating the premise of my last post.

    @richardveryard: #entarch @tetradian @manielse  @nickmalik implies purpose of model is to answer specific set of questions - support a given reasoning process

    Tom then did something really interesting.  Using a little judicious editing, he create a new conclusion: one that I did not make in my post.

    @tetradian: @richardveryard "implies purpose of model is to ... support a given reasoning process" - yes, agreed / @manielse @nickmalik #entarch

    And there we go into new territory.  Richard caught an implication from my reasoning that I had simply assumed, without examining or testing.  Tom then took that implication and used it to reach a higher implication, and called it out in the open.  So let’s examine that resulting implication and then apply that logic a bit further to see where it goes.

    The purpose of a model is support a given reasoning process

    My prior blog post focuses on the questions that you want your model to answer.  You create a model to answer a question.  If you don’t know what the question is, you won’t answer it (or you will bury your answer in details that are not pertinent to the question).  So first ask the question. 

    But why are we asking a question?  This is the leap that Richard and Tom took.  Let’s understand that asking questions, for their own sake, is a rather detached activity.  Enterprise Architects tend to live a little closer to the practical world than that, so we are asking questions that are useful, not just interesting.  And what makes a question useful?

    We ask a question, and model the answer, for a couple of reasons:

    • We want to guide thought in ourselves.
    • We want to guide thought in others.
    • We want to answer a question asked of us.
    • We want to examine the results of asking a question that we find particularly interesting.

     

    Note that I did not say that we are guiding action.  We are guiding thought.  In some cases, thought precedes action.  In other cases, not so much.  But the role of the Enterprise Architect may be to suggest action, and it may include overseeing that action to ensure alignment to goals, but Enterprise Architects are rarely the driver of action.  Someone else funds the action and drives for conclusion.  We are the people who guide thought.  If we were living in a feudal society, we are not the King… we are his advisors. 

    The idea of “supporting a reasoning process” is clearly the first two bullets.  We want to guide thought.  We are walking through a reasoning process, either for our own decisions or for the decisions we will lead others to (sometimes both at once). 

    Tom’s edit takes on new ground because he allows us to draw a meta-conclusion: that ultimately a model may lead us to a reasoning process when we were not actually planning for it to.  This is the fourth bullet above, and one that I wasn’t really considering when I wrote the post.  What if we don’t know where the model will lead, until we create the model?  What if we are simply modeling because doing so is literally a form of reasoning in itself?  What if we can ask questions of the model that we didn’t think were relevant and wouldn’t have bothered asking, but can only ask because we have the model to answer it?

    Now, to extend the thinking just a bit.  What is an architectural framework?  While there are many definitions, there is one possible definition I’d like to propose: an architectural framework is composed of a reference model describing the essential elements of a system, and a series of methods for building instance models within that reference model.  In other words, a framework is a model and the tools to use it to build more models.

    The Purpose of a Framework

    If the purpose of a model is to support a reasoning process, then, by extension, the purpose of a framework is ultimately to support a particular theory of organizational evolution. 

    This notion flies in the face of most framework development efforts. 

    Taxonomic transformation, like that proposed by Zachman fans, is a model-driven design approach to mostly IT solutions.  The descendants of TAFIM, including TOGAF and DODAF, follow a methodological approach that builds from a solution standpoint, but which supports the core concept of a single-page enterprise architecture.  Service oriented frameworks like MODAF, FEAF and NGOSS are somewhat middle out, with the core concept being composability of services.  Business oriented frameworks tend to focus on classification of motivations, and usually start with some kind of metamodel like the OMG BMM, the BMGen canvas, or my own EBMM.

    Under here are the theories of evolution of a successful organization… but it will take a little archeology to figure out what those theories really are.  Just as we can look at the remnants of cultures long passed and deduce elements about the way that those people lived, we can look at frameworks and deduce the ideas that the framers of the framework had about how organizations could, or should, or must develop. 

    Frameworks, like models, are designed to answer a specific set of questions.  But more than that, they are designed to support a logical train of thought from understanding of a situation through proposing a pathway through it to meet a vision of success.  If your organization can only really support one fundamental approach, then you must choose the frameworks that can deliver on that approach in an effective way.

    Consider these aspects of each framework.   Consider the idea that frameworks are an outward expression of inner assumptions.  Then, go looking for those assumptions.

    If this is where we start, with the underlying assumptions, it is fairly easy to see why some frameworks are appealing to specific people and even corporate cultures, where others are not.  If the framework doesn’t support your view of organizational transformation and evolution, it is tougher to understand and apply it.  Your organization’s culture, politics, and history may end up doing more to help you to select an EA framework than you think.  After all, you can always extend a framework to include a method, but it is tough to deal with the problem of a framework that simply doesn't support the way people in an organization think about themselves and their mission.

    This is important because EA has been struggling for years to understand what the possible directions are for academic study and scientific examination.  Using this approach, we can refine and develop succinct theories of organizational development, merge similar frameworks, build commonalities among approaches, and even compare results of company development “in the wild” to see where these approaches lead.

    And the Credit goes to…

    Who authored the new idea?  Who cares.  I won’t take all the credit.  Perhaps it was first Richard Veryard riffing on my post and then Tom Graves creating a new idea by removing words. Perhaps I went to the conclusion after reading that edit.  I don’t know.   Perhaps it was just social.  Perhaps it is an idea that has already been proposed elsewhere.  I respect that possibility as well. 

    Regardless, I think there is a real idea under here.  We have artifacts, real artifacts, to take to our original authors as well as social anthropologists and archeologists.  Let’s ask for analysis and intent.  Let’s find out what those underlying assumptions really are.  We may discover that there are underlying theories of organizational evolution upon which we can base the ongoing development of the EA profession.

  • Inside Architecture

    What makes models interesting

    • 3 Comments

    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).

    IT Traceability Viewpoint 4.1

    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.

Page 1 of 104 (623 items) 12345»