Go Native AND Integrate Systems? Contradiction or Paradox?
If you are a follower of my blogs, you know that my Go Native series talked about the dangers of favoring needless customization over native functionality. You would have also seen that I recently blogged about the continued importance of proper system integration. Can you go native *and* integrate systems?
In fact, you can and often should. At first glance it may seem that these two themes contradict each other, but take a closer look. Go native is about fully leveraging the standard functionality within a robust software platform and doing any necessary customizations the right way. Nowhere in that blog series does it say that you must use only ONE provider’s software platform for all of your needs OR that you should avoid custom integration.
I realize that some software vendors may take issue with my previous statement, but few of our customers would. Sure, some customers do try to (mostly) standardize on one software provider for ostensibly sound reasons (like consolidation of licensing and required skillsets to support). In reality there are several factors that make these purported benefits unlikely to be achieved (as appealing as it may originally seem)…here are a few:
1. A single platform may result in diminishing (or negative) returns. Or said another way, one size rarely fits all. This is a very common problem in very large manufacturing organizations that have some very large and very small operations (and everything in between). For example, they definitely need an enterprise strength ERP to run their large, complex operations, but try deploying that same ERP at a smaller unit with just a few people each of whom wear many hats. Watch what happens. Not pretty.
2. You are likely only one acquisition away from a heterogeneous environment.For the few companies that ever truly achieve a single platform, even for a single function like ERP, the victory is likely to be short lived. As soon the company acquires a new business, they typically also acquire all of the existing systems that business had. These systems are not converted or replaced overnight, and so a homogeneous system landscape rarely stays that way for very long.
3. The proverbial one throat to choke may be multi-headed. Conventional wisdom holds that a single platform means you can work with, and hold one software provider accountable for your solution. But remember, customers aren’t the only kinds of companies that grow by acquisition; software providers do too. Often. You may be able to get one account representative (if you are lucky), but just try building a solution with all of their systems. You are likely to find (as I have) that you will have to deal with various sub-organizations that still feel a bit more like separate companies.
4. Standard integration doesn’t mean two systems were designed to work together. When software providers integrate acquired systems into their platforms, they normally provide some form of standard integration. At first the integration may cover only basic data and functions. Over time it normally includes most data and functions, but beware of advanced features or combinations thereof – especially things like product configuration, pricing, engineer-to-order, etc. (more on that later).
5. You need to integrate with YOUR customers too! One of our most savvy customers (let’s call them company A) recently told me that technology advances and new integration capabilities are quickly opening doors to exciting new sales opportunities. One of their customers (let’s call them company B) said that if A can provide its product selector as a web service, then B would stop buying from competitors and buy only A’s products. That alone could generate $150K in profit next year. They can now have this web service in production within a few weeks. So calculate the ROI on that project!
So when does it make sense to stay on a single platform? In general, I use the following rules of thumb:
Your needs are really best met by the systems in a single platform. The provider will typically provide some standard integration so you don’t have to develop custom integration. This is especially relevant when you are upgrading your current systems. For example, if you are an SAP customer replacing an existing eCommerce system with hybris, then you would get the added benefit of standard integration (but don’t choose hybris for the integration aspect alone).
You want pervasive integration like that offered within Microsoft Office products. It is generally difficult and expensive to provide this kind of custom or third party integration but some providers are getting much better at it.
You have tightly integrated processes like product configuration, pricing, and some engineer to order features. These can be very challenging to provide custom integration due to the need to keep so much data and logic in sync between disparate systems with disparate paradigms. This is often addressed with some sort of simulation in the target system which can be performance intensive. I could write an entire blog on this topic; perhaps that will be next.
Custom integration is not only commonplace but significantly growing in scale and reach. It is the way of the future. Systems and devices are now being designed to connect and inter-operate in ways that were scarcely imagined before this century. By now I suppose that nearly everyone has heard of the “internet of things.” In case you haven’t, then have a look at this link: http://en.wikipedia.org/wiki/Internet_of_Things
So by now you have probably guessed that the answer to my subject is – paradox. I encourage you to make informed decisions about software platforms and systems integration. Make the most of what you have (i.e. use each system’s native functionality and then tie them together with proper integration). eLogic has been helping customers do this since our inception in 1999. Give us a call if you would like to learn more.