Composing a journey, ca. digital
There is a need for a platform that generates platforms. When Systems of Experience replaced Systems of Record, it wasn’t a case of one platform replacing another, but rather a set of observations replacing another. When the performance indicators changed, the underlying support for the process of interest changed.
One isn’t all that sure this can continue because the step functions (and the time between steps) is too large to support real time converging with digital transformation. It would be helpful if we could move at the speed of data acquisition rather than at the speed of data analysis. It would be helpful if there were to become a set of imminently transferable platform asset types and process methods which could be used to co-generate change models.
And, maybe that’s the thing which we have access to now, and didn’t think too much about in the past. Models that reflect the underlying processes and mandates of change rather than where the point source opportunities for change existed per organizational behavior. Might not have been all bad, that time, those times, but now it is probably holding us back from meeting the needs to upgrade, or at least re-grade, so much so fast so as not to retrograde.
The insight about moving toward the speed of data acquisition rather than the speed of data analytics is a form of the shift left movement in continuous integration/continuous delivery perspectives. An organization which merges customer expectations into the product or service design process is shifting left if research and development is on the left-hand side and customer expectations are on the right. Certainly, any focus on Customer 360 views or work done on the attribution of customer journey effects on the outcomes acquired were already moving us in the shift left direction, organizationally.
What we are maybe doing now is losing time in the race to get shift left perspectives so enmeshed in our times and our work that we could be drifting right-wardly operationally without knowing it. We call monitoring observability now, but have we had the time to integrate product and service instrumentation into the customer journey? We were close once, when account based marketing looked ready to merge with information technology. That, too, fell to a wayside of diminishing expectations from over-inflated ones.
Sticking with it (‘it’ being change that never changes changing) is so not easy that it’s hard to describe how hard it is. We cannot expect, and should not expect to set the baseline, change will be a way of life for the majority of the workforce a majority of the time. There isn’t enough budget to support teams in every organization with sufficient size, scope of purpose, and funding to do the change thing for everyone else.
We need to both reset our expectations about this, and come to understand that there will be change, like it or not, and some of it will affect us, like it or not. The purpose of things here is to offer a design pattern for change which is scalable, efficient, and flexible to support the creation of platform after platform of viable and value-based solution engineering.
In order to present a template for others to use, this material provides a method for creating a digital twin of change. It is not as outlandish as it sounds because there is much commonality in what needs to change during times of change across industries, markets, and demographies. By distilling down those similarities into a core of working principles, we can generate, and then re-generate, a system which, once learned, can be reused for another change project.
What differentiates change in one industry, market, or demography from change in another is the variation of requirements deriving from policy, program, practice, protocol, and process each and all in the context of an environment and each other. We can create a maturity model for tracking our precession through these requirements by assigning each of these characteristics to a domain in the Smart Grid Maturity Model developed by the Carnegie Mellon Software Engineering Institute. Below is a mapping of the five characteristics to five of the eight Domains in the SGMM model. A sixth characteristic is the maturity of the interoperability between the characteristics, as alluded to above.
There it is again. That word “model”. If we are in search of a digital twin for change, and then one for change management, and then one for the confluence of productivity and sustainability, we are going to need a democratization of models so that more, rather than fewer, can use them much more, rather than, say, not at all. That one has been on me for some serious time, and fortunately there’s a time and place to start fixing it.
Like now, and here, respectively.
In (admittedly, once again) starting out on this adventure, we have at least been provisioned with a toolset we can use to model models. That would be the level of abstraction necessary to support the development of a platform that builds platforms. The tool set consists of purposes attached to pursuits which are supported by open-source software. If the purposes are things, and the pursuits are journeys, our path from wherever we are stylistically between change agents and change management to their confluence -as-a-Lifecycle, becomes that of digital twins merged with digital threads. There is, of course, a Capability Periodic Table for this type of work. It was developed by the Digital Twin Consortium and provides guidance about how to construct a platform from asset pools.
With all this available, what needs to be done is a filling in of the blanks on a matrix. One such matrix is provided in the graphic below. In this phase of the process, we correlate a foundation to a process and then to a solution set which can render the usefulness of the foundation to a demography of shared interest.
In the next Note, how the precession of digital transformation through a platform that generates platform architecture will be described.