The concept of a data historian has been around for many years and is a well-known and often a cherished part of the industrial landscape. In fact, many organizations will tell you outright that they couldn’t run their business without it; they are right at least conceptually anyway. The fact of the matter remains that the ability to collect and analyze time series centric data is a key part of every industrial organization. The need to achieve this at scale directly influences a company’s ability to grow and prosper. What is interesting about this is that as the needs of the business continue to mature the legacy design of how historians have typically scaled out is also changing.
In previous iterations of the historian landscape, the scale out was typically achieved through local hardware and the horizontal scale-out of the solution. This keeps the software relatively consistent in costs but results in a hidden cost. The infrastructure and physical space required to support local storage, back-ups, datacenters, etc. While these needs are coming down in cost, they still require expertise to manage, maintain, and upgrade over time just to “keep the lights on” as a technical upgrades and downtimes. This shift is pointing to the stand-alone historian model as something that is relegated to a thing of the past, and the inverse historians are rising to take their place.
What do I mean by this (inverse historian), I mean that new lighter-weight models for deploying time-series analysis systems are stepping in to do the job that the legacy historian systems typically have provided. You will notice that I haven’t gone as far to say outright replacing. However, in a very non-disruptive manner these systems are taking over as new projects rather than extending the current system. This results in a much subtler shift and a slower replacement process via attrition rather than a disruptive ‘rip-and-replace’ motion. This shift makes way for the target design and model for the quintessential efficient and scalable model to date where no end-user functionality is lost and data from any device at any location flows seamlessly to the enterprise.
This sounds great, almost utopian, but something in the back of your mind is likely telling you that this isn’t as easy to achieve as it may sound. You’d be right about that and some of the pitfalls are called out here in another blog ‘Is IT/OT Convergence Dead?’. This blog centers around how the various teams support and scale out these systems for many projects and not for individual one-off needs. Questions around management of such a distributed system and how it can remain consistent for use across the business application layers becomes a key sticking point for many approaches that are looking only at the technology aspect. This becomes more and more evident each time a new technology vendor only shows how data moves upwards, and no plan in place on how to (centrally & locally) manage the systems producing the data and linking it to how it will be used by applications. It is much more than just a technical or application management topic, but rather the combination of the two needs working together. Somewhere in this mixture, we find a symbiotic balance of “technology isn’t needed unless the business applications use it” and conversely “the applications need systems to drive them, as they are too complex to be manually driven” and the over-arching “business needs changing both strategically and organizationally and need stability and scale from both”. Once this balance, and its joint value, is realized the business can thrive in a continuous feedback loop of applications supporting technology investment and technology investment driving continually advancing applications.
The interesting part is keeping it stable while managing various changes in the business and in the way that various technical systems are continuously evolving. Ensuring stability and trust that the business can re-invest and reap short and long-term value from this investment is key for staying ahead of the competition and running a successful business while ensuring technology and applications don’t become outdated and hindrances to progress.
In previous iterations of the historian landscape, the scale out was typically achieved through local hardware and the horizontal scale-out of the solution. This keeps the software relatively consistent in costs but results in a hidden cost. The infrastructure and physical space required to support local storage, back-ups, datacenters, etc. While these needs are coming down in cost, they still require expertise to manage, maintain, and upgrade over time just to “keep the lights on” as a technical upgrades and downtimes. This shift is pointing to the stand-alone historian model as something that is relegated to a thing of the past, and the inverse historians are rising to take their place.
What do I mean by this (inverse historian), I mean that new lighter-weight models for deploying time-series analysis systems are stepping in to do the job that the legacy historian systems typically have provided. You will notice that I haven’t gone as far to say outright replacing. However, in a very non-disruptive manner these systems are taking over as new projects rather than extending the current system. This results in a much subtler shift and a slower replacement process via attrition rather than a disruptive ‘rip-and-replace’ motion. This shift makes way for the target design and model for the quintessential efficient and scalable model to date where no end-user functionality is lost and data from any device at any location flows seamlessly to the enterprise.
Diagram 1: The SAP Digital Manufacturing strategy to address this key industry trend
This sounds great, almost utopian, but something in the back of your mind is likely telling you that this isn’t as easy to achieve as it may sound. You’d be right about that and some of the pitfalls are called out here in another blog ‘Is IT/OT Convergence Dead?’. This blog centers around how the various teams support and scale out these systems for many projects and not for individual one-off needs. Questions around management of such a distributed system and how it can remain consistent for use across the business application layers becomes a key sticking point for many approaches that are looking only at the technology aspect. This becomes more and more evident each time a new technology vendor only shows how data moves upwards, and no plan in place on how to (centrally & locally) manage the systems producing the data and linking it to how it will be used by applications. It is much more than just a technical or application management topic, but rather the combination of the two needs working together. Somewhere in this mixture, we find a symbiotic balance of “technology isn’t needed unless the business applications use it” and conversely “the applications need systems to drive them, as they are too complex to be manually driven” and the over-arching “business needs changing both strategically and organizationally and need stability and scale from both”. Once this balance, and its joint value, is realized the business can thrive in a continuous feedback loop of applications supporting technology investment and technology investment driving continually advancing applications.
The interesting part is keeping it stable while managing various changes in the business and in the way that various technical systems are continuously evolving. Ensuring stability and trust that the business can re-invest and reap short and long-term value from this investment is key for staying ahead of the competition and running a successful business while ensuring technology and applications don’t become outdated and hindrances to progress.
- SAP Managed Tags:
1 Comment
