Share via


When feasibility of integration is a measure of capability…

One of the jobs of an enterprise architect is to evaluate the business capabilities of an area of the business and determine if those capabilities are either strong, capable, or insufficient.  But what to do when two areas of the business overlap?

In some cases, as in mergers, or even consolidation of functions, you will find that two areas of the business have a need for a set of capabilities, and both have developed them independently.  This could be a good thing.  Lots of opportunity for independent movement.  On the other hand, silos in the business can be a problem for customer care among other things.  Silos also add complexity, in systems, data, and business process. 

So let’s say we have two parts of a business that have both developed the ability to manage inventory for the retail channels.  Two sets of warehouses.  Two sets of inventory management systems.  Two sets of supply chain relationships.  The warehouses are in the same geographical area.  So you bring together the inventories into a single building, but you still have two sets of systems. 

In this case, the capabilities associated with the processes, people, technology, and data may not be a simple comparison.  You may have strengths in both systems, and weaknesses in both, and yet it may be quite difficult to merge them.

In this case, the evaluation of business capabilities becomes more nuanced.  Instead of saying “contoso has strong capabilities in vendor management and shipment tracking,” you have to look ahead to the next step recommendations… which processes and systems will be used to manage the inventory of both businesses?  In that context, the ability of the existing systems to integrate, support multiple businesses, and adapt to change, becomes much more important than before.

Now, we are no longer comparing apples to oranges.  Now it is Fuji apples vs. Braeburn apples.  More measures are needed.

Comments

  • Anonymous
    February 03, 2010
    I lived through a nuance of this same thread recently.  The company I worked for was purchased.  As the acquirer began evaluating what systems to keep and which to shut down, our folks were often aghast that technically superior systems did not "win".  What I tried to explain was that our systems implement our business model and out processes.  Our business model "lost".  Unless our systems implemented a complimentary process or the same process in a better way or the process didn't much matter (as long as the work was done efficiently/effectively) technical superiority just didn't matter.   Adaptability is the right way to go, although it cuts both ways.  It makes things both easier to integrate as well as easier to eliminate.  Case in point, I use Notes now b/c it was too hard to pry out all the apps.  Win for IBM, loss for MS.