Inside Architecture

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

July, 2010

Posts
  • Inside Architecture

    Avoiding Business Architecture Paralysis

    • 1 Comments

    A close cousin to “analysis paralysis” is BA Paralysis.  This unfortunate situation occurs when a business architect is asked to contribute to an ill-defined project within the scope of the business where the business architect is being asked to provide “insight.”  While a business architect is quite capable of applying proven research-based methods to a problem area, and producing insight into the problems of that area, asking a BA to produce insight is dangerous, for both the BA and the project team.

    1. There are literally hundreds of different tools that a business architect can call upon to produce insight.  Without clear definition of the project or workstream goals, the Business Architect is left to his or her own devices to (a) select the insight tools (one or more) that could be useful, (b) decide when to use them, and (c) hope that the business would find the insight produced to be “consumable and practical” for their needs.  In this case, the likelihood that the project will view the output as a “waste of time and money” is high.
       
    2. The opportunity to produce “insight” is so vague that it is very likely that the output produced by a BA will be too detailed, or too high level, to meet the expectations of the business customers.  Disappointment, distrust, and a rejection of the value of business architecture, as a practice, are the likely results.  This is very bad for the business architect, and for the effort to increase the perceived value of enterprise and business architecture.
       

    When you find yourself in a situation where you are being asked to provide insight, get with the business sponsor and see if you can get the entire project focused on answering the following questions, and get this all written down in a short “charter” that everyone on the project team buys into.

    1. What decision needs to be made?
      1. Is this a decision that will need to be made more than once?
      2. How often is this decision made? 
      3. What is the risk of making the wrong decision? 
    2. Who is accountable for making that decision?
    3. What is the relationship between the business architect and the decision maker? 
      • Direct relationship: (the decision maker has asked for the BA specifically), or
      • Indirect relationship (the BA’s insight will be given to another person to pass up to the decision maker)
      • Aspirational relationship (Is someone hoping that a BA artifact will magically find itself into the lap of the decision-maker) 
    4. What information does the decision maker (expect / desire / require) to make an appropriate decision? 
      1. When will the insight be required?
      2. What format should it be delivered in?
    5. What activities can the business architect reasonably expect to accomplish?
      1. Will the culture of the business support the BA in their role?
      2. Does the business need to prepare for these activities?
      3. How much stakeholder time will be required for the BA to complete these activities?
      4. Are key stakeholders available for interacting with a BA?  Are other resources required? 
    6. Has the decision maker taken a specific dependency on the business architect to produce the insight? 
      1. Will he or she wait until the insight is produced? 
      2. Will the insight be respected as coming from a trusted authoritative source?

     

    Of course, this is good advice for any project: know the problem you are trying to solve before you spend a bunch of time solving it.  However, I find that business folks often have trouble seeing the strategic work of a business architect in the context of a “decision support project” and therefore may overlook this basic level of understanding.  If this is the situation you find yourself in, don’t ask for the charter to be created by someone else.  Create one and go to the business sponsor to sign off on it. 

    Creating a charter can go a long way towards clarifying the request for insight, and thus keeping the business architect out of hot water.

  • Inside Architecture

    Can Enterprise Architecture be effective if we ignore the needs of the customer?

    • 4 Comments

    In my prior post, I pointed out that the Zachman Framework is limited (fatally flawed even) by the fact that there is no row to represent the customer viewpoint.  In the ensuing discussion, it became obvious that I had not explained why that matters.

    Enterprise architecture is described by many monikers:

    • Bridge from Strategy to Execution
    • Alignment between the Business and IT

    But why do we need to bridge strategy to execution, or bridge business to IT?  Because customer needs change, and therefore businesses must change.  If nothing is changing, then there is no need for EA.  Of course, for most of us, that is not a situation we will likely face. 

    The direction that a business should go is the combination of three things: where there is passion, where the business is positioned well, and where the customer sees value.  (this is an abbreviation of the Hedgehog concept).  There is a risk, a rather large risk, that the things the customer values will change so radically that the business will find itself passionate and positioned for success in a business that the customer doesn't care about.

    And that is why the Zachman framework is interesting but not useful.  It does a good job of modeling the present, and the internal intent of the business, but not the customer's needs and therefore, not the rationale for change.  Put another way, the ZF does a good job of documenting the Inside-Out view, but fails completely to allow anyone to model the Outside-In view.  This is simply not effective at the level of business strategy.  If we are going to be effective at bridging strategy to execution, we need to be effective at modeling strategy.  But to model business strategy, we need to represent the needs of the customer. 

    If we don't capture the needs of the customer, we can build the most effective roadmap... to the wrong destination.  We would have no way to advise the business that the strategy is brilliantly and wildly incorrect.  If a business was made up of little robots, doing everything the executives say, that would not matter, but in most successful businesses, we expect and require that the entire company be tuned to the needs of the marketplace. 

    In that context, any strategy that leads away from the needs of the customer will be questioned, delayed, and dissipated.  That is probably a good thing, but it also means that the business will waste valuable energy fighting itself.  Leadership will say "head North" and the managers will say "but the customer is East" and no one will move at all.  Time is wasted and resources are wasted.

    As Enterprise Architects, we can no longer take a tactical view and simply accept that business strategy, by definition, is correct.  The rest of the enterprise will not effectively implement a strategy that does not take into account the needs of the marketplace, so we will not be effective at linking execution to strategy in those cases where strategy is wrong.

    In the modern world, where we empower employees, and trust ourselves, and actually require ourselves to think, we must expect resistance if EA amplifies a wrong-headed strategy.  If we are to empower execution, we must also empower the executives to examine business strategy in light of customer needs.  We must do more than model the goals and processes... we must capture the business model, and all of the influencers, drivers, and assessments that surround it.  The customer is not middle-management, where the initiatives are formed.  The customer for EA is, and must be, the senior executives where strategy is formed, and where strategy must be examined, questioned, and thoroughly modeled.

    That is why I'm passionate about the business motivation model.  That is why I believe that the Zachman framework is interesting, but no longer sufficient, for enterprise architecture.  EA must be able to capture, model, and examine the influencers for a business, and place the business strategy into context, if we are to be effective at aligning the execution of the enterprise to that strategy.  In an empowered enterprise, we have no choice.

    Business has changed.  Enterprise Architecture must change as well.

  • Inside Architecture

    Zachman’s Fatal Flaw: No Row for the Customer

    • 16 Comments

    John Zachman’s Framework for Information Systems Architecture, later renamed as the Zachman framework for Enterprise Architecture, is a commonly used taxonomy of business elements and artifacts used by Enterprise Architecture teams.  It is clearly in rapid decline as the TOGAF framework, derived from TAFIM, is being widely adopted as the Enterprise Architecture framework of choice.

    Unfortunately, many of the concepts of Enterprise Architecture were established by adopters of the Zachman Framework.  This is a shame, because the Zachman Framework is fatally flawed. 

    What is the fatal flaw?  As you can tell from the title of the post, the flaw is an “Inside-Out” perspective on the enterprise.  The flaw is the description of an enterprise from the viewpoints expressed in the rows of the framework itself, variously described as the Planner, Owner, Designer, Builder, Programmer, and User viewpoints.  All of these viewpoints express the enterprise in terms of how these different roles understand it… but not in the way in which an enterprise is actually relevant. 

    A business that does not provide value to a customer is doomed.  Therefore, it is critical to develop models of the enterprise that reflect the viewpoint and perspective that is of critical importance.  Unfortunately, while the Zachman Framework is large, it has a fatal gap: it demands many things but fails to demand the creation or classification of business elements from the perspective of the end customer. 

    One could say that the customer viewpoint is represented not by a row, but rather by a column: the “why” or motivation column.  That is nonsense.  We need to answer each of the interrogatives of Enterprise Architecture (What, How, Where, Who, When, and Why) from the perspective of the customer.  The customer must be a row.  It is not.

    Now, time to retrain all those folks who are bringing Zachman “thinking” with them…

  • Inside Architecture

    Our own worst enemy: BPM pros tell horror stories about working with EA

    • 4 Comments

    I recently asked two questions on LinkedIn.  I asked BPM professionals what they thought about working with Enterprise Architects, and I asked EA folks what they thought of working with Business Process Managers.  The results: BPM professionals want to work with you, but you have to meet them half way.

    The number one complaint against Enterprise Architects?  Focusing on technology instead of business. 

    Kenneth Beard of South Africa tells of Enterprise Architects who “think that EA = ITEA and BPM = name of a software … tend to live in silos, fight turf wars amongst the technical population, and are often at odds with the business they should serve, making it difficult to work with them.”

    John Segal of New Zealand says

    “in my experience the majority of so called EA's are IT focused and hired to be so. Consequently they are typically interested in the automated solution aspects of BPM rather than what is to my mind its primary importance as a process design and improvement meta process.”  He goes on, “So, with IT oriented EAs emphasizing a technology solution led concept of BPM, they can effectively become an impediment to deploying BPM as a core business meta process.”

    If John feels that the majority of EAs are an “impediment,” then we may have only ourselves to blame.  After all, many of the responders were Enterprise Architects, and surprisingly, they agreed.  Adrian Gregoriu of the UK shares this bit of insight:

    “BPM and other process improvement efforts like Six/Lean Sigma, business process and organization alignment to strategy are left out of the definition of EA and business architecture development. In my work, I have collaborated with BPM people and efforts but could not ever engage EA people to work with them. After all, contrary to what many claim, EA seems to be mostly about IT, unfortunately.”

    Alas, all is not lost.  There were also stories of success, when conditions were right. 

    Kenneth Beard shared a positive opinion as well.  He prefers to work with Enterprise Architects who “understand that real EA is a set of layers for process, information, application and technology that are inseparable and work in concert & must be managed as such.”  In this environment, Mr. Beard finds that Enterprise Architects view BPM in its proper role, “BPM is seen as a customer focused initiative to improve the performance of the real enterprise architecture” and he finds these architects to be “strategic level thinkers who share an integrated view and are a pleasure to work with, and they get results.”

    Alexander Samarin of Switzerland tells the story of carefully, over time, educating a team of Enterprise Architects so that they can understand how best to use BPM in their work.

    “At first, I explained to the team how BPM can solve many of typical IT problems (rescuing a couple rotten projects helped me a lot). Then, in each opportunity -- a difficult problem, new enterprise-wide project, developing principles, writing procedures, etc. -- we applied the power of BPM (discipline, tools and practice). We gave seminars, built demos, shared our knowledge, etc.  After about 2,5 years, the first BPM-centric solution has been selected (via a tender) for the new information system of a governmental service. “

    There is a great deal of insight here.  Clearly, the combination of Enterprise Architecture and Business Process Management is valuable, when it is applied right.  Clearly, Enterprise Architects are, as a group, missing out on that value.  Some folks are taking the time to educate, while others wait patiently for an EA who actually has a clue. 

    There are surprising synergies.  Here is Kenneth Beard again, sharing his opinion about how important an EA repository is. 

    “we need to appreciate that business leaders with different experience find it hard to grasp. Most believe it is simply too complex to document and maintain the information assets. But the diversity of each layer of the EA plus the know-how of how they work in concert is vast, and is exactly the reason why this knowledge needs to be managed in an integrated repository, with strict configuration management and change control procedures. Otherwise it remains in the heads of various SME's and at best partly documented in numerous unrelated formats that decay with time or are lost when people move. The benefits of having it in one home are vast, enabling enterprise performance management, despite having a massive knowledge asset.”

    Lastly, our friends in the BPM community have some advice on how to work well with them… focus on the customer!

    Kenneth Beard tells us that “the emphasis should be on the customer experience so successful outcomes translate into meaningful results along with value for the business.”  John Macdonald of the Netherlands provides similar advice, “the intended customer experience should be the start point, then assemble the parties and methodologies required to bring about the transformation. EA, BPM, L6SS, Project Mgmt etc all have vital contributions to make.  The change leader should be the party responsible for customer satisfaction, employee well being and profitability, the team should be made up of a cross section of process (business), IT and employee competence experts.”

    What is your experience when working between EA and BPM roles? Please share your story!

  • Inside Architecture

    A Rough Primer on Enterprise Architecture

    • 0 Comments

    I produced this page after fielding a question for a succinct definition, in three pages or less, describing what Enterprise Architecture is, and how it is valuable.  Unfortunately, I don’t have time at the moment to pull all the various strands of information together as a nifty three page document.  What I can do, at this time, is provide a series of links to prior articles that can help to describe and define Enterprise Architecture from my point of view. 

    First off, let me say that Microsoft does not favor, endorse, or promote any particular EA framework.  We have had experience with numerous approaches and frameworks, have developed our own metamodel and framework for internal use that guides our strategic planning.  Our consulting organization, Microsoft Consulting Services has many Enterprise Architects among the ranks.

    Selected Links:

    Nick Malik (me):
    • Value of EA (link), (link),
    • Functions of EA (link),
    • Double Iron Triangle of EA (link)
    • Job desc for Business Architect (link),
    • EA vs. SA (link),
    • IEEE1471 and EA (link),
    • measuring EA (link),
    • On being relevant (link)
    • Multiple interacting teams (link)
    • Review of TOGAF 9 (link),

     

    Gabriel Morgan:
    • EA vs. SA (link),
    • traceability (link),

     

    Mike Walker:
    • EATK article (link)

     

    And of course, there’s the Wikipedia’s entry (to which I have contributed) http://en.wikipedia.org/wiki/Enterprise_architecture

    Here are some useful blog posts from some friends in the blogosphere:

    Leo de Souza: EA Maturity Model (link)

    Chris Potts: Definition of EA (link), Moving EA out of IT (link)

    Adrian Grigoriu: Review of Gartner Emergent EA (link)

Page 1 of 1 (5 items)