Saturday, May 11, 2013

Interpreting OGC-Capita Joint Venture

26th April 2013, the date which could possible go down into Service Management History as capitalization of ITIL framework. This very day OGC entered into a joint venture agreement with Capita, an IT outsourcing provider of UK, to form a new company that has not yet been named. With this the ITIL, PRINCE2 and other IP of OGC would be owned by this new company which would take the responsibility of commercially developing these IPs. The new company would be launched in January 2014. The commercial and other details regarding this venture are available at:




It is interesting that such a major news for Service Management industry got minimal news coverage outside UK. Also, I am a bit surprised why other IT giants or organizations like EXIN have not won this bid because they have a potential to pay much more than Capita did. Was it that these organizations felt that there would not be a significant RoI from this deal or was it something else which prevented, barred or disqualified them from this bid. Only OGC would have an answer to my question. My opinion is that definitely it is not a case where these organizations were not interested. Owning IPs from OGC with the likes of PRINCE2 and ITIL surely make a great business proposition especially when you get to own the IP, which would take an organization into a different playing field all together. So RoI and business sense is definitely there. Then how come Capita, comparatively an unknown company outside of UK, has won this bid?

My opinion is that this being an election year in UK could have had an influence on decision making. EXIN was a Dutch company. IBM, Accenture, TCS and the likes are neither British as well. So though it might have had made more business sense for UK government to go with these Giants yet it would have had a political fallout on the ruling party.

How Service Management Industry Would Transform Post The Joint Venture
Only future will unfold the eventual impact of this joint venture. But I believe as far as adoption of ITIL V3 framework is concerned, there would not be any significant impact till a time the new venture does not come out with a policy to charge royalty for using the framework, a decision which could possibly lead to the death of ITIL. We might see some new Service Management framework being released from Open Source networks.

ITIL has grown not simply because OGC owned and developed it. It happened because many professionals across the globe, irrespective of their corporate boundaries have contributed to its evolution into a de-facto framework for IT Service Management.

Now post joint venture era, would the same level of contribution happen to further evolve ITIL? I do not think so. On the other hand the new company might hire professionals to write the new version of ITIL or develop supporting peripheral materials. In both the cases the acceptance level which ITIL as a framework enjoys today would not remain the same.

Other factors which could be interesting would be:

Firstly, the IT service providers who have a major contribution towards using the certification scheme may decide not to accept the ITIL certifications. This could happen because the money they would spend on getting their resources trained or certified would indirectly be funding their potential competitor.

Secondly, IT service providers and ITIL Consulting companies would start facing a severe competition from Capita in the ITIL consulting/implementation space since Capita would go to customers and claim that they own ITIL and no one can provide a better consulting/implementation solution than them. This again could be deterrent for such companies to accept ITIL’s evolution and thus contribute towards an open source Service Management framework.

Thirdly, the certification bodies like EXIN, APMG, etc. or ITIL Consulting Companies like Pink Elephant, Quint, QAI, etc. may decide to come out with their own certification scheme which could be based on an open source or their proprietary Service Management framework.

With all possibilities I see a major decrease in the revenue from ITIL certification and evolution of ITIL framework. Thus, this joint venture might possible fail on a long term and OGC would have a stiff competition from a new open source service management framework.

Monday, April 16, 2012

Controlling Unauthorized Changes

I have frequently come across a question – “How can we control unauthorized changes?” Some of the most common response that I have come across are:
  • Discovery tool can help in identification of the change of state, which if not approved would mean the change is unauthorized. This is reactive; in reaction to a change that has already been implemented. It can help us in identifying the unauthorized changes that has already been implemented, in case that change of state is being monitored. But if that change fails, the impact to the business would have already happened.

  • We need to embed process culture to ensure that everyone follows the defined processes and policies. Again a reactive approach if one is aware that unauthorized change has taken place. May be it can help in minimizing the probability when implemented with a severe penalty clause whereby it would be a deterrent for an individual to go against the defined process or policy. But there is a saying “Thief is not a thief till one is caught stealing”. Same applies to unauthorized changes. Many organizations realizes that unauthorized change has taken place only when that change fails and impacts the business.
  • Many have voiced the combination of the above two to eventually ensure that unauthorized changes are not implemented.
Then, what can be a pro-active way whereby change management can ensure that an unauthorized change does not take place?

To answer the above question, IT Security Management process has to be tightly integrated with Change Management. As part of the IT security process and policy definition, a security policy has to defined whereby ‘write’ access to the production environment can be granted to the concerned stakeholders, including the ‘administrators’ only when a change is approved and the concerned stakeholder is responsible for the change.

The defined security policy would be implemented by Access Management. Granting and revoking access can be automated by linking the approved change, implementer ID and change schedule with the access control application.
This process would ensure that no one has the access to the environment unless the same is approved by change management, which would be an approved change request. Thereby, proactively making certain that only approved changes are implemented to greater degree of accuracy (an approved stakeholder can still make some change which is not approved in the environment one has access to for implementing an approved change but such instances would be extremely rare)