on finding middles in things

Though not directly related to several things going on, there was an opportunity to review the how and where thoughts on platform engineering.  Certainly, thinking of platform engineering as the confluence of ecosystems of software, hardware, and services in a cloud-trust-big data delivery system has been a great starting place.

But what about when the ecosystems need to move ‘upstream’ to get to the source of digital transformations rather than settling for enabling downstream moves of strategies, operations, and tactical maneuvers?  Since cloud-native computing solutions reduced the north-south, east-west design patterns to more ‘diagonal-first’ architectures, the compounded interest on past understandings has become subject to technical debt, if not near bankrupt.  When the how and where of scaling can be embedded in the system architecture rather than have to be layered on from without, what are we left to figure out how to best model the platform’s evolution in a manner that can be made productive and sustainable.

That is probably one reason we got to the idea about going to the middle of middles to begin a transformation.  Rather than start at either end, or both ends, pick a goal that is midway from one set of supporting equations of motion to another.  Since we lost the easy maps of north-south, east-west, we can assume the topography is (as of now) nearly completely unknown to us except for the fact that swarms of containers are going to be used to support each component of the upstream/downstream approach.  We are only going to feel comfortable in the middle of a river of change by discovering a path to paths which enables leaps, not of faith, but of calculable value.

Which, as everyone knows, has always been a fickle thing to uncover.  Calculable value needs some quantification method that is based on instrumenting the process in order to recover numerically operable data.  Tracing the path of a process used to be more difficult than it is now, because surveys and user impressions can be substituted for with functionality from observability tools.  Given that, all we have to do is provide a representation of the process which is amenable to deployment in a dynamic assessment application.

Below is the Open Group’s IT4IT process.  This version can be found in the paper at: DBCX Transformation WP (opengroup.org); accessed 26 june 2023.

By applying the domains of a (for instance) maturity model, we can see that the IT4IT framework is extensible to use as process modeling architecture.  The result is provided below:

The Domains used in this example come from the Smart Grid Maturity Model developed at Carnegie Mellon University.  Since each of the Domains contains levels to assess the progress from ad hoc activity to well managed through analytics, we can scale the model up or down, or left and right, investing as budget and skills are available. 

As the developer community moves from shift left to dev/ops, then to devsecops and platform engineering, keeping track of the successes and the projects drifting off course needs to be managed using orchestration and automation at the process level, and then at the sub-process level.  Such capabilities have been available for some time, but they haven’t yet been sufficiently applied to something like taking over from wehre the north-south, east-west architectures left off.

This becomes an opportunity to accomplish some of that.