Managing in silos

Let’s elaborate on the siloed organizations and challenges associated with such structures. Applications are engineered and developed in an effort to address the functional requirements as well as non-functional application-related requirements. Infrastructures are engineered, developed and managed with the aim to manage technology components within those infrastructures. There may exist more than one ‘release’ channels into production. Senior leadership and management, both within the businesses as well as IT receive largely disconnected information that does not enable intelligent decision-making.

In the middle of such chaos, unfortunately, you also come across leaders that are unable to appreciate the new generation of challenges that their business enterprises face and want to force obsolete ways of managing IT. Combination of these and other similar barriers lead to a non-delivery of those exact services that IT exists to deliver and that are required by our business customers.

This cycle creates an overall negative impact on what IT stands for and promises to deliver i.e., enabling business processes in an effective and efficient manner. In this blog, we will discuss these challenges in further details and will also, at a high-level, review how business service management can address these and other related challenges.

Following sloes contribute negatively to the overall realization of service culture:

1.     Silo-ed Vision and Leadership: Silo-ed vision and leadership at an IT level can result in lack of alignment between IT components thereby comprosing on the overall value that IT exists to deliver.

2.     Silo-ed Engineering and Development: End-to-end service management requires integrated approach to managing application development and infrastructure engineering.

3.     Silo-ed Technology Management: If we continue to manage technology in siloes, our business and customers will continue to face challenges in meeting their desired business outcomes.

4.     Silo-ed Request Management: All functions with IT organization must operate in harmony in order to ensure management of service requests required to meet service targets.

5.     Silo-ed Reporting and Communication Management: Siloed management results in siloed-reporting and communication management.

6.     Silo-ed Supplier Management: If we are managing our suppliers in siloes, it will present significant risks to the overall realization of agreed targets.

In my upcoming blogs, we will discuss the above-mentioned silo-ed thinking across various domains in greater details and will try to establish a better appreciation on the impact of such siloes on business outcomes. 

Challenges faced by lesser mature IT organizations

In the last couple of years, we see all trends that suggest that management of IT, as a discipline, is on its way to achieving the next level of maturity. Most established (with legacy environment in place) business enterprises that have been using IT in a traditional manner

1. Kept their infrastructure engineering and operations functions somewhat separate from the application development and operations
2. Managed technology and not the business, and
3. Thought, planned and managed in a silo-ed fashion

These business enterprises are now undertaking major transformational and improvement initiatives to bring alignment across different IT components in an effort to achieve the highly envisioned Business-IT Integration benefits. The separation between application and infrastructure resulted in a disconnect between business needs and the end-to-end management of those needs from the fulfillment perspectives – applications teams architected, designed, developed and implemented applications to satisfy functional as well as non-functional application needs, somewhat in a vacuum. When these applications are deployed in production, mismatches happen and these lead to negatively impacting the customer experience with IT products and services.

A close integration between application and infrastructure architecture, engineering, and development is absolutely critical to successfully meeting the business needs in an effective and efficient manner. For example, if an application is designed for a 99% availability driven by business needs, it may not actually be available that long if the network has a lower or same availability level. A global business enterprise deployed a Single-Sign On (SSO) application without thoroughly analyzing the demands and capacity requirements both at application as well as infrastructure levels. When it was put in production, other departments saw the benefits and started migrating to the SSO platform to take advantage of the benefits. Soon after deployment, the SSO platform was supporting over 4000 business applications, which it was never implemented for. Lack of capacity planning in this case resulted in the outage of SSO platform that led to un-availability of all of these business applications and impacted the business bottom-line tremendously. Therefore, if architected in a vacuum, these applications will very likely be mismatches to network and server capacity resulting in unforeseen outages. These outages cause disruptions not only for business customers but also for IT teams. In fact, if not governed and managed appropriately, this can impact the organizational culture to the one where ‘fire-fighting’ is a norm and is, unfortunately, encouraged and rewarded. In financial terms, this results in increasing costs of delivering IT services and reducing productivity and may lead to greater customer dissatisfaction.  

In my next blog, I will discuss in detail the siloed thinking and siloed management that adversely impacts an IT service provider’s ability to enable business processes. 

