Favorite Quotes - Chris Swan

from:  https://www.infoq.com/articles/notpetya-retrospective/

The IT Toolbox #002 - Edge and Central

We often hear a reference to the ‘IT Pendulum’ but we should forget the idea that it is an all or nothing fight between good and evil.

The first point, it’s definitely NOT an all or nothing fight.  Each one of these technologies continues to exist today.

The more interesting thing that happens to make each of these relevant in their time is the abstraction and evolution pattern that occurs.

Consider this pattern:

Mainframes becoming remotely administered.                                                    Central -> Edge

Distributed computing replacing Remote Terminal (from mainframes)        Edge -> Edge

Client-Server replacing Distributed Computing                                                    Edge -> Central

Cloud Computing replacing Client-Server                                                              Central -> Central

Distributed Edge replacing Cloud Computing                                                       Central -> Edge

The Pattern consists of computing at the edge or in a central location.  Nothing really magical about that, but when a NEW technology comes in it’s almost always because we’ve either abstracted complexity away from the solution OR an evolution step in capability was enabled.

Take the case of Client-Server replacing Distributed Computing.  The effect was to move computing to a central location, this made possible largely by a significant increase in network bandwidth in the mid 1990s.  An example of an evolution pattern.

Cloud computing replacing Client-Server happened through an abstraction pattern.  Virtualization of computing systems allowed substantial recovery of compute investment.  It is also making smaller abstractions possible, think containers and serverless.  (also supporting one of my favorite quotes, from Rick Wilhelm @rickwilhelm, "Containers allow creation and destruction of application environments without drama or remorse.")

Effectively making the next evolution transition possible, moving workloads to the Distributed Edge, because … why should a programmer care where the program runs.

So, the IT Pendulum is only a pendulum if you look at it in two very myopic dimensions.  

The fight between good and evil, it isn't. It's evolution.

The IT Toolbox #001 - Definitions

It is vital that IT people communicate with the same lexicon.  This helps to establish definition which provides the specificity necessary to discuss complex topics.

The marketing engine, not to mention the general media, does little to correct ambiguity.  It can be argued that ambiguity in the marketing engine suffers ignorance in the hopes of capturing the next big headline.

This isn’t new.  Key terms do matter.  They are refined over time.

What makes matters worse, we often don’t know ~exactly~ what these terms mean until they are ingrained in a pattern that everyone comes to accept.

One of the best examples is Cloud Computing, “The Cloud” or just simply ‘Cloud.’

The problem with ‘Cloud’ is it doesn’t fit the definition of what everyone believes it to be.

The various definitions I’ve come across include:

Cloud is hosting on the internet.  (True-ish, but not very meaningful.)

Cloud is Infrastructure as a Service.  (It’s not only, but that’s OK.)

Cloud is Platform as a Service.  (A better definition, but also incomplete.)

Cloud is Cloud Native applications.  (This is about as ill fitting as Infrastructure as a Service.)

Cloud is Serverless.  (No, it’s not.  Never was, never will be.)

Cloud is where I’m moving all of our Enterprise Applications.  (That’ll be fun)
            Cloud is Digital.  (as in Digital Transformation, everyone talks about it, but few know how to                                           do it.)

If you’d like to read a thoughtful description of Cloud, have a look at this Wikipedia article: https://en.wikipedia.org/wiki/Cloud_computing  (16 pages and 125 references, 7 deployment models and 6 service models AND 23 disambiguation references)

What I’m getting at is that calling anything ‘Cloud’ lacks definition, its meaning has no precision what-so-ever.

Please make sure others know what you mean, when you say Cloud.

XXXX-as-a-Service aaS

The context of the utility to an as-a-Service capability in IT relies heavily on where the demarcation of use resolves.

It's much easier to see it in a graphical depiction.

In general, Infrastructure and a portion of the virtualization/abstraction are what will be acted upon by nearly all use cases (if we forgo the licensing issues with respect to those things more appropriately economical on bare metal).

On top of that you'd build out the as-a-Service for Infrastructure, which at the base level is virtualization/abstraction/operating system automation and management. 

Then you walk up the technology chain, including the management of constructs necessary for applications to be automated in build / test and delivery.

