Process perspectives
In thinking about how Open Standards would provide guidance for a data as code Center of Excellence, we needed an example. The Digital Twin Consortium has produced a Capability Periodic Table that has six major elements. These are Data Services, Integration, Trustworthiness, Management, Intelligence, and User Experience.
Since a digital twin requires a physical and virtual representation at a minimum, this seems to be something that could support a journey through the aggregation process alluded to in last week’s entry. Again, thanks to the fact that data as code is a hard thing to define, focusing on developing a standards based, standards fostering, devsecops model seemed a good place to start…..We can re-use the starting place if we can provide support for both up and downstream work and top down and bottom up designs. That is, if there could be a digital twin for the Center of Excellence, it has to support the idea about moving things forward (up and down-stream), while supporting a vision of how the organization is to change. Change, changing.
As this addresses a common challenge to organizations, let’s say that the up-stream, down-stream model is provided by the Open Group IT4IT process. It is reusable across any domain or range and reflects the type of thinking needed to model a circular economy. A build plan for the IT4IT-as-stream can be constructed from existing designs which need only a virtualized network and a model that supports microservices, API’s, operators, pipelines, and a method to link them together. The link could be integration, interoperability, or simply interconnection.
With the NIST CPS version of the macro, meso, micro design path and the four-stage build-out methodology proposed by the Open Group, micro becomes the stage 1 to stage 2 process, meso stage 2 to stage 3, and macro stage 3 to stage 4. The reason we need the pipeline and interaction component is that from a two-dimensional perspective, the IT4IT devsecops plan requires us to connect disparate parts of the architecture during each phase of adoption.
The Open Group IT4IT™ Standard; accessed 15 august 2023
In the graphic above, the manner in which layers of solutions supported by the IT4IT methodology in terms of value paths lead to downstream catalogs of services is shown. The upstream flow rate would be how the catalogs provide insight into supporting their next versions and the catalog lifecycle. Since there are open-source solutions for observability, pipeline articulation, and data tracing, we can use the IT4IT architecture as a form of ‘quick-connect’ to the underlying architecture, even in the as-built state.
Moving from the as-built to as envisioned requires the use of the multi-stage design pattern mentioned above. The first two stages are shown below with an indicator between them representing a micro-level bridge.
The Open Group refers to these projections of the IT4IT process as the first and second contexts of an adoption process. If one were to represent the transition in the context of a model reference adaptive control system the architecture would look like this:
If the representation of the transition across the micro-level bridge is the strategic representation of what an organization wants to accomplish within its digital domain, the use of the model reference adaptive control version provides a state-space tool with which to observe the transformation process in situ. That is, as it’s happening.
Current observability tools include instrumentation capability for microservices, API’s, operators, pipelines, and integrations of each with each other. Dynamic systems analysis in the cloud native space grew up with the solution packages, and do not have to be retro-fitted on to existing offerings. This remarkable achievement may be the one that provides the capability to reach beyond productivity and efficiency metrics, and provide sustainability models thought the use of something like the model reference adaptive control analogy provided above.