The production environment that supports my legacy applications is a Gordian knot of different technologies and different approaches to architecture. There is not a person alive on the earth who fully understands how this legacy environment works. We find this out each time we make a change to a legacy application and then wait to see what else breaks. Interacting with this overly complex environment is such a nightmare that we avoid it whenever we can. Navigating through or around this legacy system slows down everything we do. Any time someone asks for a new application or major enhancement that involves this environment, I have to say that it will take at least six months -- and six months is being optimistic.
This situation reminds me of what I consider to be two unassailable facts: Complexity is the enemy of agility, and complexity generates risk. In my experience, there is no possible good result from anything complex. As a result, I do all I can to avoid it. I work pretty hard each day to simplify everything I can about IT -- simpler business rules that minimize exception handling, more transparency about everything we do, rigorous standardization and streamlined internal processes.
Simplification sounds like a laudable goal, but sometimes my quest for simplicity is in conflict with other goals -- and that legacy system. Over the past two years, we have moved some major workloads to the cloud. Unless or until everything we do is in the cloud, this move to the cloud creates integration complexity. In the good old days, applications exchanged data to an application that resided in the same data center. Now, the data path goes from an application, through our internal network, through an external network, to one or more Software as a service (SaaS), Infrastructure as a Service (IaaS) or Platform as a Service (PaaS) providers and back. Such paths can result in some challenges.
Unless or until everything we do is in the cloud, this move to the cloud creates integration complexity.
Our first use of IaaS turned out to be a bit of a nightmare. We moved one of our applications to the IaaS provider. But this application spent its entire life communicating with applications in our data center. In spite of our best efforts, there was simply too much latency in this data exchange, and so we moved the application back into our data center. The legacy system prevailed.
We next did a global implementation of an application that is only available as SaaS. This application must exchange data with multiple systems -- with some of the data exchange needed in near real-time. Having learned some lessons from our first foray into the cloud, we completely changed our architecture. Instead of creating a hefty set of point-to-point integrations, we implemented -- also in the cloud -- an enterprise service bus product that acts as our data transformation and integration hub. This data exchange is purpose-built to manage, with low latency, the integration of data services for everything we do.
More CIO advice from Niel Nickolaisen
Consumer-friendly or enterprise security: What's a CIO to do?
The right BI for a mobile-first world
A CIO's plan for managing endpoint security
At a minimum, I figured that buying a product, instead of building my own, dramatically reduced project complexity. Even better, the product includes the functionality to align data exchange to business needs. Some of the data gets transformed and processed in near-real-time. Other data is queued in a holding tank and waits for quiet times before it takes its integration path. Thus, the high-priority exchanges don't compete with the low-priority traffic.
Given the fact that I accepted a certain level of complexity when I signed up for my version of a hybrid cloud, this has been the most practical way to get the benefits of SaaS, IaaS and PaaS at the lowest possible cost of complexity.
About the author:
Niel Nickolaisen is CIO at Western Governors University in Salt Lake City. He is a frequent speaker, presenter and writer on IT's dual role enabling strategy and delivering operational excellence. Write to him at firstname.lastname@example.org.
This was first published in October 2013