Inside Architecture

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

October, 2013

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

Page 1 of 1 (2 items)