Business Processes and Services are not always correctly associated

For a few months, discussion around processes and services has been a hot topic in my company. Everybody has his own interpretation and very few information exist related to the subject.

This post is the follow up to a previous article I wrote a while ago:

What is a Service?

It is important to specify that sometimes when people talk, the term Service has to be considered either as an ITSM Service or an SOA Service-web service. This is clear to me that BPM and SOA should be tightly integrated, but let’s look at this slightly differently…

A Business Process has activities. An activity could be one to many Services.

But you can also look at this in another way...

A Service is one to many Business Processes. A Business Process has activities, and as already said, an activity is one to many Services. Isn’t this confusing?

What I try to say is that we need to be clear (at least for me...) when we talk of a Service. Are we talking of Service in Service Management terms, or in SOA Terms?

As an example:

The Service "e-mail" has several Business Processes such has:

Creation of email, classification, forwarding, etc...
Calendar Management, invitation for meetings, reminders, etc..
etc..

If for example we define the Calandar Management process and look at activities, maybe at some stage we would define a Service which lookup for availability of people in a meeting. This would be an SOA Service "Availability of people"...

To summarize and be clear, I would claim that ITSM Services could count one to many Business Processes, and Business Processes could one to many SOA Services. “E-mail” is an ITSM Service and “creation of an email” being a transaction is an SOA Service.

Does this make sense?

Innovation has to be the result of an Enterprise Architecture program

One of the steps of an Enterprise Architecture program is to look at Business Architecture. The Enterprise Architect or the Business Architect (sometimes a Business Analyst) starts to describe the current Baseline Architecture. This is usually done through MS Visio types of diagrams or with either the use of an Enterprise Architecture or a Business Process Analysis tool. The Business Architecture defines the organization value chains and how all its business processes fit together, are managed, monitored, measured, etc.

Then that team starts to develop a target Business Architecture describing the product and/or service strategy, and the organizational, functional, process, event, information, and geographic aspects of the business environment.

There must be then an analysis related to the gaps between the Baseline and the Target Business Architecture. As with the Baseline artifacts, the Target architecture information should be captured in with a phased approach with the organization Enterprise Architecture stakeholders and senior management. Once populated, the variance between the existing baseline, view and the transitional and future, target, views is used to identify the performance gaps in the Enterprise Architecture. The Performance Gap (also know as the transition strategy information to migrate the organization from its “As-Is” architecture to the organization “To-Be” architecture) information is then used to help identify what investments need to be supported for funding and implementation.

But during this Gap analysis phase, the Enterprise Architect plays a fundamental role in enabling business innovation, and facilitating the provision of a flexible and resilient infrastructure. His role will be to manage and incubate successful ideas through to implementation, as the Business is always looking at innovations in products, services, and business models to drive growth and profits.

A good Enterprise Architect also needs to be an innovator.

Innovation is critical, especially in today’s rapidly changing technology and business landscape. Having a n Enterprise Architecture that supports an IT Strategy and provides the flexibility to achieve the right balance between IT efficiency and business innovation is a keystone to business adaptability and growth.

"The CMDB Initiative..”, but where is the evolution?

Late April, a group of system and service management vendors decided to propose a standard related to a repository for IT assets, and their configurations items change over time.

In other words, BMC, Fujitsu, IBM and HP decided to create a model for a CMDB which would allow storing information such as desktop and laptop client images or configurations, servers, storage pools or networks and so on.

Very often information is spread among various sources and no standards exist on how to exchange meta data from all these potential sources of CMDB information. Today, the CMDB interfaces that exist are all proprietary, which is the problem that this group wants to tackle.
This working group will issue a white paper within the next month that will spell out their initial goals in more detail. And by the end of the year, they hope to have a draft specification proposal, at which point they hope to formalize the process by choosing a standards body.

But is that enough?

Focusing on data exchange is fine but shouldn’t they also consider the CMDB Meta data and propose a common model eventually re-usable by third parties?

All vendors’ CMDB have their own Meta model and as from now I have never seen from any vendor a roadmap related to the repository. As an example, with the acquisition of both Mercury and Peregrine, HP initially announced the migration from the HP Openview Service Desk, to Service Center, and now has announced that next CMDB would be the one from Mercury, which is in fact…Appilog… (An acquisition from Mercury). So what!

There is a need for a “next generation CMDB” for the following reasons:

- BPM based on a SOA architecture invoque IT components (software on hardware…) and we should have a link between a Business Process and the underlying Cis. A CMDB should also be process based.
- Relation is important that’s for sure but dependencies is another key topic. How does infratructure relates one to the other, how information relates one to the other, how physically components relates one to the other, how does application code relates (Cendura acquired by CA is maybe one of the only company which deleivred that capability) etc… A CMDB should be also able to add dependencies on the top of relationships.

This initiative will help the concept of federated CMDB and information exchange but will not really look at today’s requirements… A unified Meta model could be an interesting initiative for these vendors as this would create a new generation of unified Service management/Business Process management solutions.

IT Processes, Business Processes, who is coordinating what?

More and more IT departments refer to IT Governance, Best Practices, quality and processes. To run efficiently an IT shops, processes are supposed to help companies to excel. The disctinction between best practices and processes is not so clear but let’s assume that this is complimentary. Processes are either standardized; refer to existing frameworks such as ITIL, Six Sigma, eTOM and other best practices.

An IT Process is also a Business Process. It has only an “IT Flavour”.

Looking at the Business side, Business Process Reegineering (BPR) and now Business Process Management (BPM) are activities which also look at improving how a Business works. Some companies develop a target Business Architecture describing the product and/or service strategy, and the organizational, functional, process, event, information, and geographic aspects of the business environment.

