Contributor: Markus Linsin
Some of you might remember that I have previously written about integrations, and specifically the not so fine line between:
- Integrating a core system to some supporting data feeds and
- Whether to create a new “central reporting datawarehouse” by integrating an Enterprise Architecture Solution with over 20 sub-systems.
What I didn’t touch upon was the discussion around the technical nature of interfaces and what type of integration technologies are typically required between Enterprise Architecture systems and feeding sub-systems.
In the world of web 2.0 and webservices, everyone seems to think that integrations have to be real-time, instantaneous and utilize the latest and greatest technology (APIs, XML , web services, etc). Talking about a flat file data import is as sexy as talking about a Cobol and RPG!
One of the most important trade-offs in an integration design is to have a balance between:
- the need for and value of “immediately updated information” and
- the cost (and also the risk) of actually building the integration.
Let’s look at a practical example. Let’ say I am supply chain planner at Walmart and I am managing the supply chain for chocolate cookies across the 3500 Walmart stores and super centers. Part of this job is to monitor the stock balances in the stores/super centers as well as the distribution centers to plan future inventory levels and to make sure inventory is replenished in a timely and cost effective way.
When a sales transaction occurs in a store, obviously this will have an immediate impact on the available inventory and could potentially lead to a stock-out which could lead to lost sales. One could argue that the supply-chain planner in his function to avoid stock-outs must know immediately about this situation. But is there really a need to know about this transaction in real-time meaning within a few seconds after the sales transaction has happened? In other words, when I look at my inventory levels in my supply chain cockpit, do I really need to see an up-to-the-minute inventory balance of chocolate cookies across my 3500 stores?
I am sure there are many supply chain software vendors out there that will tell you this is absolutely critical and they will have sample calculations how much money this will save WalMart on an annual basis. (Multiply Cost of Stock-Outs * Rate of Internal Capital) / (Customer Loss Rate * Annual Inventory Carrying Cost), etc etc, you know what I mean. Ultimately the software will increase earning pers share by 2 cents and you will be a corporate hero.
But is this really how a supply chain planner works? Of course not. A supply chain planner will not react to a sales transaction or maybe not even to a single stock-out situation in a store. A supply chain planner will look at the overall demand and supply situation and will then analyze trends, forecasts and other supply chain events to come up with a decision. Is the sudden demand in one store an exception, do we see similar trends in other stores, is this a result of an aggressive marketing campaign that ends 2 days later, can I maybe transfer some inventory from another warehouse before I re-order product from the manufacturer, etc etc
Sales trends occur over weeks or months, replenishment orders take days to be full-filled and sales campaigns are typically planned weeks ahead, so there is not need to alert the supply chain planner that 3 seconds ago, an inventory level dropped below the safety stock level. In fact it could be distracting to the planner when all those data points would come in in real-time and conclusions would be drawn from individual data points. For this simple reason, real-time information for a supply chain planner probably constitutes a daily, maybe even weekly inventory view.
The execution time of the response process to an event is a critical element that determines the time criticality of data integrations between systems. If it takes 3-5 days to replenish the inventory, is there a need to get sub-second updates about inventory levels?
So how does this compare to integrations in the Enterprise Architecture space? What data could possible be so time sensitive to an Enterprise Architect that it needs to be updated in real time? Compare this to a real architect in the real world…
Would an architect request an update every single time a wall has been completed or every time a window has been placed? Or is it enough for the architect to know that the basement is 75% finished? Enterprise Architects typically think in months and many times in years when it comes to planning their to-be architecture. Application roll-outs take anywhere between 6 and 18 months or longer , technology replacement cycles in an enterprise take similar time and changes to the business model or corporate strategies don’t require immediate sub-second reactions. Projects to replace existing IT artifacts are planned months in advance and are executed over months. So in my humble opinion, there is truly no need for real-time integration between EA applications and feeding sub-systems.
The only information that comes close to requiring a real-time update is deployment data that is critical for business continuity purposes.When a server goes down or a data center is affected by an outage, it is important to understand immediately what applications are down, what business processes experience an interruption and what organization is affected by this incident. Detailed technical deployment information is typically managed in Configuration Management Databases and in my view, this integration is potentially the only integration that justifies a close-to-real-time integration architecture. Other integrations like the integration to a Project Portfolio Management system (PPM) or a Business Process Modeling solution (BPM) can certainly be built on a decoupled asynchronous data import model.
In other words, if I were to make a decision for an Enterprise Architecture solution, strong data import capabilities to enable automatic data loads that are supported by data mapping capabilities and good data validation are much more important than real-time data integration capabilities that over-complicate integrations that at the end do not create a lot of value.
Any comments?
Recent Comments