How can Service Catalog enable optimal management of Value Chains?

Depending upon the type of the request submitted, Request Routing Engine should perform request classification / categorization and route the requests to the appropriate process. Note that this Request Routing Engine may be as simple as a spreadsheet or as intelligent as business-rule based workflow engine.

Mature IT organizations are able to leverage Service Catalog to truly align its technical capabilities to meet the expectations established using the Service Catalog and Service Level Management processes.

All services listed in the Service Catalog need to be managed to ensure that they deliver the desired level of utility and warranty to the customers of these services such that these services are deemed valuable and serve as a means of delivering value. Capabilities of an IT organization to be able to manage and deploy its resources and ensure that the services that it offers deliver the desired value is called service management. Some of the key goals that need to be achieved by implementing service management are as follows:

• Service Level Requirements of services listed in the Service Catalog must be clearly documented and understood. 

• Service Level Management must ensure that achievable targets are established.

• Request Fulfillment must ensure that high-volume low-risk requests are managed effectively and efficiently in as much automated manner as possible

• Service Desk must be the single point of contact for the customers.

• Configuration Management Systems (tools and databases) must be optimized to ensure that the right quality of data are available to support decision making.

• Configuration Item (CI) relationships must be established such that these support the end-to-end management of services. Auto discovery tools are limited in their capabilities. CI relationships development and capturing of useful information is mostly a manual effort. For a medium to large size organization, it means significant investments. Targeted efforts focused on value creation are necessary.
• Change Management and Release and Deployment Management processes are optimized to ensure that changes are effectively planned and efficiently deployed into the production environment. For high impact services in the Service Catalog, custom change models may be defined.

• Incident models are defined for critical services to ensure that those services may be brought back to operations (in case of an incident) as soon as possible.

• Event Management capabilities are developed for those critical IT components that are supporting critical business services.

• And so on.

The main message here is not everything is important. Keep the 80/20 rule in mind when planning to implement service management i.e., let’s improve 20% of services that make 80% of the impact. The end goal of service management implementation is to identify the Value Chain for a given business process and ensure that all CIs that implement that Value Chain are managed effectively. This will enable IT to manage customer expectations and deliver IT services at the desired levels.  

"Service Catalog" - A Gateway Into IT

Having gained this understanding of the Service Portfolio and Service Catalog, let’s now see how these are used by different roles within a business enterprise and the role of Service Catalog in the day-to-day operations of the IT service provider’s organization.

·      Management (both business as well as IT) may use Service Portfolio to Strategize for New Services and to Plan to retire Old Services.

·      Customer (both from business as well as IT) may use Business Service View of the Service Catalog to Place Request for Service, to Check Status, to Report Problems, and to Submit New Ideas. Depending upon the role of the customer, s/he may be provided a different view into the Service Catalog and may even see different offerings and tiers all together. In addition, if IT service provider is providing services to multiple lines of businesses, depending upon your role and which line of business you belong to, an appropriate view of the Service Catalog may be made visible.

·      IT may use Technical Service View of the Service Catalog to “Build relationships between SLAs, OLAs, & UCs and to Identify Technology Needs.”

If something is not on the Service Catalog, it is not there because it was probably not worth offering. All IT activities (performed mostly by technical functions – Application Management and Technical Management) must contribute towards the design and development of new services and towards maintaining, operating and improving existing services and / or retiring those services that are no longer needed.

Service Catalog shows all the services provided by the IT. Depending upon the different channels that you may have provided to your customers, your customers may choose to call the Service Desk to initiate the request or use the Inter-active (online) Service Catalog to do the same. You will notice that there can be a small number of clearly defined request types that can be initiated by the customer using the Service Catalog. These may include the following:

• Open a new account 

• Change existing plan

• Report a problem

• Submit a new idea

Depending upon organizational needs and the type of the service, there may be more or fewer types of requests. However, the message that I am trying to convey is simple,

Service Catalog is the gateway into the IT and should list all services provided by the IT and the types of requests that can be placed on those services.

 In my upcoming blogs, we will discuss how Service Catalog will enable the full lifecycle management of requests initiated by the customers.