Very often, based on my experience, and observations, IT processes do not have a process owner. If there are owners, sometimes they are siloed. As an example, the ITIL Incident Management process owner does not work in harmony with the ITIL Availability Management process owner, etc. Sometimes, politics, company’s mindset, or personnel agendas, prevent to do a consistent job.

On the Business side, it happens also that processes are siloed and not cross-functional. The integration between IT Processes and Business Processes is even not considered despite the fact that all Business Processes should be linked to IT Processes. The processes and activities of a Line of Business have Incidents, Problems, issues with availability etc…

The first step would be to have for the IT department a Service Manager (e.g. ITIL) to coordinate all the processes related to IT Service Management. On a parallel, the Business should also have owners for their processes.

Recently I was looking at some documentation related to the SAP ESA (Enterprise Service Oriented Architecture) and found a very interesting comment from Shai Agassi, member of the SAP Executive Board and president of the SAP Product and Technology Group (PTG). He claimed that “Chief Information Officer” function is morphing into two distinctive roles: the Chief Process Innovation Officer (CPIO), and the Chief IT Officer (CITO, to coin a new acronym). In this new model, the CPIO is in charge of innovative business processes and continuous process integration.”

All processes have definetly to be coordinated, IT or not in a consistent way. As improving processes allows to bring innovation, this new role (Chief Process Innovation Officer), would allow companies to create new synergies, between the Business and IT, considering the CPIO as a partner of LOBs, in charge of processes deisgns with the business’ network. That position would require new skills to be developed as part of the IT organization. Such a role would be the best way to create an harmony for IT/Business processes.

Service Catalog, what do you exactly mean?

These days everybody is referring to a Service Catalog whatever that means. Unfortunately there is some misunderstanding between people as sometimes they are referring to SOA and sometimes to IT Service Management.

An ITSM Service Catalog describes all services that are offered by a service provider. In some cases, all services offered by the IT department of a company. The Service Catalog is part of the entire Service Level Management process. The Service Catalog describes the standard services offered, based on which agreements are made with clients. These agreements are subsequently covered in Service Level Agreements. It also becomes the basis for documenting procedures and processes in an IT organization.

Depending on the purpose the organization hopes to achieve, the service catalog may be rich in detail or simply provide a top level explanation of services. An IT department manages, maintains and supports part of the IT infrastructure of the Organization. This infrastructure consists of a large quantity of products with which services can be provided.

These services are described in the Service Catalog.

To first identify services, we have to work from the perspective of the core business purposes. Then, look at what IT offerings support those services. After the core purposes, we have to move into those supporting areas that IT also serves, such as administrative or general organizational support. The entire Service Catalog should be viewed from the customer’s perspective. Some services can be further broken down into sub services as well.

For every service a clear description and all relevant characteristics are included. Based on this a client can assess the business application and the usefulness of a service for their own organization.

After looking at services from the business perspective, we start to define each service with the following information:

-Service Name (a simple description, preferably the same name the customer would use)
-Service Description (high-level description of the service written in language customers can understand)
-Support Contact Point (Where should the customer begin an inquiry or report problems regarding the service?)
-Responsible Manager (Contact person responsible for the service)
-Customers/Users (What set of customers (specific or general) utilizes this service?)
-Detailed Specifications (Some items may not require all of these elements, but possible elements to include in specifications are):

• Inputs (hardware, software, infrastructure, customer inputs, etc.)
• Outputs (final products viewed from a customer perspective)
• Default items always included
• Optional items the customer may request or pay extra for
• Excluded items which are never included
• Service hours of availability
• Up-time and service availability goals
• Support provided
• Performance standards for the service
• Customer procedures for starting, changing or ending the service
• Charges (if appropriate)
• Disaster/recovery
• Data Integrity
• Security
• Training
• Etc.

A Service Catalog is intended for all clients of an IT department, in other words, the business unit managers and/or their representatives that want to be extensively informed about the services offered by the IT department of his company.

An SOA Service Catalog has another goal: to manage, organise and reuse services. One of the key promises of SOA is reuse on a much more granular level than one could ever hope to achieve with pure object oriented techniques, but reuse isn't something that we get for free. Particularly, reuse problems arise when others within a teamdepartmententerprise don't realise that we have already defined and/or built a particular service that they could reuse.

To achieve in some way that objective, a SOA Service Catalog needs to exist and document the basis of each service. To build such a Service Catalog is not an easy task as you will need to first define the granularity of your services (please refer to my previous post: What is a Service?) which decribes the differences between an SOA Service and an ITSM Service).

As for an ITSM Service Catalog, information has also to be identified and captured:

• Service name
• Description
• Type of service (e.g. business, application specific, data, etc)
• Service level agreements and other quality of service characteristics (e.g. performance, scalability, security, availability, etc)
• For each service operation
• Operation name
• Description
• Request/response messages input/output parameters and possible errors
• Pre-conditions
• Post-conditions
• Whether the operation is idempotent

SOA Service catalogs leverage both Web services (application services (provided by reusable software components) that are typically found further down around the middle of the IT stack) and BPM to eliminate an expensive burden on business. To be effective, that service catalog must contain services in the language of the customer, must be transactional and finally flexible.

For sure both Catalogs relate one to the other but what is contained inside is quite different. The SOA Service Catalog should be considered as a Service Registry. The future will tell us how to link both catalogs once synergies between ITSM and SOA will be better documented and companies will have reach an upper level of maturity in these two domains.