IT / OT Convergence: Part 4 Organisational Impact and Conclusion
This four part blog provides my point of view on what IT / OT convergence is, why it is important to engage with the topic and where we are heading.
Part one, the introduction, can be found here.
Part two looked at the use of information technology in operational systems, available here
Part three took a closer look at the integration of information and operational systems. available here.
This fourth (and last) instalment considers the organisation implications of IT OT convergence/ It also features a guest post from faithful contributor and reviewer of this series: Dr. Andy Stanford-Clark.
In most organisations the IT and OT functions are separate from each other. The IT function typically looks after enterprise systems such as Finance, HR, CRM, ERP and is the responsibility of the CIO.
OT is usually part of the business units and is often ultimately the responsibility of the business unit owner or the COO. This has often led to a proliferation of OT technologies and systems. Clearly this is not always the case and many organisations have coherent OT strategies and technical governance to ensure that OT systems can integrate with each other and economies of scale are achieved to optimise procurement as well as support and maintenance costs.
Alignment between IT and OT is much more rare and is usually limited to specific projects and not "designed in". Even where the system architects and designers have attempted to create an over-arching reference architecture it becomes difficult to implement as the organisations that are responsible for IT and OT have different objectives and are measured differently. For Example: Any additional project cost incurred in an OT project to align it with the reference architecture is difficult to justify to the sponsoring business owner as the benefits are likely to accrue only after the project has completed and, furthermore, are likely to impact a different business unit or even IT.
The problems that this divergence causes are quite obvious and I won't list all of them here, but key issues include:
- Lack of integration between different OT systems
- Wide range of skills required to support different technologies and designs
- Large spare inventories due to lack of component standardisation
- No consistent approach to security, difficult to assess how secure each system is
- Difficult to integrate OT systems with IT systems as each integration point is different
The use of IT technology in OT systems is providing some de facto standards (e.g. Ethernet) but also provides opportunities to diverge even further (think of the large number of operating systems).
I will consider two options to address this challenge. The first is to merge the IT and OT functions, or at least bring the communications and data processing aspects of OT under the control of IT. The second option is to establish a joint design authority (DA) to ensure that all systems use a limited set of reference architectures (where appropriate) and conform to a single Enterprise Architecture (EA).
Merge OT and IT functions
Merging the two functions sounds like the easiest approach. The main challenge is that there are often cultural differences between OT and IT departments. OT departments are typically staffed by domain specialists (e.g. Electrical Engineers in the case of Distribution Network Operators) who have a deep understanding of the business. IT departments typically employ people who understand information technology very well but don't have such a deep understanding of the engineering problems that OT systems address.
It should be noted that OT is often also a customer of IT (e.g. for support of desk-tops, laptops, mobile devices and enterprise systems). Any real or perceived lack of IT service quality is likely to impact OT's view of the capability of IT.
Both IT and OT however have a lot to contribute. IT professionals bring IT design methods, reference architectures, deep understanding of information and communications technology, mature development processes, IT security expertise and full life cycle management processes (e.g. ITIL). OT professionals bring a deep understanding of the domain and the devices that are deployed in the field, OT software, reliability engineering, real world challenges of deploying equipment in hostile environments, working within communications constraints and an acute awareness of the health and safety implications inherent in OT systems.
There is significant potential for both groups of professionals to learn from each other, not just to harmonise and integrate IT and OT systems - but also to improve practices in both areas (e.g. use some of the OT reliability engineering techniques in application development and use ITIL processes to manage OT systems). A merger by these these groups will however only succeed (in my opinion) if both groups understand the benefits and are prepared to learn form each other. This will allow them to build the level of trust that is required to achieve the benefits of IT / OT convergence as outlined in the previous two blog posts.
Close co-operation and joint design authority
An alternative to a merger is to create a joint design authority that creates and approves an overall architecture, reference architectures and standards. It should also approve the designs for large projects and projects that are likely to impact multiple areas (e.g. IT and OT). This sounds like a much simpler option and it is a lot easier to implement. But that does not mean it is easier to make it work. The challenge that all DAs face is how to exercise their authority. In many cases DAs exercise informal authority; they rely on the seniority of the members who use their reputation and gravitas to influence designers and decisions makers. This becomes a lot more difficult when the DA has to span multiple lines of business and / or departments within an organisation.
A successful joint DA has to be staffed by the most senior, most respected technical people from both IT and OT and enjoy full management support from both sides of the business. But this is not enough. To implement a consistent architecture and ensure standards are followed usually costs more in the short term. In some cases infrastructure needs to be built (e.g. an Enterprise Service Bus) that can not be cost justified by any one project. The DA needs to have a budget, or at least be able to obtain funding to support projects that need to spend more than is optimal for the project but provides an overall ROI for the organisation.
I will keep my conclusion very short: Convergence of IT and OT is happening now and I don't see this trend changing as there are many benefits as outlined in the earlier blog posts. To maximise the benefits and mitigate the risks, this trend needs to be managed. This requires not just technical but also organisational changes.
The last word goes to Andy, Internet of Things (IoT) guru, inventor of MQTT and Smarter Energy CTO for IBM's consulting business in Europe who has provided valuable input and reviewed this series of blog posts:
We've seen in this series of blog posts that there is a fundamental shift happening in industry sectors that have an "operational" side to their business. This has been evident for a number of years - when I started working in the SCADA industry, part of my role was to arrange a "first ever" meeting between the Operations team and the IT department in a number of clients. Once we got people talking the same language - about publish/subscribe, brokers and topic spaces in their middleware messaging systems, then they realised there was a lot of common ground for interaction and subsequent integration.
Fast forward ten years and we see Smarter Planet, Machine-to-Machine (M2M) and the Internet of Things (IoT) (take your pick!) making a substantial impact on the operational capabilities, and potential, of clients in a wide range of industries - from oil and gas pipelines, to transport and logistics, to farming and food-chain applications. We know now that the Internet of Things will have as profound effect on our ways of running our businesses and interacting with our clients as, dare I say, the advent of the Web did 20 years ago in the mid-nineties.
At that time I worked with clients to formulate their Web strategy. Now I'm working with clients to formulate their IoT strategy.
And the recurring theme, as we look at how the greatly expanded "Operational" side of their business, which now includes direct interaction with their customers through mobile and social applications, as well as sensor and actuator devices, is that a coherent and consistent end-to-end architecture needs to be in place, with no boundary between OT and IT - it's just one big system. Data and benefit flows both ways - data in the core IT systems directly influences the operational decisions made "on the ground", and a flow of data from the operational systems gives early notification of factors that affect the running of the business.
Whether this is done through a merge of IT and OT, or is implemented through an empowered overall Design Authority, is a matter for individual clients to consider - there are pros and cons of each, and the degree of integration in the current environment may lead to one approach over the other. But either way, it is self-evident that this needs to happen.
Erwin Frank-Schultz, Technical Leader for Energy and Utilities in the UK, Twitter: @erwinfranks
I would like to thank Andy Stanford-Clark (@andysc) for his input to and review of this entry.
The opinions in this article are my own and don't necessarily represent IBM's positions, strategies or opinions.