Treating IT as a business domain

One of the elements in the Service Methodology that was released last year was the idea of support services, this talked mainly about considering things like HR et al as support services rather than as core business elements.


Well there is another area that IT needs to consider, namely itself. What are the capabilities that IT provides and what are the services that provide access to those capabilities? In the same way as the HR services and capabilities enable business units to undertake certain key elements, so must IT provide services for business elements to be automated.

The key here is that these elements are not the services that the business wants, they are those that are required to host the business services to be automated. These are purely support services in the same way as most HR services are support services. They are only required because the business needs them, either explicitly or implicitly, rather than having business justification on their own (e.g. there is no point having employee on-boarding without business departments to get them into).

So for IT what are these services? In part this is what the SOA Reference Architecture subcommittee will probably look to address, but before we get a formal definition I thought I'd outline what is meant by IT as a domain. Simply put most of the vendors when they talk about the "services" they offer to the business are really talking about IT services, things that support the view of the business not actually things directly offered to the business.

So when IBM talk about their ESB model and they talk about Process and Interaction Services, or Event Process or Workflow. Or some of the elements that BEA talk about, these are all about the IT services, which has nothing to do with the business services.
And its pretty common out there on the vendor front. The pattern of ESBs being about linking different technical services together rather than business services is becoming accepted wisdom, and for those that have read Freakonomics this doesn't mean its actually right.

So you should think about IT as a different business domain, with its own services and own approaches. But you shouldn't let this change the way you view the business services, and here is the challenge. Too often people start trying to split services into "Process","Rules" etc. Thanks to Edwin Khodabakchian who helped me frame what was really wrong about this.

The challenge isn't just the fact that from a business domain perspective that all the IT infrastructure is about is exactly that, infrastructure the place where its hosted, considering this important is like considering the floor of a building a person sits at as being a way to classify their job. The point is that these IT Services represent just the hosting element for a single capability, not always for entire services. A process engine for instance is just one way in which activities can be strung together, and this is completely separate to how two services will interact.

So the way to think about this IT domain is that its just another support service, it hosts individual capabilities for services, but doesn't have anything to do with the capability of the service itself.

For those who do Java or C#, think about the JVM and the CLR, they do a huge amount of things for your code, but when one class calls another that stuff just "happens", as a developer you don't care. Equally from a business service perspective you shouldn't care about the IT Services they should just "happen".