Freigeben über

Standardization works with a limited, and rational, scope

  • Artikel

I've been on a roll lately, calling for the creating of a standardized approach to the partitioning of Line-of-Business apps. 

One reader commented that we are a long way from "plug and play" integration.

The real answer is more subtle than that. 

Not all business are alike.  Therefore, one standard for all software doesn't make sense.  I'm not calling for one standard for all software.  I'm calling for one standard for some software.  Specifically, LOB supporting software.  Allow me to explain.

First off: I'm talking about Line of Business software.  So, if am excluding "storage in the cloud" or "hosted collaboration" services (like hosted e-mail).  Not because they are not important... but because I'm looking at a different problem.

image

Line of Business applications are used to perform specific functions for the business.  Particular steps in business processes are automated using LOB software.  These processes are focused on things like "finances" and "human resources" and "order entry."  Useful things. 

But what are these "things?"  How do we describe the "things" that a business needs to define it's operational world-view?  These "things" are business capabilities.

A business capability is a description of the stable business functions (the things that must be done) in a way that allows the processes to change independently (processes describe how you do those things).  So, you could say that when a customer calls your business with a request for information, the customer is going to invoke the "handle customer request" business capability.  Whether that means a call center, or an IVR system, or just "folks in stores picking up the phone" depends on the business.  The capability is stable.  Every business needs to "handle customer requests."  How those requests are handled... that varies.

In Business Architecture, we talk a lot about business capabilities.  The operational capabilities form a key part of the entire business model (just one part, of course). 

For the sake of clarifying my call for standards, however, I'd like to break down the capabilities into three layers.  From the bottom: Supporting, Industry, and Differentiators.

image

Now, I'd like to avoid a "taxonomy debate" right off the bat by saying this: I'm not suggesting that this is the only way to group business capabilities.  There are lots of ways to navigate the list of business capabilities.  I'm breaking them down this way because it is useful. 

I have grouped the capabilities into these groups because these are the layers at which companies can collaborate.  When you talk about standards, and creating shared best practices, and constraining software vendors, and leveraging the buying power of the market, then collaboration matters.

At the bottom of the stack, you have supporting capabilities.  These are the things that every company needs, and every system contributes to, but is too-often overlooked.  This is where you keep your information about customers, products, transactions, and obligations.  This is the 'base functionality' on which the entire enterprise is built. 

Companies can collaborate in this area because capabilities here provide no competitive edge.  We mostly have the same needs here, quite often across a wide array of industries.  Business schools teach courses in how to "do" the things that align with these capabilities.

The Industry specific areas are the focus of so many industry-specific standards bodies, from TMForum to Acord to hundreds of others.  Even the HIPAA standard is a form of Industry-specific standard created to support an Industry-specific capability: the filing of medical claims.  Everyone likes to collaborate here, but only other folks in your own industry really care.

The capabilities at the top are the ones that differentiate your business from your competitors.  If your business is willing to collaborate in this space, then you are (a) rare, and (b) probably either location or geography specific or you are a protected monopoly!  The rest of the organizations I come across, including Microsoft, have a set of capabilities that they keep quiet about because there is some value in how we compete.

Of course, the customer doesn't see these things.  For the most part, the customer sees the image that a business wants them to see: the things that make a business unique.  That is what the brand is all about.  In a certain sense, the most successful businesses wrap their "supporting" capabilities and industry-specific capabilities with a layer of uniqueness and differentiation.  This is a slightly different perspective, but one that is useful.

image

Now, we have divided up the S+S space to focus on Line of business services, and within that, we have divided up the capabilities of a business into different layers.

The area where I believe we should standardize is not all software, or even all line of business software, but only the software underlying the Supporting Business Capabilities.

In this space, and ONLY in this space, do I see the need to create the first row of standards.

Then, on top of this space, I can see the need to describe Industry-specific models, like NGOSS/TAM for the telecommunications industry. 

The reason for doing this goes back to my initial post about a Shared Global Integration Model. 

One thing that is useful to realize about this standardization: I'm including the data model using the same hierarchy of business capabilities.  In other words, we should collaborate on the 'supporting' business model and allow industry-specific groups collaborate on the information that surrounds the center.  This creates an information model with many layers, each managed by different people.

image

I am getting somewhere with all of this, by the way.  My next post will go further into why the standards bodies are not getting this right today.  After that, I'll talk about the software that we should develop to support / enforce / encourage these standards.

Comments

  • Anonymous
    February 04, 2008
    PingBack from http://msdnrss.thecoderblogs.com/2008/02/05/standardization-works-with-a-limited-and-rational-scope/

  • Anonymous
    February 05, 2008
    Hi Nick - Do you also envision that there would be some sort of standard business processes defined for the Supporting Business Capabilities?

  • Anonymous
    February 05, 2008
    Hi Gabriel, Short answer: yes.  The supporting business capabilities do not provide differentiation to the business.  The businesses need to perform the related processes, but there is little or no incentive to perform them in anything but the most efficient manner possible. Therefore, creating consensus on a core set of processes should be quite a bit easier than you would find in the industry-specific space, yet industry groups like TMForum are able to do it.  I don't see any reason that supporting business processes couldn't be mapped and consolodated.   --- N

  • Anonymous
    February 13, 2008
    I'm not clear on why you're omitting hosted technologies in this, since may of these solutions now do address LOB functions. I wonder if there will be a need for standards here, as in applications, given that more companies are facing integration issues with hosted software solutions. (I get the hosted collaboration email example, but what about hosted CRM?)

  • Anonymous
    February 13, 2008
    Never mind. I went all the way back and read. I see where you're going. You might consider a mention of the hosted discussion, though, for those of us who can't get to every post.

  • Anonymous
    February 14, 2008
    sorry about that Loraine.  You made a good point.  I should link to prior posts.

  • Anonymous
    February 25, 2008
    Hey Nick,  I wrote something last year (http://appside.blogspot.com/2007/09/corporationlets.html) that relates a bit to your point.  You can skip to the 4th paragraph.

  • Anonymous
    February 25, 2008
    Hi Erik, I do believe I have part of that answer that you described. Thanks for the link. --- N