One little-appreciated issue with ITIL/ITSM suites is the question of who, within the enterprise, owns and operates them.
Consider this:
Who owns your financial processes? Probably your Finance group. But who owns your General Ledger system? Probably your IT group charged with building and running it. This separation of concerns is seen as a good thing by auditors and others concerned with checks and balances...
For one thing, it provides one more barrier against fraud, as administrative access to sensitive things like database tables and application servers is owned by operational staff not directly reporting to the VP of Finance. And of course, there are the usual issues of core professional competency; large systems require software engineers and architects with specialized skills not usually found in business departments.
The same principles, with few exceptions, are generally applied across all large enterprises, from HR to supply chain to advertising.
Consider then who owns your ITIL suite. Because ITIL (rightly or wrongly) is often seen as an operational discipline, the tooling seems to gravitate to IT operations staff. However, the same questions of core competency and conflict of interest also arise here. Software engineers are not usually attracted to operations, nor application architects. Even in a package implementation, there are significant questions of architecture and engineering in the application layer that an operations staff may be ill-suited to handle. What interfaces should the ITIL system have? What are its logical data structures? Is it suitable for a messaging or web services approach? How does it integrate and interoperate with the other applications that it will need to partner with, such as directory services, HRMSs, project management and CASE tools, and so forth?
These are nontrivial questions, requiring the most senior engineers and architects, personnel most likely to be found on the development side of the house. And there is a case to made that the process owners (e.g. the owners of change, release, config, etc.) are the last people you want to own the enabling systems. There is too much temptation and potential conflict of interest, especially when SLAs meaning real money are at stake. How can one have confidence that an SLA has been met when the team reporting it is the team who owns all aspects of the system monitoring it? In this post-Enron era, the answer is "One can't."
The answer is simple: IT must apply the same principles to itself it applies to the rest of the enterprise. Process owners do not run their own systems; separation of concerns is applied. If it's good enough for the rest of the company, it's good enough for IT.
See also A Story of Too Many Tools, Part 2 (and Part 1 as well.)
