What is it all about
Many ITIL adopters embark on a journey of structuring their IT assets and resources to achieve various organisational goals like transparency of IT costs, alignment with business goals and processes or just as simple as asset/license accountability. ITIL has CMS (Configuration Management System, formerly CMDB), which is a conceptual federating platform (dB+), which serves as a placeholder for such assets (aka Configuration Items) including relationships that tie them all together. Sounds wonderful, but the problem is that CMS is just a loose concept and ITIL (purposely?) does not provide with a recipe for turning this concept into something real. On the other hand, vendors do sell out-of-the-box “CMS/CMDB solutions”. A credulous ITIL adopter buys such CMS as a “silver bullet” only to realise that what he bought was just a fancy network discovery tool, and the most interesting stuff, relationships, are all either messed up by automation or simply left to manual configuration with no helpful guidance. Why does this happen? What needs to happen to bridge the gap between CMS concept and its actual implementation? These are the two questions which are being discussed below.
Building a House without Architectural Drawings? Good luck…
Imagine independent, skilled, well equipped and ambitious builders who were all given a task of erecting a house, where every builder would be solely responsible for one particular part: walls, foundation and a roof. They all know the ultimate goal, a house; they all have materials and tools to build; the only thing missing is Architectural Drawings of the House to build. Well… one should rightfully ask why a professional would even proceed without such drawings, but let’s just assume that those builders are optimistic beyond their professionalism.
The results would be quite predictable. The guy building a roof will most likely be showing up at the construction site in vain checking for the walls to become ready, which may never happen…
I hope this situation never really happens in construction. But in IT it seems to be the norm. When trying to build data around a particular goal, the most common approach is to buy a software package which promises such goal but think less about a logical path from that data to the goal. And this is where I try to make this parallel in between the “logical path” and “architectural drawings”. Really, we should not be selecting tools prior to having a good understanding of the “logical path” first.
Tools do not offer “Architectural Drawings”, even when it is claimed they do
An ITSM App Vendor is very proud to offer you rich functionality and of course “CMDB”. But the versatility, modularity and flexibility of the tool, being great marketing points, may not be so great in practice. Without having the “drawings” of the logical path from data to the goals one may get carried away from the scope (if it even exists) into the “bells and whistles” of the tool, introduce unduly complexities, expand the use of the tool into the areas for which it was not even designed and potentially start paying premium for such abuse.
And this is when running a tender among the ITSM Software industry leaders and picking the best of the best is really becoming a bad idea, leading to wasted money and effort – one needs “Drawings” first.
Logical Architecture of Service = Architectural Drawing
What is that Drawing of the “logical path” anyway? Moving away from the “building a house” fable, I’d like to introduce a more puffed up name: “Logical Architecture of Service” Model (LAoS Model). LAoS Model is NOT the same as data model. Data model is closely related to a dB structure, with which a CMS/CMDB vendor is trying to impress you. LAoS Model in this context has absolutely nothing to do with a particular dB technology.
LAoS Model in abstract terms defines rules of how different IT Elements contribute to IT Services.
LAoS Model is not something new. ITIL v3 calls upon “Logical Configuration Model” term in passing.There are different models pursuing similar objective of justifying having “stuff” in the Enterprise too. Those are mostly referred to as Enterprise Architecture Frameworks (TOGAF, Zachman’s, DoDAF, FEAF, MODAF, AGATE, OBASHI), and they may or may not have “Service” element playing a role there.
Most Enterprise Architecture frameworks suffer from being incomprehensibly bulky (DoDAF, MODAF, AGATE) and/or speculative, non-empirical (Zachman’s, TOGAF), and often biased toward Application making it somewhat exclusive and paramount to any other IT deliverable (TOGAF). Consequently they can hardly help in bridging the gap between the CMS/CMDB as a concept and its practical application. On the other hand, other models (like OBASHI) and especially vendor specific CMDB’s built into ITSM Applications lack the level of abstractness and are locked partially or completely onto:
- particular technologies (networked vs. non-networked, servers vs. PC’s vs. Telco equipment)
- medium (hardware vs. software vs. license)
- specific processes with no ability to inter-operate with others
Logical Architecture of Service Implementation Considerations
Similar to how ITIL provides with the framework within which there is some freedom of constructing IT Processes, LAoS provides with a framework within which IT Infrastructure data is being manipulated and forced to contribute to Service. This way every “builder” has freedom to chose colours, composition, material, etc. for his wall as long as this wall is built on a particular foundation and supports the desired roof (by design).
Such Model can/should be indeed implemented through a wisely designed database. Let’s call such dB a “LAoS Core”.
Three main functional characteristics of the LAoS Core are:
1) Simple
Besides its explicit connotation, means that it is not designed to enable any particular ITIL process. Being process oblivious, LAoS in and of itself does not deliver any tangible process specific benefits.
2) Federating
Has essential ability to access, consolidate and guide (control and validate) data from its normally disparate Citizens (other data stores responsible for managing particular processes).
3) Open
Has sufficient level of abstractness to not be constrained by technology, medium, process application or particular deliverables.
The idea of a federated metadata repository is neither mine nor new. The context of where I speak about its benefits is different though as it shifts its focus away from technical aspects to the logic of aligning IT with the Business through Service concept (as ITIL suggests).
Other Software Tools, being still part of CMS, enable and facilitate particular processes and do “tangible” things. I already referred to those tools as “Citizens” of a federating LAoS Core. LAoS Core federates data from those Citizens, validates, controls and passes them from one Citizen Process to another to ensure consistency among processes and functional groups (silos), eliminate redundancy and (most importantly!) align with Services.
Does the House Building fable have a happy end?
Yes. Have an Architectural Drawings or, in other words, LAoS Model defined before deciding on your tools and resources. Give your resources the right tools and all the freedom within the framework of that Model and I am sure there will be much better chances of building a functional and sustainable “House”.
A particular tool capable of fulfilling LAoS Core function and thus having an abstract Built-in LAoS Model is yet to be found (by me at least). I would not claim that I am fully aware of all the tools out there and their capabilities. I’d rather assume that the actual software either capable or already structured around a particular LAoS Model does exist. However, the Software Vendors tend to market their software solutions by GUI, versatility, “power of a dB engine”, comprehensiveness, capacity, reporting capabilities, etc. anything but the very core idea the tool is built upon. I dare to say that a lot of those glossy, all-around tools don’t have any such core idea, and are quite messy and illogical inside. Nevertheless, if there were such product on the market. I’d still be very cautious about locking your LAoS Core onto a particular vendor. If major IT processes also depend on the same product – its vendor may have too much leverage…