In the late 80’s I had the unforgettable experience of working in the corporate IT Applied Architecture Committee for a Fortune 100 company. This could sound pretty impressive, except that it mainly boiled down to finding a way to get a large number of applications all across and up and down the supply chain to work together seamlessly. The problem was absurdly illustrated by a picture we took of a process control room with 5 different terminals/applications lined up in a row, with process operators moving between them in order to control the process. One colleague far more clever than I added a “Level I Integration Solution”, a custom operator’s chair – simply push a button marked “LIMS” and you instantly arrived in front of the LIMS screen. It had become obvious that the world was integrated, why weren’t our systems? We had to train the application Tower of Babel we had built over the years to communicate. Some believed the holy grail of integration was to be found by building a massive data model of the world and then CASE based applications would flow forth like tin soldiers marching in formation. “It’s the data, stupid,” was their creed. Others focused on standard interfaces, dealing with everything from coherent transport to standardized, even internationally standardized messaging. “It’s the interfaces, stupid” was their cry. Still others claimed “Open Software” as the one true religion of integration. But the practical solution that won out in the end was pretty simple – purchase the fewest possible commercial applications with the broadest suite of internally integrated business function coverage that best fit into a rational architecture of functionality, often giving up “best in breed” for a manageable integration task, usually then consisting of relatively simple interfaces. Although it is not particularly elegant, much has been accomplished using this approach, both in terms of significant IT budget cutting and improved business effectiveness.
Twenty years have passed, an eternity in the world of computer technology. Yet when I enter the laboratories of the small to medium and even larger enterprises today, it is as if I am entering a time warp and it is déjà vu all over again, or even worse. For there I encounter an array of often ad-hoc point solutions and an army of technicians and chemists referencing, logging, transcribing, cutting, pasting and otherwise struggling with a vast array of paper logs, Excel spreadsheets, Access applications, Word Documents, and a set of stovepipe commercial applications for instrument control, project/product management, MES, document management, ELN, LIMS, metrology, chemical inventory, employee qualification management, proposals, orders, purchasing, invoicing, etc. Day to day transaction processing is a struggle, timely and accurate decision support information even more difficult to produce. When it comes time to further automate a function, the approach is to find the best application and buy it – chemical inventory this year, LIMS next year, document management the year after, etc. Integration of systems is a rarity, integration across departmental boundaries even more rare. There is a lot of sub-system optimization, producing a total system that is far from optimized. In all this one must wonder, where is the advocate for total system optimization for business? Clearly not all vendor offerings are created equal when it comes to breadth of functions, integration features, and ability to act as an integration partner, but these considerations are often an afterthought at best in the application acquisition strategy and selection process.
In casting about for a better way, my gaze must fall on the IT organization and call for some serious mission re-evaluation. From all appearances that mission today is to architect and furnish infrastructure and insure that applications are compatible with it. Where then is the application architecture to deliver total system optimization and maximum business value? It is seldom in evidence. But when acquiring applications, whether home grown or commercial, it ought to be front and center stage in the selection process, and the IT organization is its most natural champion and advocate. I do not mean to trivialize the challenge for an organization whose skill set is usually more narrowly focused on IT technology. But the old saw applies, “When you do not know where you are going, any path will take you there.” As in many areas, a good beginning may be simply to start asking the right questions.
Is it all worth it, can value be added, especially for the smaller enterprise? Of course every enterprise and every industry has a different “lay of the land” that affects the answers to these questions. I remain convinced, however, that the enterprise that architects its application suite for integration will also architect a significant competitive advantage into the future in both the cost and quality domains.
Larry DeHeer 3/16/2009