Starting on that longer work
In the last Note, the question about seeing into and beyond our past was put in the context of where does software tooling get us? ‘as Code’ speaking. As the adoption of open source climbs and the lack of venture capital for startups decreases, are we lining up for the first ‘as Code’ winter? What we would appreicate is an eternal (or at least long term finite) as Code spring. One supposes that thing about
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?
Hamlet, Act III, Scene I [To be, or not to be] by William Shakespeare - Poems | poets.org; accessed 12 april 2023
matters at least some. In taking arms against our own little sea of troubles, not being content to be caught between climbing use and declining investment makes less of a Scylla and Charybdis. Which is often the first half of an internal debate about whether to do this or that in the first place. Because the first place of a journey is much different than the first place in a race. You have to like one to appreciate the other, for one thing.
We ended the previous Note with a matrix correlating data governance and a digital twin capabilities table. We can certainly provide more detail on how that becomes relevant to the as Code progression in order to outline the edges of a longer work on the topic. The first perspective is provided below.
The following perspective provides the guide to the longer work in progress related to the convergence of data, digitalization of models, and digitizing experiences in a sense broader than games, entertainment, and shopping. As large as these economies are today, the digital edge has the potential to expand both markets and opportunities in ways we need to imagine as fast as possible.
In order to enable a framework for rapid adoption and a template that offers a choice of starting points for any organization, it has been suggested that some longer work be undertaken. That work, in the form of a book or a series of workbooks, begins with a strategy which encompasses both the need for a framework and a set of templates. The principles for framework and template foundation have been addressed in the previous Note. The following Section is the first of seven to be described here which provide the plan for the anticipated longer work.
Section 1. From technical debt to the edge
By filling in the 3 X 3 grid in the center of the graphic below, we have a step-wise adoption model for consuming technical debt of any and all kinds. Whether it is data-driven, asset-driven, process-driven, policy-driven, or culturally-driven, we can start to burn it off by filling in the blanks.
The reader will recall that from the bottom left clockwise, we have a data-centric adoption model. From the bottom left counterclockwise, we have a digital capability model. When data and digital capability converge, we have a digital twin within the organization. One of the metrics we can use in studying the degree to which an organization is transforming is to calculate how much technical debt is being rendered into digital twins, or at least what percentage of new investment is going toward digital twin devops rather than the legacy paths which created the technical debt.
In order to further frame the context and content of a longer work, we will use the 3 X 3 matrix as the rubric for generating the materials. From cell 2-2 (second row, second column) to cell 4-4 (fourth row, fourth column) we are gong to create an adoption model for applying open-source software as the engine to machine a platform engineering workbench. Starting with Infrastructure as Code in 2-2, we will sequentially add capability to our model in order to support the digital twin of net future engineering.
That net (also next...) future in cell 4-4, we refer to as xDP or “a Developer Platform for everything”. Since the Linux Foundation and its Cloud Native Computing Foundation team already provide a wide range of tools, techniques, and transformational services, we only have to use their work as a starting place. Wherever our starting place might have been, and where, in fact, the seven Sections proffer starting points.
Here, as we have said, choosing the starting place sets a strategy that enables organizations to move from as-built organizational solution engineering to an as-envisioned digital factory model. We can say this is imaginable, even say it’s possible, because of all the work teams within the Linux Foundation and the CNCF have done and put forward. Plus, so many other groups have joined to help support open source in ways that generate answers to all kinds of problems we use to have to sort through one script at a time. That was so yesterday.
In the next note, we continue along with the description of other Sections and appendices. We are reaching toward a scalable, efficient, and extensible model for rendering technical debt off the accrual sheets and into either something we can reuse going forward, or decommission out of our way.