Jul 23, 2013
Many of the vendors I talk to have been acquisitive — rather than develop their own technologies, they see it as easier and more cost effective to buy any capability through acquiring another vendor and then integrating that technology into their own.
However, so many seem to struggle with this integration — and it often leads to problems with existing customers.
For example, if a vendor already has some capability in one area, but recognizes that it has holes in its overall offering, it may go out and buy another vendor that then provides functional overlap between two systems — where the original vendor’s system does some things almost the same as the acquired vendor’s system (note the key word: “almost”).
Received wisdom is to take what is best from the two systems and create a new offering to the market. However, existing customers can then get upset — they may have chosen the acquired vendor over the acquiring vendor, may have built up skills or written additional code that is dependent on the specific area being changed. Presenting them with a new system may just push them into a position where they start to review the total use of the existing software — something vendors always want to avoid, as this raises the possibility of the customer going elsewhere. An alternative approach is to use application programming interfaces (API) to cobble some form of interoperability together — still leaving the problem of supporting multiple different systems over an extended period of time.
Some vendors then choose to run the systems as stand-alone options, which I believe can be confusing to the user. “Here’s our best offering in this area. Or you can have this, which is also a very good offering, but doesn’t do these bits that the other offering does. Or maybe this one?” No, a vendor has to bite the bullet and get things sorted — but how to do this without upsetting the customer?
Surely, with service oriented architectures (SOA) and web services (WS) technologies being proven, the answer lies here?
For example, take System A and System B that are now both in a vendor’s portfolio through acquisition. Functions 1, 2, 3, 4 and 5 are facilitated by System A; Functions 4, 5, 6, 7 and 8 by System B. As you can see, there is a redundancy in functionality in areas 4 and 5 between the two systems. Existing customer bases for both systems are wary of change, but supporting two products is a drain on the vendor’s capabilities.
By identifying exactly what the functional overlap is, a web service or series of web services could be written which provides the combined functionality. In the next release of System A and System B, customers will still have the same look and feel to their beloved chosen system, but will now be using a shared capability through calling the same web services in these cross-functional areas. Going forwards, new customers can then buy an overall system (System AB, let’s call it) which is seamless and has no functional redundancy. Over time, existing customers can be drip-fed the extra functions in the same manner — through a set of web services operating through SOA architectures, resulting in a common overall system with a veneer of a different front end being the only difference.
Cloud computing can also be utilized to make this simpler: the new functions can be provided from a public cloud environment, with the on-premise software being changed to point to using the new functions as needed, meaning that a single instance of new functions is maintained and managed – and more of the software management is brought back under the vendor’s control.
A functional approach to how systems work can stop acquisitive vendors from running into systems overload.
Image credit: Steven Verlander (flickr)