I love watching those modern movies where IT works magically. In these movies, any average Joe with access to a computer or terminal can instantly access anything with seamless effort. Everything is clear and neat, we’re presented with impeccably clean data centers, long alleys of servers with no spaghetti cables lying around, and the operators knows pretty much every single system, address and login information.
For a sizable portion of the IT workforce though, this idyllic vision of the IT world is only a piece of fiction. I see here an interesting parallel with the IT world that we know. No matter how well intended we are, or how much meticulous we are with tracking our infrastructure and virtual machines, we will eventually lose track at some point in time, especially if we do not have a kind of automated solution that at the very least regularly scans our infrastructure.
In my previous post, I was discussing Business Services and their challenges in complex environments and explaining how critical it is to properly map business service dependencies through a Business Impact Analysis (BIA) among other tools. To be able to look at systems from a business service perspective, we have to readjust our vision to see the hidden wavelength of the business services spectrum. Let’s put on our X-Ray business vision glasses to look beyond the visible IT infrastructure spectrum.
Why is it so complicated to keep track of business systems? Shouldn’t we just have a map of everything, automatically generated and up-to-date? And shouldn’t each business service be accountable for their own service / system map?
In an idyllic world the answer should be yes. However, with our busy lives and a focus on delivering, attention sometimes takes a toll and priorities get adjusted accordingly, especially in reactive environments. Lack of documentation, high turnover rates in personnel, as well as no proper handover / knowledge transfer sessions can be contributing factors to losing track of existing systems. But even in well-intentioned cases, we may have some misses. It could be that new project which your deputy forgot to tell you about while you were on holidays, where a couple dozen systems were on-boarded into IT support, because they were too busy firefighting. Or it could be that recently purchased smaller company, where nobody informed IT that some new IT systems must be supported. Or again, this division which now runs the entire order processing system directly on a public cloud provider infrastructure.
Finger pointing aside, and looking at the broader scope, there has to be a way to do a better job at identifying those unknown systems, especially in the context of an IT organization that is oriented towards supporting business services. Mapping business service dependencies should be a collaborative effort between IT and business stakeholders, where the goal is to cover end-to-end all of the IT systems that participate in a given business process or function. In an ideal world, this mapping activity should be conducted through various interviews with individual stakeholders, service line owners and key contributors to a given process.
It is, however, difficult to obtain 100% success in such activities. A real-life example I’ve encountered during my career was the infamous “hidden innocuous desktop computer under a table”: A regular-looking machine running a crazy Excel macro which was pumping multicast Reuters financial feeds and pushing the data into a SQL Server, which would then be queried by an entire business division. This innocuous desktop was a critical component for a business activity which had a turnaround of cca. 500 million USD per day. With this computer off, the risk was regulatory fines, loss of reputation and loss of business from disgruntled customers. This component was eventually virtualized once we figured out it existed. But for one found, how many are left lying around in cabinets and under tables?
Organizations have evolved, and long gone is the time where a monolithic core IT system was used across the company. Nowadays, a single business service may rely on multiple applications, systems and processes, and the opposite is also true: one application may also service multiple business services. Similarly, the traditional boundaries between on-premises and off-premises systems have been obliterated. Multi-tiered applications may run on different infrastructures, with portions sometimes out sight from an IT infrastructure perspective.
In this complex, entangled, and dynamic world, the ability to document and maintain one-to-one relationships between systems requires exponentially more time and is at best a difficult endeavor. So how do we cope with this issue and where do we go next?
Not all business services and processes are created equal, some are critical to the organization and others are secondary. A process that requires data to be collated and analyzed once every two weeks for regulatory compliance has a lower priority than another process which handles manufacturing and shipping. This classification is essential because it is fundamentally different from the IT infrastructure view. In IT Operations, a P1 incident often indicates downtime and service unavailability for multiple stakeholders. That incident classification already derives from multiple inputs such as the number of affected users, whether the environment is production or not. But with additional context such as business service priority, it becomes easier to effectively assess the impact and better manage expectations, resource assignment and resolution.
Automated application mapping and traffic flow identification capabilities in monitoring systems are essential for mapping system dependencies (and thus business service dependencies) and avoid similar situations as the ones described above. But moreover, tools which allow the organization to break away from the classical IT infrastructure view and incorporate a business services view are the most likely to succeed.
