Service Management, performed correctly, is an enterprise-wide cross-discipline function that spans, both, the Business and IT. Yet, more often than not, Service Management is buried deep within IT Infrastructure and Operations Organizations, where only a handful of services that are only important to those organizations get any any real attention. As a result, Business Services and other IT Services get completely ignored and Service Catalogs become wasted investments that barely help anyone. An option is to move Service Management into an area that has far more accountability for enterprise-wide strategy, such as Enterprise Architecture.
Reminder: Defining Service Management
In short, Service Management is the professional discipline that helps identify, establish, manage and govern all Service Item (i.e. Services) for an enterprise. (Full definition of Service Management.)
The Purpose of Service Management
Service Management, as it applies to an enterprise (e.g. a company or government agency), exists to efficiently and effectively pair worker Demand with worker Supply, regardless of where the person/organization with the demand sits in the enterprise or where the person/organization with the supply sits in the enterprise. In other words, we build Services to connect people with a problem, in any one part of an enterprise, to people who can help solve that problem, in any other part of the enterprise.
This is important because it highlights the simple fact that Services sit within and span across different areas of the enterprise, meaning Enterprise Service Management is an enterprise-wide function, just like Enterprise Architecture.
Why IT Infrastructure and Operations is usually the worst place for Service Management
Unlike Enterprise Architects who spend their time worried about setting strategy for and enabling enterprise capabilities, IT Infrastructure and Operations Organizations are much further down the Business Value Chain. This means they’re focused on the lowest level commodity-like work, such as provisioning technology that is directed to them by higher levels in the Business Value Chain.
Another important consideration for moving Service Management into your Architecture Organization is that most IT Infrastructure and Operations organizations lack the advanced software development skills required for designing and developing automated micro-services, which are required for automating services, nor do they have the skills required for leveraging and applying complex Business Process Management Software (BPMS) and Rules Engines for end-to-end service orchestration. IT Infrastructure and Operations organizations are usually set up to deliver computing infrastructure (e.g. networks, switches, computers, virtual machines) and rarely get into the nuances of advanced software development, which are a completely different set of IT skills.
The end result is that, if IT Infrastructure and Operations owns Service Management, the Services in the Service Catalog are limited to the few that only meet the needs of those people who work at the lowest levels of the Business Value Chain. For example, a repeatable Service for Provisioning Laptops is valuable but not nearly as valuable as a repeatable Service that builds complex business applications, which in turn is not as valuable as a repeatable Service that handles Mergers & Acquisitions (M&As). A good Service Catalog addresses all Service needs at all levels of the Business Value Chain. Placing Service Management and the Service Catalog in your IT Infrastructure and Operations organization will rarely achieve this.
Simply put, Service Catalogs that originate in and grow from within IT Infrastructure and Operations organizations is often a pretty weak Service Catalog.
A better option is to move Service Management into Enterprise Architecture
Enterprise Architects have accountability for performing enterprise-wide work. For example, they focus on the enablement of enterprise capabilities (which are enabled by services, products, people, processes, data, technology, etc.). And, because Services align so closely with Capabilities, it makes all the sense in the world to place the ownership and accountability of Enterprise Service Management squarely on your Chief Architect.
This means your Architects and Architecture Organization will own, be accountable for, and be able to perform true Enterprise Service Management (ESM) functions, which means designing and delivering a true Service-Oriented Architecture (SOA). In other words, Architecture will be able plan for every Service, research every Service, map out all Service Deliverables, map out every Application that is a dependency for every Service, identify and manage all Data that goes into or comes out of every Service, help control every Technology that is required by and for every Service, etc. This means Architecture will be able to identify critical gaps, redundancies and opportunities for improvement.
In addition to being able to leverage Architecture’s enterprise-wide scope, your Architecture Organization is usually also better equipped to address things like custom coding, micro-services design and implementation, and the design and application of solutions which leverage BPMS and Rules Engines. All of these skills are the bare minimum for what you’ll need to build out automated (or semi-automated) Services for your Service Management program.
Architecture will ensure that Business Services are accounted for
In addition to low-level IT services, Enterprise Architecture will make sure that all Business Services and IT Services are accounted for in your Enterprise Service Management Strategy. This means that the most important stakeholder (your Business) will not be left out of Service Planning and the Service Catalog.
Enterprise Service Management in Architecture gives EA a tangible set of explainable deliverables
Placing Enterprise Service Management (ESM) in your Architecture organization has another important side-effect. Most Architecture organizations have a difficult time explaining their value and justifying their existence because their typical deliverables are documents and drawings that, while are important to specific people in localized areas, rarely get broader attention and support.
Placing ESM in Architecture gives your Architecture organization responsibilities for the Enterprise Service Map and the Service Catalog, which represent two tangible deliverables. It also means that Architecture will have many real tangible deliverables that revolve around the constant enablement and optimization of enterprise Services, such as the application of things like Business Process Management Software (BPMS) to implement better orchestration and automation of enterprise processes, across organizations and capabilities.