Inside Architecture

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

July, 2009

Posts
  • Inside Architecture

    Work-back Enterprise Architecture

    • 5 Comments

    We are all familiar with the notion of a work-back schedule: a date driven schedule where we start with the end in mind, and work back to the present time, figuring out what tasks we can accomplish in that time frame.  Anything that doesn’t fit, we don’t do.  Creating a work-back schedule is an iterative process.  You describe the results at the beginning, but if you cannot deliver those results in the time you have, you figure out what you CAN deliver.

    I was having a chat with another architect today who asked why we don’t do this for enterprise architecture… and I didn’t have a good response for him.  My viewpoint has often been to solve a small problem and “scale out,” (kind of EA + Agile), but his question was interesting…

    Why don’t we jump ahead, four years, and describe the “Ideal” state, and then WORK BACK to today, describing what each of the steps would be to get there.  And then iterate.  If we cannot get to the “Ideal” state in four years, answer the question “What can we do in four years?” 

    All too often, I’ve seen enterprise architecture described from the “Ideal” state with no respect for time.  It is as though the Ideal state is some goal hovering out in the ether, with no connection to reality.  Thus, it is easy to criticize EA as being detached from reality, because the models ARE detached from reality.

    What may simply be a better approach is to describe an Ideal state based on principles and best practices, and then temper that with a work-back process, just as we would for a time-bounded project plan. 

    With a work-back approach, the EA team could create multiple possible “future” states and get IT leadership to pick one, rather than having everyone buy off on an ideal state that is pretty, but unrealistic. 

    Once you have an attainable “future state” model, then hide the “ideal state” in a desk drawer.  Don’t refer to it.  Use the realistic version that is actually reflective of the budget, appetite, skills, flexibility, and political realities of the IT organization.

    The realistic model becomes the “future state model” that is discussed, and described, and shared, and evaluated.  It is the one you discuss because it is possible, not because it is “right” or “ideal.”  Possible trumps Right. 

    Simple.  Makes sense.  Yet, in all the discussion of EA that I’ve read and walked through, including the various EA frameworks that I’ve studied, I’ve not yet seen a description of using a work-back process to describe the future state for EA models. 

    What are your thoughts?   I’m interested to know.

  • Inside Architecture

    When is the “flow” in a use case part of the system requirements?

    • 4 Comments

    There is an odd relationship between the concepts of a use case and a requirement.  A use case is a structured chunk of text, useful for understanding and evoking requirements from the end user.  It is also a way to place those requirements into context (as in “this requirements is attached to step 3 of UC41”).  There is also the “flow” itself… the order in which information is entered and the “screens” that the user enters them into.  In many cases, a use case is quite explicit about the flow, and the customers will spend a good bit of time describing that flow.  In other cases, the flow is incidental.

    So, I can see three types of “requirements” that are part and parcel of use cases:

    1. Declarative requirements attached to the use case: these “statements of requirement” may be implicit in the structure (as is the case with preconditions and post conditions), or may be attached to the use case itself. For example, if we are creating a workflow system, we may see a declarative requirement attached to a use case saying something like this: “When a user logs in to the workflow system, the default screen is the task list.”  The interesting thing is that this requirement could be attached to any of a dozen different use cases.  It is universally understandable.
       
    2. Implicit requirements attached to a step in the use case: these are requirements for user interaction, data fields, and functionality that are implicitly stated by the description in the use case, without being declared.  For example, if we describe a use case in a workflow system where a person can “assign” a task to someone else to perform, we could see a step like this: “Step 3: from a drop-down list, select the name of the person to whom this task will be assigned, or enter their name in the text box”.  From that, we could create some declarative requirements like “users may assign a task to another user,” “the user will be presented with a list of team members to whom it is appropriate to assign a particular task, based on the task type,” and “the user may enter the name of a person to assign the task to.”
       
    3. The flow of the steps in a use case:  In the use case description, the business analyst is describing a sequence of steps that the user has to go through in order to perform a specific task (or, as I like to say, complete a specific system interaction).  That sequence itself, with the implicit order of “what information is provided first” and “what information is provided next” is often created by the analyst without regard to the difficulties of asking for information in that particular order.

    I specifically want to focus on type 3: implicit order.  The analyst creates this order.  In some cases, the order was created in order to “tell a story” and it is NOT a requirement from the end user… it is a requirement from the analyst.  In other words, the customer doesn’t care about the order itself.  In other cases, the customer and the analyst will carefully create that sequence of steps, focusing time and attention on the order in which information is provided.  The customer cares a great deal about the order of information (usually for valid reasons).

    Here is where there is a potential for misunderstanding.  When a use case is delivered to a development team, the analyst needs to make it clear whether the order of steps is a “useful story” or a “well considered requirement.”  This indicator is missing from nearly every use case I’ve ever seen described, yet there is an interesting effect here.  Developers will read a use case and will make decisions, in code, on the basis of what they see.  Some will take all sequences in the use case as a verbatim requirement, even when it is not necessarily a requirement from the customer.  Others will look for ways to create interesting and insightful interfaces, regardless of how hard the analyst worked to create the use cases.

    Testers have a problem with either option, because they are often out developing test scenarios and estimating test effort from the requirements, without consideration of the developer’s choices.

    And a developer who takes the flow of a use case as a verbatim expression is the kind of developer that would never have developed the original iPhone interface, because no analyst in the world could have designed that.  The iPhone interface was developed by a design team that took the time to reconsider every aspect of user input on a touch device.  It was not dictated by a business user through a use case process.

    Suggestion for improving the standard structure of use cases:

    There should be an indicator of some kind attached to the use case that says one of the following options is available to the design and development teams.  Let’s call this indicator “Requirements for Flow Design” and the indicator will have one of the following values:

    • Specific – the analyst and the customer carefully considered both the order of steps and the interface controls that they want to see, and the developer should follow the flow and controls described as closely as possible.
       
    • Sequenced – the analyst and the customer carefully considered the sequence of information and interaction, but the customer is flexible on the interface controls that the developer may use when implementing the flow.
       
    • General – the analyst and customer agree with the flow, but are willing to consider any alternative flow that meets other requirements for information and functionality.
       
    • Suggested – the analyst created the flow as a story to elicit requirements.  As long as other requirements are met, the flow is optional.
       

    This removes some of the guesswork about “customer intent” that is inherent in present use case design.

  • Inside Architecture

    Very Funny – Trailer for Office 2010 – The Movie

    • 0 Comments

    Even non-geeks will get a huge kick out of this, and I’m betting that most of the folks who follow my blog will find it as funny as I did… Word up. 

    My only question for the MS Marketing guys who finally loosened up enough to pay for a viral video: What Took You So Long!

    Special kudos to Traffik, the agency that did the work.  Excellent Job!

  • Inside Architecture

    Why strategy statements are necessary, but insufficient, solutions

    • 0 Comments

    I had the opportunity recently to review an excellent article in the Harvard Business Review (HBR) on strategy development, and consider the notion of a business motivation model with respect to how a strategy is constructed. (“Can you say what your strategy is?” by David Collis and Michael Rukstad, Harvard Business Review, April 2008, link)

    For those folks who are not familiar with a business motivation model, the goal of this kind of architectural artifact is to understand the different “things” that motivate an enterprise and trace the various behaviors of the enterprise that are engaged (or not engaged) to react to those things.  Things (not a technical term) refer to influencers like competitive opportunities, drivers like strategies and objectives, and business models that describe the elements of the business itself.

    One thing that is clear: traceability matters.  Traceability is the ability to not only say “what” we are doing, but “why.”  It is the ability to trace our activities back to motivators that we can all agree on.

    The HBR article cited above provides a clear argument for rewriting strategy statements in a different way, one in which the traceability of the strategy is described in the strategy statement itself.  For example, it would be “OK” for a ‘printer’ company to use a strategy like this: 

    “Increase market penetration in the North America SOHO segment by 20% through improvements in product usability, partner marketing, and customer relationship management.”

    On the other hand, according to the article, it is even better to lengthen that sentence dramatically.  An appropriate rewrite would include, in the strategy statement itself, the traceability to a key differentiator for the enterprise:

    “Increase market penetration in the North America SOHO segment by 20% through improvements in product usability, partner marketing, and customer relationship management leveraging our long-term relationships with customers and deep awareness of their business needs.”

    I must confess that it makes sense to care about this particular aspect of strategic traceability.  After all, creating a strategy that does not trace to a fundamental motivation around improving the health, competitiveness, and financial stability of a company would be particularly corrosive.  A bad strategy can be worse than no strategy.

    The solution that the authors suggest is useful in an environment where the business does not already know who they are, and what aspects of their business are key differentiators for them.

    If a business is very aware of their key differentiators, then extending the strategy statement to include them is redundant and, dare I say, mildly counterproductive.  The notion that a long-winded sentence carries sufficient weight to drive a change, outside a complete understanding of the business itself, is indicative of two possibilities: (1) an enterprise with only one business model, or (2) a business with fairly chaotic thinking.

    In effect, if your business is very simple, but you don’t believe that everyone understands it, then this is good advice.  Also, if your business is in chaos, this is excellent advice.   In both cases, you need the strategy statements to communicate and provide clarity.

    On the other hand, if your business is well organized but competes in a rapidly changing business environment, using a complex multi-faceted set of business models, then I have some concerns.

    The limitations of sentences

    Long sentences as strategy statements are a good idea, if there is no conflict between them.  In a business with one business model, this is a realistic goal.  It would be inappropriate for the leadership of the business to issue strategies that overlap or compete with one another if there is only one business model.

    On the other hand, many businesses, including Microsoft and most of the rest of the Fortune 100 corporations, have many business models within the framework of their enterprise.  These different businesses will have overlapping customer bases, different products, and potentially some radically different ways to make money.  For example, as Microsoft embarks on Software Plus Services, we make money on the sale of licenses of Microsoft Exchange.  We also make money on selling access to an online version of Microsoft Exchange (Business Online Services) that many businesses find preferable to running their own e-mail infrastructure.

    You can add only so much clarity to a business by stretching out the length of the strategy statements to include additional words, as the HBR article suggests.  Some things cannot be worked out using long sentences, however.  Long sentences to do not clarify overlaps, or what may appear to be competing strategies.  Long sentences do not reduce internal conflicts or clear up customer misconceptions or make it easy for the sales force to explain what your company does, especially when your company does MANY different things, for different people, in different ways.

    Perhaps having longer strategy statements do work in chaotic businesses.  I’m not sure.  I believe that the problems of poor role understanding, poor organizational discipline, and poor visibility into the success factors of others are each big problems typical of a chaotic business.  If it were my call, I’d want to solve those problems before I focused on clarifying business strategy statements (although, in some sense, clarity may help).

    Traceability through models

    So let’s assume, for the rest of this discussion, that you can drive behavior from a strategy because your business has the organizational discipline to actually care about these statements.  Let’s assume that the problem is this: you need your strategies to be executed better. 

    Now, let’s throw in a complicating factor: your enterprise has many business models… many different ways to make money.  If that is the case, then there may be effective ways that work for more people, in more ways, than the one suggested in the HBR article.

    One method for building effective, aligned, and actionable strategies to model the business using a rich mechanism like the Enterprise Business Motivation Model.  This allows direct traceability between the competitive needs of the business model, the influencers that affect the business, and the drivers of change that propagate through an organization.

    The method advised by the HBR article performs some of that traceability.  According to the article, some of the differentiation of the business needs to be drawn into the strategy statements themselves.  This is not bad advice.  However, the author is selecting one particular path of traceability (product differentiation to strategy) and neglecting others. 

    With a model, you can draw this path, and many more.  Modeling is necessary because business strategies are simply one of the tools of change, and a full and rich motivation model, like the one described in the MSDN article, clarifies the traceability without sacrificing all of the relationships in favor of a single important one.

    Having a full model doesn’t fix a chaotic business, but it is a useful first step.  On the other hand, a business without a rich and fully described motivation model will have a harder time reaching the maturity that they need in order to compete, and succeed, in the marketplace.

    Once you have developed the model, you have something very valuable.  The model lets you demonstrate how the strategies are connected to the various influencers, in the context of the (potentially many) business models of an enterprise.  It provides much of the rich context needed to prioritize business objectives and deal with competing demands for resources, time, and mindshare.  With a broad notion of traceability in place, the need to “pad” the strategy statements themselves may diminish.  More importantly, strategy statements can be shown to derive from many different paths of traceability, not just one of product differentiation.

    Conclusion

    The advice from the Harvard Business Review is good advice.  There are many situations where a set of long strategy statements is a good thing.  Companies that want to use strategy statements as an education mechanism, and not just a motivation mechanism, can use their advice to full effect.

    The HBR article does not, however, take into account the many interesting kinds of traceability that may be useful to the business.  A full and rich motivation model can start where that article leaves off and go much further, allowing the business to describing its motivating factors in more than one manner (regardless of how useful that manner is). 

Page 1 of 1 (4 items)