Does integration impede flexibility in response to business changes?
For many years, technology suppliers have touted the benefits of an “integrated” approach to planning and deploying information technology (IT) solutions. The claimed benefits have included reduced waste, lower operating costs, and improved decision-making. Although this has been most prevalent in enterprise systems, similar trends have been promoted for industrial automation systems. All the major suppliers now offer a comprehensive suite of products and solutions based on a common, unifying architecture.
While such benefits are hard to quantify, the basic premise appears to make sense on the surface. After all, shouldn’t it be easier to share information across applications if they use common data sources and communications protocols? Integrated packaging and common installation and maintenance procedures and processes should reduce the day-to-day costs associated with operating the solutions infrastructure. Acquisition and installation costs can also be reduced when using a smaller number of multi-functional applications, rather than independent applications. Common user interfaces also offer the promise of “ease of use,” although much of this has been accomplished by using available operating systems features such as those provided by Microsoft Windows.
So, is there a downside to integration? After all, it is rare that benefits are achieved without some sort of trade-off. As is so often the case, the answer is “It depends.” In this case, the dependencies include the degree of integration – both desired and achieved – as well as the lifecycle position of the solution in question. Most important, and often overlooked, are important factors associated with the business environment. In many cases, these factors may not even fully present themselves until after important design and deployment decisions have already been made.
Highly integrated solutions can result in all the above benefits (and more), but they can also be restrictive at one or more stages of the lifecycle. For example, evaluating and selecting integrated solutions can take much longer, simply because of the larger set of requirements to be addressed. Planning upgrades can become much more complex, simply because a large integrated solution can have connections to and dependencies upon a wider range of related business processes. The result is that the size of the stakeholder group for such upgrades can be much larger and the extent of testing required correspondingly greater. In extreme cases, it may be virtually impossible to conduct such testing without a large, complex and expensive testing environment that mirrors the production systems. Reliable and cost-effective operation of such a solution may also be more challenging because of the diversity of the user base.
However, it is in the final stages of the life cycle that the largest costs may present themselves. As a large integrated solution moves to maturity and approaches obsolescence, the reality often sets in that the eventual replacement could become very complicated and expensive and take a considerable amount time to complete. This can be particularly challenging if careful records have not been kept of all the data flows and system and solution dependencies.
Much has been written about the challenges associated with replacing integrated business solutions such as Enterprise Resource Planning (ERP), but similar challenges can also arise when contemplating the replacement of operations and engineering systems. These challenges can only be expected to grow as these systems become more integrated.
Even before the solutions have reached the mature or obsolete stages it may suddenly become necessary to consider major changes or even total replacement. This is becoming more common as companies that have employed integrated systems make changes to their business portfolios; selling off some business units and acquiring others. A business that previously benefited from being part of a much larger corporate enterprise may suddenly find itself adrift as part of a spinoff, or face the need to connect with the systems and processes of a new parent as the result of a divestiture. In cases such as this, high levels of integration can present a major impediment to successful change.
Does this mean that such integration should be resisted or rejected? Not at all. The benefits remain and are very real. However, it is important to understand the explicit and implicit costs associated with this integration as early as possible in the life cycle, and to make adequate preparations for changes and eventual replacement in the later stages. As end users evaluate new and more integrated solutions they should keep this advice in mind; “Don’t think of it as state-of-the art, but as obsolete-ready.”
About ARC Advisory Group (www.arcweb.com): Founded in 1986, ARC Advisory Group is a Boston based leading technology research and advisory firm for industry and infrastructure.
For further information or to provide feedback on this article, please contact email@example.com
About the Author:
Eric provides advisory and consulting services to ARC analysts and clients in all aspects of operations and project management.
Eric has over 35 years of experience in the development, delivery, management, and support of operations information technology solutions in the process industries. During his career his assignments and responsibilities have included process automation systems development, communications network design, functional and technical architecture design, and technology lifecycle management. He recently retired as an Operations IT Consulting Engineer with the Dow Chemical Company.