The last step on the technology chain is the delivery of what should be the most important element (though even today, we've people worried about HOW the underlying physical elements are doing), the Application delivery.

Tiers of 'as-a-Service' delivery

The Internet meme vs Cynefin

Stumbling across an interesting relationship can be interesting.  Was looking at a blog by Kees van der Ent on linked.in and realized that the header graphic could be related to Cynefin.

Thanks to Dawn ONeil presentation on checkup.org.au, I was rapidly able to mock up the concept, meme to the Cynefin graphic, and it became apparent that there is a relationship.

In Cynefin, Complex Collaboration is all about "putting thoughts into words."  It has to be described to work with complexity.  Consider how absolutely wide the fields of Information Technology have become, things as simple as definitions and TLAs may not mean the same things to different technology backgrounds.

Without this specific step in the framework, it's is nearly impossible except through experimentation to achieve anything remotely close to education.

This lends itself heavily to cooperation, taking complex concepts and reducing them to something relatable.  Quite literally "what I say to other people."

Reducing disorder even further, is were understanding really takes hold.  Concepts are extracted, reduced and put in overlay or contrast in such at way that it becomes "what people actually understand."

Declarative IT and Design for Operations

Was reading a very insightful and interesting blog from @TorstenVolt on Linked.in titled "Digital Transformation Requires Autonomic Computing 3.0" and started to see some commonality in the needed operations processes with a digital future.

This, by the way, is right after @AWS announces their AWS Outposts, a telling example of how coevolution in IT validates concepts and models (Yes, everyone, Hybrid is real, even Microsoft things so) and how terribly important it is to get to the data.

Torsten brings up some very important points about post transformational examples on what direction needs to take place.  It's very much like the conversation that @cpswan brings up almost every time we talk, how does the future solve the problems we see through Design for Operations.

The solution for Design for Operations revolves distinctly around Declarative IT plus a bit of truth and trust in the platform(s) associated with that same delivery.

I've done my best in capturing/mapping this in a Wardley Map as a way to illustrate the idea.

Figure 1.  Wardley Map showing Declarative needs and Design for Operations of IT Infrastructure

In general, IT Infrastructure Design for Operations includes a Platform for management of Declarative states of underlying infrastructure.

With the abstraction of server virtualization and cloud computing, the declarations became very much least common denominator and not very permissible with respect the evolution of application development (the Dev part of DevOps).  It eased operations of the abstracted layer considerably, but it didn't really enhance the Ops side of the infrastructure model.

At this point, we could argue that the Cloud Titans have already achieved a more horizontally evolved Declarative Platform, but now that everyone seems to be reaching back into the Enterprise Datacenter, permissible use and least common denominator may very well come into play again.

So, looking at the problem that now needs to be solved, truly Declarative Storage and Declarative Compute need to be pressed into evolution toward commodity to achieve the rewards of application integrated software definition of the hybrid datacenter.

This should go a long way toward solving the Design for Operations problems as well as matching up with @TorstonVolt's re-conceptualization of the Digital future state.

Wardley Mapping Technical Debt of a System

A friend of mine brought a question, can you map technical debt of a neglected system (edited) with Wardley Mapping.

I'm not sure it's possible in a single slide, mostly because the Wardley Map would require a time axis (or even a worker knowledge axis) to depict it in one slide.

To explain the entire idea, I'm going to use 8 slides such that the entire thought may be followed.  Please keep in mind, that this is entirely theoretical in nature.

For starters, Wardley Maps does have a couple of mechanisms that are useful for this depiction (See Figure 1 upper right).  The first one is inertia, represented as a solid bar and the second is a fat arrow indicating acceleration and deacceleration.

Figure 1 is a starting value chain map, with a system between the electricity anchored in the Commodity (+utility) area and a user need indicated in the most visible position.

Figure 1.  Wardley Map of system with Inertial marker identified

I'm placing the characteristic of Inertia in the middle of the system, with the supposition that there are no other forces acting on the system (like in physics).

Let's suppose then, that a deaccelertion is applied to the system by forgoing a technical upgrade in a part or all of the system.  See Figure 2.

Figure 2.  Stalling Update of System to N-1

This will impose an inertial movement from current position to the left.  See Figure 3.  Also note the "shadow" of Technical Debt in this drawing behind the system's inertial reference.

Figure 3.  System in N-1 State

The system is still within the Product (+rental) space and therefore there is no significant harm to how the system provides for the user need.

Imparting another deacceleration to the center mass of the system by forgoing the next generational needs of upgrading the system again shifts the center of mass of the system to the left.  See Figure 4.

Figure 4.  Forgoing update of system to N-2

See Figure 5, the system now sits on a precarious boundary between Product and Custom.  The possibility that the functions of support and management are greatly increased and the system itself may need some parts of its structure custom maintained.  The "shadow" of Technical Debt has grown with respect to the movement of the system.

Figure 5.  System in precarious boundary between Product and Custom

Forgoing another generational upgrade of the system imparts another deacceleration to the overall system.  See Figure 6.

Figure 6.  Further neglect of System to N-X

Continuous neglect of the system eventually leads to complete failure, where the massive "shadow" of Technical Debt of this neglect leads to system collapse through the technological inability to upgrade or loss of knowledge necessary to upgrade. See Figures 7 and 8.

Figure 7.  Continued neglect until system breaks

Figure 8.  Broken system (fully in Genesis) with Total of Technical Debt

Once the center of mass passes the Genesis boundary, the system is likely incapable of accurate function.  The user needs will no longer be met and that also may need to shift along with the center of system inertial movement or more likely be removed altogether.

As always, if you've any additional thoughts on this topic, I'm active in the twitter-verse @abusedbits

https://threadreaderapp.com/thread/1068822023126827010.html