Business Services and their Challenges in Complex Environments

Business services and infrastructure services have divergent interests and requirements: business services are not focusing on IT. They may leverage IT, but their role is to be a core enabler for the organization to execute on its business strategy, i.e. delivering tangible business outcomes to internal or external customers that help the organization move forward. A business service could focus on the timely analysis and delivery of market data within an organization to drive its strategy, another business service could be to allow external customers to make online purchases. Infrastructure services will instead focus on providing and managing a stable and resilient infrastructure platform to run workloads. It will not necessarily matter to the organization whether these are running on-premises or off-premises. What the organization leadership expects from infrastructure services (i.e., IT) is to ensure business services can leverage the infrastructure to execute whatever is needed without any performance or stability impact. Considering that the audience is very familiar with infrastructure services, we will focus the discussion here on what business services are and what makes them so sensitive to any IT outages or performance degradation. Business services, while seemingly independent, are very often interconnected with other organization IT systems, and sometimes even with third-party interfaces.  A business service can thus be seen (from an IT perspective and at an abstract level) as a collection of systems expecting inputs from either humans or other sources of information, performing processing activities and delivering outputs (once again either to humans or to other sources of information). One of the challenges with business services lies with the partitioning of its software components: not everybody may know the “big picture” of what components are required to make the entire service/process work. Within the business service, there will be usually a handful of individuals who’ve been around long enough to know the big picture, but this may not always be properly documented. The impossibility, inability or even lack of awareness that upstream and downstream dependencies of an entire business service must be documented properly is often the culprit to extended downtimes with laborious investigation and recovery activities. In the author’s view, one of the ways to properly map the dependencies of a given business service is to perform a Business Impact Analysis (BIA) exercise. The BIA is interesting because it covers exactly the business service from a business perspective: what is the financial and reputational impact, how much money would be lost, what happens to employees, will the organization be fined or even worse have its business license revoked? Beyond these questions it also delves down to identifying all of the dependencies that are required to make the business service run. These might be the availability of infrastructure services and qualified service personnel, but also the availability of upstream sources such as data streams that are necessary for the business service to execute its processes. Finally, the BIA also looks at the broader picture. If a location is lost because of a major disaster, perhaps it makes no longer sense to “care” about a given business service or process, when priorities have now shifted somewhere else. Depending on the size of the organization, its business focus and the variety of business services it delivers, the ability to map dependencies will greatly vary. Smaller organizations that operate in a single industry vertical might have a simplified business services structure and thus a simpler underlying services map, coupled with easier processes. Larger organizations, and especially regulated ones (think of the financial or pharmaceutical sectors, for example), will have much more complex structures which impact business services. Keeping in mind the focus is on business services in the context of upstream/downstream dependencies, complexities can be induced by the following:

• Organizational structure (local sites vs. headquarter)
• Regulatory requirements (necessity to take into account in business processes the requirement to provide outputs to their regulatory body)
• Environmental requirements - production processes depend on external factors (temperature/humidity, quality grade of raw materials, etc.)
• Availability of upstream data sources and dependency on other processes (inability to invest if market data is not available, inability to manufacture drugs if environmental info is missing, inability to reconcile transaction settlements etc.)

In these complex environments, the cause of a disruption to a business service may not be immediately evident and therefore an adequate service mapping will help, especially in the context of a BIA. Needless to say, it may not always be an easy walk in the park to get this done, especially if key members in the organization which were the only ones to understand the full context are gone. It might even be much worse in the case of a disaster or an unfortunate life incident (the author has experienced this in at least two organizations). What about IT / infrastructure services, and how can they help with the challenges of business services? It would be wrong to assume that IT is the panacea to all problems and the all-seeing-eye of an organization. There is however a tendency to assume that because business services execute on top of infrastructure services, IT has an all-encompassing view of which application servers are interacting with which databases, and this leads organizations to believe that only IT can fully map a business service. The belief holds partially true: IT organizations that leverage advanced monitoring solutions are able to map a majority of infrastructure/application dependencies and view traffic flows between systems. In our view, these solutions should always be leveraged because they drastically improve the MTTR (Mean-Time-To-Resolution) of an incident. Nevertheless, in the context of a BIA and of the business view of services, we believe that while IT should definitely be a contributor to business service mapping, it should not be the owner of such plans. The full view on business services requires the organization not only to incorporate IT’s inputs, but also to gather the entire process flow for any given business process, to understand which inputs are required and which outputs are provided, as those may not always end in an handshake with an IT infrastructure service process.