Look around any enterprise and we will see duplication, unnecessary redundancy, specialized isolated systems that do similar things to other specialized isolated systems, and gaps between information systems that people have to bridge. “Aha!” we cry “There is waste here – these things cost us money, and time, and attention. We must Do Something about it”. We set up a central integration committee with the power to set and enforce standards, and so the enterprise’s developers build systems that inter-operate across the enterprise, and so these costs disappear.
Sadly, setting standards is not free. It costs money, but it also costs time, it costs attention, and it costs innovation – just the things we are trying to save. If we are not careful, we can cause more delay, cost and distraction than we save. So when we consider the role of central coordinating boards – because we know we need them, completely ad-hoc chaotic disconnected systems are also harmful – we need to understand these costs so they can be weighed against the costs of the activities we want to reduce. And of course, we must bear in mind that this weighing activity itself costs money, time and attention…
For a central integration board to have the power to force integration it essentially must have the remit to dictate what a project must do; the project is not allowed to complete until it has satisfied the board in some way.
This essentially means the board becomes yet another veto-ing ‘touchpoint’ for any proposed change. It means time and effort has to be spent by the board understanding the nature of the integration needs of the new system, and the new system must ‘fit’ into the concepts of the board – which is often far removed from the task at hand. As the board personnel rotate through, certification will pause as the new staff get to grips with the situation. The board not only acts as yet another barrier to change (many enterprises already have ‘too many’ stakeholders with the ability to veto work), it acts as a bottleneck to the changes it finally approves. This doesn’t just take time, it takes brain power that can be used elsewhere.
As an example, consider “Bottom up” standards. These are driven by the requirements of the task operators (the people carrying out the work) and their need to communicate. The requirements are collected and collated, and a central standard can then be specified. The system developers can then submit their interfaces to be certified by the central board, and once approved can then implement systems that fulfill those specifications. Even in the best cases, this imposes delays. In the worst cases – where the needs of the task operators change before the previous needs have been fulfilled – it never completes.
Each round-trip generates another standard, all versions of which must be implemented by the appropriate systems to ensure backwards compatibility with those who have not yet changed.
This all costs money as well as time. The requests and approvals (and refusals, and resubmissions, and…) cost enterprise attention – it distracts the enterprise’s experts from the work they are being employed to do. The extra barrier reduces the willingness of people to experiment, to adapt, to innovate. Except, possibly, in ways to bypass onerous central standards committees.
(“Top down” standards on the other hand are nearly always inappropriate to the needs of the task operators, and system integrators resort to workarounds and misuses of the standards, leading again to extra work and extra delays – and increasing disconnection between the shared, documented interface protocols and the actual ones).
To avoid these problems it can be tempting to be abstract, to be vague, to provide overarching guidelines and approaches. The result of which is a set of compliance requirements that are so abstract that they do not inform or support integration efforts, but still require… compliance.
To provide core interoperability with the freedom to innovate, ‘extensible’ standards can provide the best of both worlds. Sadly, without great care, they can also provide the worst of both: the delays required to approve integration work, and a chaotic mix of incompatible extensions.
When XML first arrived it was hailed as the new interoperable standard that would – at last – mean that anything could talk to anything else. As a format it does indeed get around many of the issues with bespoke binary formats (while introducing some others), but even with a schema it solves only the format problem, not the rather more critical issues of agreed meaning and protocols. Without an agreed meaning of the data and what is required and what is not, a common format is useless. Indeed, format has been the most trivial issue in interfacing – even at low, detailed, levels – for some time. The same applies to higher level integration. The media tends to be secondary to the need to agree meanings and ways to resolve misunderstandings and uncertainties.
If the tasks and organisation structures remain similar for long periods these issues tend to disappear. For example, the coalition forces in Afghanistan have a highly complex impressively integrated network of collaborations as there has been time to crystalise collaboration TTPs around the tasks. Strong standards that have emerged from years of work are welcome in this environment. Strong policing boards that govern such stable systems are not so welcome if they prevent those systems from adapting quickly when the tasks change, as they are likely to between contingency operations.
The solution is, of course: ‘it depends’.
The first step is simply to recognise that the costs exist, and therefore to identify them and compare them. Costs might be delivery time, money spent up-front, money spent maintaining, effort (manpower) spent maintaining, various qualities of the deliverable (reliability, etc) and so on. So you might decide that removing redundancy is worth some extra design time, for example (although this is rare: “Sooner” usually has much more weight than “Better”). Or you might decide the opposite, in which case the calculation can be bundled in with the programme oversight so that someone doesn’t come along and go “Oh look there’s some redundancy [ie we are wasting money and time], we should do something [ie spend money and time] about that”
By making these comparisons we can hopefully avoid the ‘flip flop’ between strong integration committees that force everything to a grinding halt, and strongly ‘agile’ approaches that result in unwelcome and (worse) unexpected gaps between important systems at critical times.
Between these extremes of ‘Ultimate Coherence Never’ and ‘Agile Incoherence Now’ should be sweet spots – or at least not too bitter ranges – of arranging for ‘Just Integrated Enough’.
For example the integration board could be a broker rather than an enforcer: “So you want to connect your 3d terrain data to that 3d terrain data? Well such-and-such did that, they already have an interface protocol/specification”. Having a proven interface specification can improve the speed and reliability of a new integration so is attractive to integrators if it is appropriate, and the people who can judge that are the integrators not a remote board.
The board could be a ‘goto’ place for a repository or library of existing emerging interface protocols, storing and noting which systems use which protocols and so being able to ‘tweak’ and ‘adjust’ emerging standards rather than dictate them.
Ideally, the board should be a place that creates the right incentives across the enterprise so that people sort out the cross communications amongst themselves, in the same way as complex supply chains form and reform along the aligned incentives of money.
Enterprise-wide interoperability requires enterprise-wide governance, but governing bodies should set policy, not attempt to police.
This essay is a result of discussion with several people at the RUSI information management conference in September 2012