If you have as a key goal on your MBOs to achieve a significant reduction in your IT opex costs then listen carefully to the subplot in US president Barack Obama's recent pronouncements on the Middle East Peace Plan. What the president is saying is that you can not build an effective state unless you have a topology that can be rationally defined, operationally effective and sustainable in the long run, writes David Aminzade, UK regional director at Tufin Technologies.
It occurs to me that Obama might well have been giving a lecture to CISOs rather than politicians. If the key to opex reduction is standardisation, centralisation and virtualisation, then why allow technical zealots to build or expand "technical settlements?"
In fairness, standardisation, centralisation and virtualisation is not the sexiest project in the world, but if your techies hunger for bleeding-edge technology, then invite them to join a vendor or a consultancy. In fact, the main skills that you need for a standardisation, centralisation and virtualisation project are architectural rigour, detailed planning and the strength of character to not be blown off track by the problematic minutiae that you have to handle on the way.
There is, however ,a practical contradiction between standardisation and centralisation. Standardisation is generally about application selection and centralisation is about management. Therefore you need to know that all your standard components can be centrally managed by the chosen management software. This poses a huge challenge to centralised management software vendors as the R&D overhead of such a universal coverage is onerous. This in reality means each vendor only supports a limited subset of applications.
One successful solution to this problem is for the vendors to publish, maintain and take support responsibility of an API (application programming interface) for their product. Probably the best known example of this approach is from one of the biggest firewall companies in the world, which has more than 400 application vendors participating in its programme to allow its management system to handle aspects of their applications or to retrieve information from firewalls to provide inputs to their applications, eg, report generators, analytical tools, etc.
However, there are some major limitations to this approach. In effect, you are asking one security component vendor to act as a centralised management solution. The reality is that each component vendor will try to use their management system to exclude their competition.
Take change management, an increasingly important requirement to meet the growing demands of compliance, as an example. To achieve low opex and proper compliance a centralised change management system would need to cover all the components of a company's IT architecture. The best approach is to publish an API that vendors, VARs and end-users can use to arrive at a single centralised change management system.
Maybe President Obama could take a lesson from the IT industry and whilst continuing to insist on sustainable national boundaries for Israel and the Palestinians, put in place a cultural and political API whereby the elements of each country that will lose out in the process can have a guaranteed interface to the state that they want to handle their social, cultural and political "change management." The "but" and there is always a but in Middle East politics, is who will test the interface and who can give guarantees of its performance that will be acceptable to these often militant sectors of society.