Inside Architecture

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

April, 2008

Posts
  • Inside Architecture

    Rant: Avoiding the Problem Duck Hunt

    • 3 Comments

    Just a rant.

    "I've got me a shotgun... let's go find a duck!" 

    I call that a "problem duck hunt."  You have a solution, and you go hunting for a problem.  When a flock of "problem ducks" fly by, you fire away, hoping to hit something.  Doesn't really matter what you hit. 

    Software vendors do it all the time.  It doesn't matter what the tool is, the tool vendors will shop around for general problems and attach their tool... Look at all the good things our tools do!

    My view: Tools do squat.  People do work.  Tools help them. 

    If the people aren't aligned, incented, supported, and empowered to solve a problem... the existence of a tool will make very little difference.  The lack of a tool can slow them down, but the presence will NOT speed them up.

    So when I saw this banner ad, from a competitor, I had to post this blog.  I blotted out the names of the competitor and the analyst that they used.  I suppose we do it too.  I'm ranting about the tactic. 

    BPM_SOA_ad

    In case you can't read the ad, the headline says "Business Process Management and SOA" and in small print, "Follow the SOA Roadmap, learn from <analyst> and others how to tightly couple your IT efforts with business goals."

    SOA and BPM are good, but they don't align IT to business.  People do.  Those people are performing a function.  The function is called Enterprise Architecture.  A SOA tool is used by an Enterprise Architect.  A BPM tool is as well.  Nice when they are together.

    But the tool doesn't solve this problem.  The people do. 

    Technorati Tags: , ,
  • Inside Architecture

    Merging Capability Modeling with Process Modeling

    • 18 Comments

    Gentle reader: can you help me to solve a debate?

    Introduction

    Many companies have adopted the practice of capability modeling in the past few years.  Often, this is done to align the portfolio of business initiatives (and often, IT projects) with corporate strategy.  Many folks, including our own Microsoft Services Business Architecture (MSBA) consultants, view capability modeling as both a great business architecture practice (it is) and a great way to align SOA to your portfolio (it is that too).  Internally, Microsoft IT has adopted capability modeling with a great deal of success. 

    Unfortunately, the way that capability modeling is described today, there is an element of business architecture that is "outside" the capability mindset: business process.  Capabilities are often defined as a 'mapping' to business processes, but there is little or no attempt to include process modeling in the capability modeling approach. 

    This could cause some confusion if you are not careful.  Many companies have long-standing efforts to describe, optimize, and reuse their business processes.  These efforts are led and guided by various methodologies including six sigma and lean engineering.

    So if your company is a process oriented one (or becoming a process oriented one), how do you fit in capability modeling?  Do these two methods conflict? 

    I do not believe that the do.  In fact, I believe that they are quite complimentary... but you have to take a moment to see how they relate.  The debate that is going on at the moment: how do they relate?   That's where I'd like your opinion.

    Perspectives

    In process modeling, you divide up the things your company does into high level cross functional processes (like selling, marketing, fulfillment, etc).  Breaking down processes into sub-processes, and sub-sub-processes, you eventually get down to activities.  (I use the same definition as the Workflow Management Coalition: an activity is a unit of work.  Think of it as the leaves of the process tree.)  Process modeling is essentially concerned with how these activities are done.

    These activities are interesting from a SOA standpoint, because the activities are where you actually perform automation.  You connect services to these activities.  This is where work is done.

    Unlike process modeling, capability modeling attempts to separate the "what" from the "how."  The capability view is quite understandable for the business, and unlike process modeling, doesn't require considerable training in order for the business to describe itself.  I've seen a group of four business architects analyze a business, and adapt an existing capability taxonomy to it, as a PART TIME EFFORT, in a couple of months.  All this while holding down their other responsibilities.  If you don't have a group of architects to call upon, like we do, tailoring such a hierarchy can be done in a matter of weeks using a full-time Microsoft consultant.  Maintaining the hierarchy is fairly simple.  Using it is quite valuable for project portfolio alignment, both in the business and in IT. 

    With capability modeling, you create a hierarchy of the company's capabilities.  You then identify the capabilities that best align to corporate strategy, and which one of them need the most work.  Focus your work there, and you get a big payoff through focused investment.

    Microsoft is an interesting bird, but I don't think we are unusual.  We want to do both.  Which unfortunately means that, unless we are careful, we end up with two hierarchies.  No one wants to maintain that, and we don't get consistent benefits if process modeling and capability modeling don't work together.  But how to combine them?

    There are two opinions within this company. 

    Opinion A

    In this understanding, the notion of "Capability" is a good way to create the top levels of a hierarchy, while process creates the lower levels.  This requires discipline because you have to limit the hierarchy of capabilities to one or two levels.  On the other hand, it is not possible, after just a few levels, to describe "what" a company does without making assumptions about "how" the company does it.  This view is illustrated with the diagram below.

    image

    Opinion B

    In this understanding, the notion of Capability is related to the objectives of specific organizational units within a company.  This is a totally different perspective, in that we are intentionally saying that capabilities should look like the organization itself, an the business should "see itself" in the capability hierarchy.  There is little or no attempt for capabilities to be mutually exclusive from one another, and they can go down to five or more levels of depth.   Therefore, the fact that the support division sells support contracts, while the retail division signs up retailers using retail contracts, both of which 'sell stuff' is not a problem, because we are less concerned with redundancy in the capabilities themselves.  Where we find uniqueness is in the activities.

    In this view, activities are a shared and linked resource, managed in a database of activities.  A functional view would assign particular activities to a particular business unit or department, which reports in an organizational chart up to a senior leader and eventually the CEO. 

    Business processes are ways to thread those activities together, respecting the fact that sometimes different departments MUST perform the same activities, but that they don't have to use the same processes to do it. 

    image

    What do you think?

    These two opinions are quite different.  Perhaps they are both quite useful, and the choice of which to use depends on your company.  Perhaps, one is optimal and the other is suboptimal, and you should avoid one and use the other.

    I'd love to hear your opinion.  Personally, I like "Opinion B." But I reserve the right to be wrong on this.

    Your turn to vote.  I'd love to hear your thoughts.

  • Inside Architecture

    Measuring Maturity in BPM - Automation is the wrong answer

    • 6 Comments

    I'm working on a BPM effort right now.  I've spent a bit of time talking to business users inside my company about Business Process, and how they'd like to see us become more of a process oriented company.  Then I compare what they are saying with what the IT industry values, and measures, and I'm seeing a huge gulf.  Basically, IT doesn't get it.

    Aside: there's real value in becoming a process oriented company.  For folks who need a little convincing, consider checking out this little book (BPM is a team sport, by Spanyi) from your local library.  It's dry, but a lot less dry than most BPM books... fairly consumable.

    Part of my effort is to understand the answer to this question: Assuming we all agree that BPM is a good tool, how do we know if we are using that tool well?  In short, how do you measure the adoption of BPM?

    And there, to answer that question, is a Maturity Model from Gartner.

    And it is wrong.  Ouch.

    First some background:

    It has been almost two years since Gartner unveiled their BPM Maturity Model at a Gartner conference.  Here's an interview with Jim Sinur, one of the two authors of the approach.   Unfortunately, I can't put a graphic up on my blog without violating Gartner's IP, but the interview provides some insight:

    Intelligent Enterprise (IE): Can you recap the maturity model you unveiled at the Gartner BPM Summit?

    Jim Sinur (JS): There are five stages: process understanding, process control, enterprise execution, corporate performance management and, last, competitive differentiation. You start modeling and measuring in the process understanding stage. In the second stage, you're doing more optimizing and tweaking. This is where you take advantage of rules management and optimization. In the third stage, you craft a cross-enterprise process architecture and maybe extend that to your trading partners. In the fourth stage, you instrument a framework of corporate performance management goals against the actual process.

    Let's dissect that, shall we?

    • Level 1 - Modeling and Measuring. 
    • Level 2 - Optimizing and Tweaking
    • Level 3 - Cross-Enterprise Process Architecture
    • Level 4 - Instrumentation of Corporate Performance Management Goals
    • Level 5 - competitive differentiation

    OK, here is where I make a confession.  I have read the original material.  I won't quote directly from it, but I can assure you that it describes the path from Level 1 through Level 5 as a series of 'events' that trigger a growth in maturity.  Understand the events, and the competencies, and you have a maturity model.  

    In other words, if you are at Level 1, and your business is happy creating models and measuring things, you may reach up one day and say "hey look!  We measured the time it takes to issue a purchase order, and we think we can improve it."  And now, you are on your way to level 2.

    Does anyone ask why the business would put in a measurement in the first place?  It costs money to collect information.  Why do this?  Because... they want to measure a process.  Reality check: process orientation comes first, probably in a small setting, long before measurement takes hold.  So you can't say that metrics lead to process management, if process management is a prerequisite to metrics! 

    So what brings in process orientation if it is not for the sake of becoming efficient?  I'll get to that in a minute.  The important point is that a maturity model is a system of measurement. And if you want a particular outcome, it pays to measure the right thing.  The Gartner BPM Maturity Model measures the adoption of BPM for the sake of efficiency

    Let me harp on that for a moment.  In the Gartner model, we do BPM to become efficient.  Each step describes motivations, and outcomes, in terms of achieving the goal of operational efficiency.  We are more mature when we have created an end-to-end view for the sake of efficiency.

    Yet, as I've spoken with people around this company, people who use process management to get results, not one person speaks about trying to achieve efficiency. 

    That doesn't mean we don't care.  We do.  But that is not how to measure BPM, because if you do measure BPM on the basis of efficiency, you are missing the big picture.  And that is why the Gartner BPM Maturity model is wrong.  It measures the wrong thing.

    Still holding your breath?  Let's go back to the key question: What brings in process orientation if it is not for the sake of efficiency?  Why does the business spend money on developing process models?

    Two answers, both good:

    1. Customer retention.  Business Process modeling helps you to understand the customer's processes.  With that understanding, you can communicate with different business teams, in order to improve the customer's experience of the company's product.  You can change your processes so that the customer doesn't have to jump through hoops.  They feel valued.  They buy more products.  Improving the customer's experience increases the top-line revenue while reducing attrition.  Big win. 
       
    2. Time to market.  Process modeling allows the company to coordinate across different business teams.  With that understanding, you can bring a new product or service to the market quickly, because you can coordinate the efforts of many people. 

    These are the reasons that a business will initiate using a process-oriented approach.  The Gartner BPM Maturity Model does not measure either one.  How well do you know your customers?  At what level of scope do you perceive customer issues: departmental, divisional, corporate?  How responsive are you?  Can you meet the needs of different customers?  To how fine of a level? 

    Perhaps there are two models: one aligned to understanding the customer, and the other aligned to understanding the internal processes for the sake of communication, understanding, and consensus.  The latter method will eventually spawn a discussion of efficiency, but not right away.

    The only thing more dangerous than measuring nothing: measuring the wrong thing.

    Sorry, Gartner.

  • Inside Architecture

    The ROI of Building an Internal Community

    • 0 Comments

    One thing we sometimes forget to do... make time to make relationships.  It is good when we do it right.

    Large organizations are curious things.  Some folks like to think of a company as something akin to an organism, with a heart and lungs and nervous system, all supporting the same goal.  Some companies certainly behave like a single organism.  On the other hand, larger companies tend to have wide product lines and many sources of revenue.  Large organizations behave less like an organism than a community.

    To extend the analogy, different parts of the company are like people in a family.  We can agree about what the family values are, and we can see the effects of culture on the family, but each family member is motivated differently.  Each has their own style.  And so it goes in large businesses: each division has their own style and their own idea of success.

    Of course, with a business, we can go one level deeper.  It doesn't make sense, in a family, for my kidneys to hold a 'conference of kidneys' and communicate with my brother's kidneys to discuss how to be better at filtering blood.  :-)   But with business, each of the internal functions are run by intelligent, self-motivated, professional human beings.  And getting them together makes a lot of sense.

    Inside MSIT, the EA team just finished running a community event that we called "Dynamic MSIT."  It was a good conference, with about 200 IT architects and 50 or so of their close associates, all employees of MSIT.  We had presentations from our new CIO, our new Chief Architect, a Distinguished Engineer, and a leader from the evangelism group.  But more importantly, we had time to build relationships.

    I've met nearly everyone in that room before, many in long extended conversations.  I knew them and trusted them.  But if we have a conference where I sit next to someone, but I don't get a chance to talk to them, then what was the point of the conference?  I need to do more than "see" a face to keep a relationship working.  And that's what we did.

    The great success of our internal conference wasn't the presentations.  It was the 'white space,' the large gaps in time between presentations.  These gaps ranged from 45 minutes to an hour long.  I'll be honest: the gaps were as valuable to me as the talks... maybe more.  I got a chance to reconnect.  I shook hands and said names and asked about projects and reminded myself of how much fun it is to work with the best architects on the planet.

    So here's to the gaps... and here's to building an internal community.  May we fill that 'white space' with friendship, trust, and teamwork.

Page 1 of 1 (4 items)