Wednesday, April 25, 2018

Getting to the New Problems

At some point in the evolution of a product, a new product will come along and displace it.  Examples are quite prolific in IT, exactly like what happened with video rental, the entire market was replaced.

In the Settlers and New Problem entry, I made what turned out to be an abortive attempt at rationalizing this within the context of the Value Chain.  It should have been in an Evolution Map, as in Descriptive Evolution Mapping.

There still exists the issue of identifying new problems to be solved that create the displacement.  It can happen almost anywhere on the continuum of the product.  It's my feeling that it is the most identifiable and the most "felt" when the product being displaced is at the assumed stage of "Solutions to Known Problems" or "Refinement of Solutions."  That in mind, it can happen at any stage.

The following Wardley Map shows the associated change from the perspective of a Value Chain map.  It's also how, in "Next IT Shift, back to Distributed", the step function that could be used to show a possible future is realized.

The example, in "Next IT Shift, back to Distributed", implies that Cloud Computing is perpetually in a state of Refinement of Solution, but "Sensors, IoT and Machine Learning" cannot all be run from Cloud Computing:  This is the New Problem How do you get data to where it needs to be acted on with an enormously distributed system?  Should we try to move data in this way?
@swardley, WardleyMaps, Wardley, Maps, mapping, Evolution,
Getting to the New Problems

Tuesday, April 17, 2018

Descriptive Evolution Mapping

Thanks to @swardley and the community for steering me to a better definition of the Wardley Maps I was attempting to produce.

Wardley Map Evolution
Wardley Maps - Evolution Map

The graphic above introduces the product view of each phase of Design.

As a starting point, it is the output of the workload or application that has value.

The applications, and indeed the early computers, were Designed for Purpose.  They were also Custom built.  This is illustrated by the simple fact that repurposing an early computer may very well mean that the equipment necessary to run a different program may have to be changed in some pretty fundamental ways.

     Evolution of computing lead to computers that were capable of multi-purpose computing.  The applications were no longer specifically tied to hardware that they operated on (I know there's an argument brewing here, but it's the generalization I'm illustrating).

This provided the means for individuals and companies to run a multitude of programs on computing equipment.  This was a generational improvement in application development and lead to an entire industry of boxed software delivery.

     The box software products were developed within the framework of a particular operating system with guidelines about what and how commands were processed.  This is a manufacturing guideline and therefore we can identify the boxed software industry as Design for Manufacture and each "box" contained a Product on some type of media.

     Interestingly, the Product area is not necessarily the valuable output of the workload or application, but a means integrated to produce the valuable output.  This means that, while boxed software may very well be a Product, the overall application may still be Custom build, retroactively putting the entirety of said application back into Design for Purpose.

     Another interesting tidbit, the tight control over box software lead to the creation of competitors and the OpenSource industry.  This happened because the design of the overall application mandated variation that the box software vendors were either unwilling or unable to easily produce or it came at great licensing expense.

We reach another evolutionary state with what are arguably extremely easy to consume application outputs.  Built specifically with the consumer in mind and creating a service category (Utility Service) built upon commodity components. These are more easily offered in a volume consumption model of cost/volume-time.

     Utility specifically targets ease of consumption, foremost the usage mechanisms or operation.  It therefore represents a Design for Operations method of delivery.  Constantly being updated and firmly rooted in the idea that the easier it is to use, the more difficult it will be to replace.

     An interesting consequence of Design for Operations is that competitive pressures in Utility drive new business practices like Business Agility/Agile DevOps.

What's next you might ask?  google serverless, then google codeless

Friday, April 6, 2018

Settlers and the New Problems

There are some fundamental truths that drive technology forward, not meaning to be entirely inclusive, but they certainly include

     Technology evolves on top of other technology advancements
     Technology needs to be simplified or abstracted away from complexity to advance

This leads to interesting side cases of where the interdependence of technology must co-evolve with a relatively uncertain future state to continue moving forward.  Part of the solution is an evolution on top of the old technology and part of the solution is an abstraction to solve a complexity problem.

There are also characteristics of technology that meet as part of an industrialization of the technology.  Chris Swan @cpswan speaks on this very elegantly in the move from a technology that is design for operations rather than a design for manufacture or the design for purpose.

Industrialization of this sort is a stepping stone, much like the technology changes that move the state of the art from Town Planners back to Genesis and Design for Purpose.

Wardley Map Settlers and the New Problem
Settlers and the New Problem
Here's the diagram I'm using to try to illustrate this effect.  It is loosely based on the Wardley Map of  Settlers and an evolution step function that shows the evolution toward the "New Problems."

Looking forward to your feedback!

Update Apr 9: