IoT - Wardley Maps WAR strategy

This conversation starts from Chapter 9, of WardleyMaps where it might be useful to use a map to look at the influences of predictability on a specific topic.

The next weak signal leading to predictability from Figure 106, future points of war, is what I'm looking at for Internet of Things (IOT).

I'm using a map that I've been toying with for a while.  The concept is relatively straight forward, what actions will lead to the industrialization of IoT?

We'll first start with what the map looks like for one aspect of IoT, I'm choosing data presented of some value to the user.

Figure 1. IoT User Visualization - Wardley Map

The second thing we should discuss is where value is derived.  Arguably, value is different to different people.  From an IoT customer's perspective, the value of the Visualization is far more visible than that of Power, Data Center or the computers it houses.

Therefore, if you're building IoT capability, the areas in the upper left are the areas you're going to want to invest in.  A simple representation of this idea on a Wardley Map looks like Figure 2.

Figure 2.  High, Moderate and Low Value on a Wardley Map

  The third area leads directly to pace, derived somewhat from Figure 2 and relevant because areas of attack should be at the pace required by the results.  Basically, don't lay siege to an entrenched industry, find the weak points for quick wins.

Figure 3.  Methods overlay on a Wardley Map

The concept is relatively simple.  Do you attack an IoT investment area in a Lean/6-Sigma area, that is already well entrenched and likely not to change rapidly, Figure 4

Figure 4.  Slow attack areas on a Wardley Map

 Or, do you attack an IoT investment that is in a rapidly changing area where it's using something like Agile Methods.  An area where the feedback to new method/enhancement/capability can be established in a very rapid method and is likely familiar to newer companies/organizations.  Figure 5.

Figure 5.  Fast attack areas on a Wardley Map

With that perspective, the WAR over IoT will be conducted, in general, in this area.  Figure 6.

Figure 6.  Iot WAR on Wardley Map

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

Evolving a Business Process with a Wardley Map, Part 2

Following on from Evolving a Business Process with a Wardley Map, we were discussing the Cost mechanism.

The question was, if we understand the BOM, "Can we get to ROM Cost quicker?"

5. Cost Calculator

This part of the evolution of the business process is actually more difficult.  It involves having ALL of the partner/vendors willing and able to work with you to create a Cost Calculator.

The good thing, if it is possible to create a BOM Calculator, most of the business logic is understood well enough to introduce the concept of Cost with the same (or similar) business logic.  The reverse is also true, we just needed a starting point.

In Figure 5, we're evolving a Cost Calculator as a product of the BOM Calculator output.  It is most assuredly in the Product category because it requires a product like update on a regular interval with the partner/vendor to maintain currency with their cost changes.

In Figure 6, we've created the new Cost method.

6. New Cost Method

The benefit of this change in process, we've shaved an additional 7-10 days off the Process.  We're also able to discuss pricing with a real BOM and a tolerance based Cost.

The problem, it is unlikely to be as exact as the Quotation step, but fine for ROM review. Providing we can live with small fluctuation between the Cost Calculator and the Quotation, everything should be fine.  Just make absolutely sure you understand completely the cost tolerance requirements.

7. Optimization Method

There's quite a good chance, especially with a mixed product-service opportunity, that there is potentially an unacceptable variation to the required tolerance without looking at Optimization of the BOM to ROM, Figure 7.

The Question for the Cost Calculator, "Is 1 large widget more cost effective than 2 medium widgets or even 4 small widgets?"

Consider the scenario where the product is a combination of labor, hardware and software licensing.  Optimization of the Calculators (a Calculator of Calculators, if you will) provides the means to create a deeper awareness of the product as well as a mechanism for Sizing appropriately for the need with cost in mind.

8. New ROM and BOM tool

We then shift our attention to Customer Pricing.

The Question, "Can we get to Customer Price quicker with better awareness?"

In the mapping exercise, we could very well have started with this question as it would be the most customer centric pursuit.  I'm not entirely sure it would have changed the path we followed, but I'm relatively certain it would have been a more daunting starting point.

9. New Costing and Pricing Method

It's obvious that a Calculator for pricing solves this problem the most expediently.

At this point, we've achieved the knowledge necessary to create calculators for the change in process steps.  We can also use those calculators to feed the Quotation requirements, potentially shortening that process step in Final Pricing.

The big win, we've moved the Sales Agent's view of the process from Custom Build to Product and improved his time to respond to the customer.

The overall process, from start to finish goes like this:

Customer Input -> ROM and BOM Calculator (as many times as Customer Input changes) -> Feed the Sizing from the ROM and BOM Calculator to Quotation -> Run the Quotation(s) through the Pricing Tool -> Sales Agent happiness

This Wardley Mapping exercise ended up being mostly about convenience, a bit about standardization.  How do you execute an On-Demand set of actions that would normally take between 22 and 44 days, in the shortest time possible?

As always, I'm interested in your feedback.  Find me on Twitter @abusedbits

Evolving a Business Process with a Wardley Map

Wardley Mapping (Value Chain Mapping) can be a great asset in describing the evolution of a business process.  In this case, I'm going to illustrate the changes of the Costing and Pricing action to show how improvements may be identified once the current or base activity is mapped.

In this scenario, Costing and Pricing, a sales agent needs to arrive at a Price for the customer.

The process includes engagement of a high skill technical person to create a Bill of Materials (BOM) for the customer.

It requires a Quotation that includes all of the BOM items, this is then used to create a Cost.

The Costs are then all rolled up, margin/cost-of-money and services/labor are included to create Customer Price in such a way that the Sales Agent may have a Rough Order of Magnitude (ROM) conversation with the Customer.

Here's what that map looks like.

1.  Costing and Pricing Activity

Keeping in mind that Wardley Map placement is relative, BOM activity is in the Genesis category primarily because "we know very little" about the customer desire until a BOM is generated to discuss and modify to the customer requirements.

Quotation is in Custom Build, because it is generated uniquely based on the BOM for the customer.  It is subject to change, also based on customer requirements.

The same can be said for Cost and Customer Price.  Without a customer qualified BOM, the entire process flow is subject to correction and reset until that action is completed.

The Question to ask, "Can we move this process to Product or Utility?"

2.  Optimize the BOM activity

Any one of the items in the process flow could be looked at for possible improvement.  In determining where to start, sometimes it is just picking a point and mapping out possible evolution steps and see what happens to the map.

In this case, we're looking at the BOM, if for no other reason than it feeds the more visible aspects of the value chain.

The Question for BOM, "Can we improve the BOM by creating a calculator for the BOM?"

There are some implications to this question, the principle one, can we create a standard method.  The standard method would be an idealization of the Bill of Materials in such a way that changes to it became mathematical multiples of or well understood relationships between the elements.  This implies a standard and baseline awareness of a design or architecture that at the very smallest level that consists of units that can be both measured and used as incremental building blocks.

3. New BOM Method

  In the case where that is true, the Bill of Materials Calculator (figure 3) can potentially replace the BOM action in Genesis.  Utilizing well understood units of measure, the calculator makes it possible to manipulate the BOM output to the customer desired goals/end-state much more rapidly.  The output of this tooling is arguably a utility in nature, but because it continues to rely on manual understanding/input, we'll put it squarely on the product/utility line.

The benefit of this change in process, we've shaved 7-14 days off the Process.

The Question for BOM Calculator, "How important is the Quotation?"

As it turns out, the Quotation with the source suppliers is only required when finalizing a deal with the customer.  So, as figure 4 indicates, we're going to skip over Quotation and start to consider the Cost analysis.  Because supply chain / purchasing requires the Quotation, we cannot remove it from the process, but it doesn't have to be done until we're in a position to make a purchase.

4.  Quotation

With Quotation removed (for the moment), and a good awareness of the BOM sizing activity we'll tie the BOM directly to the Costing activity.

The benefit of this change in process, we don't have to Quote each an every time we need to understand a Rough Order of Magnitude (ROM) cost.

The Question for the BOM Calculator mechanism then becomes, "Can we get to ROM cost quicker if we understand the BOM?"

In the next installment, I'll review how Costing evolves to improve the process.

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?

Getting to the New Problems

Wardley Mapping

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 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

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.

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:

Which lead to this:

http://www.abusedbits.com/2018/04/descriptive-evolution-mapping.html 

and then this:

http://www.abusedbits.com/2018/04/getting-to-new-problems.html

Enterprise Virtualization vs Public Cloud 2018 (Mapping, Wardley)

Enterprise virtualization prediction for 2018, tl:dr - no drastic changes from 2017.

There are some interesting possibilities, though, and I've used Simon Wardley mapping to diagram them.

Enterprise Virtualization 2018 prediction vs Public Cloud

As shown in the map on the left, we can now argue that the consumption of virtual machines has trended all the way into commodity consumption (with standardized tooling, automation and operating environment).  If it hasn't in your company, you may want to start asking why.

One of the more interesting possibilities for 2018, if the equipment vendors do this correctly, is composable infrastructure. This could completely displace traditional compute and push it into commodity consumption.  I'm going to leave it as a dotted line in the figure for now, as the business impact of technical accounting for corporations might make this a non-starter. That said, I have to imagine that a true utility in any premises would be good for the industry and the consumers.

In the public cloud map on the right, we may need to incorporate some changes based on enterprise use of public cloud to include the difference between “cloud native” capability vs enterprise hosting requirements.

Cloud native capability is the service consumption of the public cloud that relies only on the tools and capabilities built into the public cloud platform element.  Using it for new application development, including things like serverless application design, is growing as AWS and Azure partners and consumers learn to take advantage of those cloud native features.

     Cloud Native platforms are not particularly well placed for traditional enterprise workloads, though, which often require more specific (as well as traditional) care and feeding.  Furthermore, refactoring enterprise applications to take advantage of Cloud Native features may not be a worthwhile endeavor considering the cost to do transformation of applications.  The general thought is to give them a safe place to run until they are no longer needed. 

The enterprise hosting data center exodus from 2017 provides some of the highlights of why workloads will move out of the data center.  It may not be obvious, but the unifying element of both of the diagrams is how Hybrid Computing will be handled between enterprise virtualization and public cloud.  This integration still looks very much like early product (see diagram above).

One of the possible next steps is being taken by both Microsoft Azure and AWS / VMware who have announced methods to move non-cloud native workloads to their IaaS:  Microsoft Azure Stack and VMware Cloud on AWS.  Over time, both of these services should drive workloads more than "smooth out the peaks".  This is a major movement in what I’d titled my prediction last year, and why I say “Public Cloud Continues to Win Workload Love.”

If you've followed the mapping threads on my blog, here's the historical links on these predictions:

2017

2016

And if you want to know more about my Wardley mapping mis-adventures, follow this link.

updated 19 Dec 2017

It's about the data

A friend of mine recently asked me what my thoughts were around connected home/small business.  He's kindly agreed to sharing the response.
...

In my humble opinion, it's all just verticals until something comes along to unify things and make life simpler.

It is about the Platform today.  In the future it will be about how we act on the data we have.  This will most likely shift to AI in some IoT fashion.

At the moment, I think we're are approaching a Wardly WAR stage with quite a lot of the capabilities moving from custom into product. http://blog.gardeviance.org/2015/02/on-evolution-disruption-and-pace-of.html

It's pre-industrialization of the capabilities that actually prove themselves both useful and offset either a cost, a time pressure or a labor effort that typically seem to win.

It'll almost always be about situational awareness though. A person will eventually see the thing that stands to make a serious and significant change that takes hold of one of the ecoystems and gives it a big push.

That's almost always an abstraction of the capability. I took a wild swing at one of the computing areas as an example. The abstraction of programming I called "codeless programming" that uses visual context rather than programming languages to build applications. It's the next step past "serverless" where inputs are tied to outputs by people not necessarily programming any of the intermediary application chains. http://www.abusedbits.com/2017/04/codeless-programming.html

Zuckerberg is running an experiment along these lines with his integration of capabilities using an AI.

https://www.youtube.com/watch?v=vvimBPJ3XGQ 

Thing is, getting everything to work together is ridiculously complex. Either commonality in method for integration or something that can manage the complexity is required before this is anything other than a really expensive and time consuming hobby. And then there's the data capture....

My brother has a sensor network that he literally built into his house to record a variety of data. The first dimension value of that data was to have it and be able to view it. The second dimension value of that data is to macroscopically act on it, like integrated thermostat control based on conditions and presets. The third dimension value would be to have similar information from 1500 houses and use it to design houses better, as an example.

In each one of the industries you are thinking of, the third dimension values far outweigh the two below it, but getting the data AND being able to act on it is ... difficult. The connected home products are about the only way to get at that data.

Mapping Tool

Just did my first mapping with the @lefep tool at https://atlas2.wardleymaps.com/ 

Figure 1.  WardleyMap on @lefep web tool

My first thought isn't about the tool which was really easy to learn and use, but the download formatting.  It outputs .png.

The thought here is we should want to show it to people, talk about the map and make adjustments to it.

• Showing it in this format, perfect.

• Talking about the map in this format, great.

• Making adjustments to it... have to do it in the webtool.

Maybe something to put into the backlog, a story about users that may want to adjust the map or the formatting to fit a specific need.

Great job @lefep.  What takes me 20 min in Visio took me all of 5 min on the tool.  A certain timesaver.

Codeless programming

Based on the conversation of decoupled hardware and applications, there is a possibility of graphical code integration as only seen in specific environments.  See LabVIEW, Yahoo Pipes, etc.

In much the same way that we've created reusability in aspects of code in the creation of containers and serverless, there is likely an additional digital shift that can drive the mainstream of programming.

Figure 1.  Flirtation with codeless

Codeless is the further evolution of the composite of Application Chaining with advancement of Graphical controlled logic, conditional integrations and data mapping.

This becomes an inflection point in programming.  It is an abstraction of traditional programming that makes it possible to provide the capability to program to the masses.

It is graphical, utilizing common drag-and-drop methods with flowchart like linkage between sources of data and the manipulation of that data.

Codeless doesn't remove coding, much like serverless didn't remove servers.  It doesn't remove the need to create code using traditional methods, but it will be the means for the largely uninitiated to create meaningful output from code and application inputs.

If you want to have a glimpse of this possible future, have a look at what tray.io and zapier are doing.  (There are possibly more, this list is not exhaustive.)

Thanks to @swardley, @cpswan and @IanMmmm for bringing this to my attention. #mapping

The what all, of Enterprise Cloud adoption, and all

Was asked my thoughts on Enterprise Public Cloud adoption rate.

Sensors leading to Public Cloud adoption:

From an enterprise perspective, the volume of servers sold in the previous year is soft. http://www.gartner.com/newsroom/id/3530117

The partnership that can underpin legacy enterprise app deployments in hybrid cloud has been announced.  https://blogs.vmware.com/vsphere/2016/10/vmware-aws-announce-strategic-partnership.html

The drivers for cost containment are going to become increasingly important as customers look for lower cost of service.  This will probably start looking like “Use (AWS or Azure) for disaster recovery” and likely to evolve into “Application Transformation” discussions as optimizations within the cloud.  The best way to see this is with the directionality of utility mapping like the value chains between enterprise and public cloud: http://www.abusedbits.com/2016/11/why-public-cloud-wins-workload-love.html

Microsoft has announced an Azure Stack appliance to extend the reach of capabilities into the private cloud.  http://www.zdnet.com/article/microsoft-to-release-azure-stack-as-an-appliance-in-mid-2017/

The cost / unit consumption of private Data Center estate is anywhere between ~40 and 100% more than public cloud.  This is further being eroded by co-location vendors continuing to drive down the cost/unit for data center vs new build.  It is becoming very costly to build or retrofit older data centers rather than simply consuming a service at cost that can be easily liquidated per month.  The large scale DC vendors are also creating ecosystem connections for networking directly with the public cloud vendors and where those don’t exist, companies like AT&T, etc are enabling this type of service connection via their MPLS capabilities.

Then, there’s the eventual large scale adoption of containers that present some additional optimizations, particularly as they relate to DevOps that further increase density over hypervisor based virtualization and increase dramatically the speed of change.  Further extending this capability, the network vendors, the historic last line to move in 3rd platform are starting to adopt these concepts.
http://www.abusedbits.com/2017/03/creation-and-destruction-without-remorse.html
http://www.investors.com/news/technology/can-cisco-take-aristas-best-customers-with-software-bait/
http://www.crn.com/slide-shows/channel-programs/300084323/arista-networks-exec-on-new-container-software-offensive-and-its-biggest-fundamental-advantage-over-cisco.htm?_lrsc=9ce3424f-25d3-4521-95e4-eeae8e96b525

This culminates in public cloud providers positioning themselves for legacy applications, cost containment, cost based on their operating models, positions in DR if they can’t get production workloads, integration into private cloud where they can’t get principle workloads and certainly new workloads in cost/volume based on scale.

This leads me to believe that the position on Public Cloud, from an enterprise perspective, is just starting…..

DevOps is Sensing for Platform's sake

In the previous post on the high level reference architecture for DevOps, we identified the lifecycle attributes of modern application development.

The state of the art in application delivery is in a continual state of refinement, subject to the execution of economies on the Value Chain attributes of both infrastructure and platform delivery.

This is further enriched through the use of shared development (opensource, github, etc) and recognition of "future sensing agents" within the lifecycle of application delivery, particularly the exposure and refinement of APIs for the purpose of automation.

All of this is made possible by the continuing evolution of application development and operational support of equipment infrastructure at a fundamental/foundational level.  It is an OODA loop and seems to be accelerating in direct alignment with the practice of Agile Development.

Where 2nd Platform application designs supported an abstraction of the server through virtualization, the 3rd Platform is leading to distributed, run anywhere application lifecycles that provide the means to portability of workload on pooled Infrastructure as a Service (IaaS).  See Figure 1.

Figure 1. Application Development Evolution Steps

Compelling events in the 3rd Platform include the introduction of Software Defined Networking (SDN), Software Defined Storage (SDS) and Containers that provide the enhanced abstraction of the underlying pool of equipment.

With an appropriate sensitivity to the APIs that provide abstracted functions, the Operations service is being automated at the platform level by industrializing those APIs into Cloud Native functions within the Platform.

This is the "future sensing" that creates the continuing evolution of the Platform space. #mapping

map-camp.com

If you are a fan or simply interested in Value Chain Mapping, Wardley Maps or anything else in this area of situational awareness:

Simon Wardley @swardley http://blog.gardeviance.org/ is setting up a first of a kind event in the UK.

It will be a gathering of like minds exploring the depth of Wardley Maps.

Visit map-camp.com to gain situational awareness of .. situational awareness.

     http://www.map-camp.com/

I'm a fan, and here are some of my examples:

     http://www.abusedbits.com/p/value-chain-mapping.html

Next IT Shift, back to Distributed

Figure 1.  We're about to swing to Distributed Computing again

There's a lot to be said for the ever changing IT industry and 2017 should be a banner year in new things happening.

As a recap, in 2016 we saw the Digital Shift take hold of IT and give it a really good shake.  Starting 2016 everyone was asking if you had a plan for Cloud Computing.  I now hope that you do and if not......

There's a huge number of predictions for what the focus and industry will be looking at in 2017.  Of these, #Artifical #Intelligence or #AI and its many brethren (#MachineLearning #Robots, etc) are likely to impose a new Transformation Shift in the industry.

The way I think about it is #IoT with some #smarts.  At a most basic level, anything that can have a sensor applied to it is likely to be considered for an IT upgrade in the framework of an #IoT style device.  These upgrades will be sensors that record some type of data, maybe multiple types of data.

The result is a tiny sensor recording something that people find of value and would like to act upon.

This means data.  And when I say data I mean #LotsOfData.  Big Data levels of lots.

Because there will be so much data, it is almost certain that the data will require some culling and curating at the source.  So, there will be a tiny little computer attached to the tiny sensor.

The data from the sensor is going to have to go somewhere and I think this will have an effect on Cloud Computing.  We're about to have another pendulum swing in computing back to distributed processing of a sort.

Just like other swings, it will not eliminate the previous technology area, but it will force it to change.

Ideally, valuable data that needs to be acted on rapidly will need to have most of the computation done very close to the source.  The entire idea behind the #OODA #Loop is needed to take advantage of real time or near real time data.

Something will be needed to jumpstart the #AI training to make it all work.  This may be the resulting use of Cloud Computing, or it may create the need for a "Near Edge" Cloud computing capability.

Once the AI is trained, the tiny computer should be self sufficient enough to handle everything else it needs to do other than store the sensor data, making the "Near Edge" Cloud as much a storage system as anything else.

This means that the next transformation is going to make computing at the #Edge a reality again.

It's also likely to change how we deal with programming languages.  Logic programming will give way to data flow programming.  (Might be time to brush the dust off some old data flow language or build a new one).

Decoupled Hardware and Application Chaining

To start things off, I'm going to "abuse" the value chain from +Simon Wardley mostly because I haven't figured out a better way of describing this.

It is intended to be the start of a conversation, not the end of one.

The argument I'm making is that hardware from the classical/traditional sense of computing is procedurally being decoupled from the execution of the application.  To be sure, we saw some of this with the introduction of virtualization, but it wasn't so much decoupled as pushed so far down the value chain that application architects simply quit thinking of hardware. 

To understand how we get to that state, we should probably start with what has happened to hardware.  A high level depiction provided in Figure 1:

Figure 1.  Value Chain Evolution of Hardware in Computing

 Starting with mechanical computing in the Genesis (lower left) and showing each high level hardware change, like IDC's representation of 1st Platform in the range of Mainframe to "still" Mini Computer, 2nd Platform from Micro Computer to Server Virtualization and 3rd Platform with Cloud Computing and upward with outliers just kicking off in IoT and Private Computing.

Figure 2.  Value Chain of Software Evolution in Computing

Software from a hardware perspective has a more complex value chain with respect to the hardware.  While we could argue the position, the relative perspective can be used to illustrate the mechanics that have driven software and subsystems toward commodity.

A case in the argument being, the use of Operating Systems need to be product, providing ease of use, but input to something like computer Languages has to be custom because of the deep learning required to learn and master.  

This being as much a case of cost of the output of the products as the education needed to create the products and make them useful/use-able.

Ultimately there's something unique happening today that is not necessarily the easiest thing to describe.  Its called #serverless.

We've done things like this before with portability of languages like Java, where the execution method was abstracted away from the hardware sufficiently to run it on multiple hardware devices.

Today we're thinking about a more absolute abstraction of the hardware.  This will make it possible to decouple multiple and complex languages, libraries and applications from the hardware.

To show where and how this is happening, I'm overlaying these two value chains.  Apologies if I've just offended the #Mapping #Gods.

Figure 3.  Combined Hardware - Software

Upper right hand corner holds the primary elements to decoupling hardware from the software.  Hardware is still there, but is only important to those that have to care about it.  

The feedback loop of Agile Development with "Loosely Coupled, Message Event driven and Backflow tuning of the software plays a critical role in reaching the state of the Decoupled Application Function.  Quite a lot of this is to make the application more aware of itself.  

In the hardware area, some element of containerization (capture of all relevant parts of the execution of function of an application or sub application) moves the awareness of the application design away from the hardware to the operating system (arguably another abstraction of the function of the hardware).

Containerization provides the means to swiftly move the application or subcomponents from one hardware underlay to another (think one server to another or one cloud to another).

Ultimately this makes it possible to create components of applications that can become highly standardized or industrialized.  Something we might call #microservices.

These components being decoupled, can be called upon independently by API.  Sufficiently optimized, they can be spun up and down on demand for the execution of a particular function.

The application could simply become a cascade of API calls between decoupled application functions to create an output.

I believe the next trick is going to be related back to a platform mechanism.  We're going to need a schematic or blueprint to create / modify the application.  Something that can understand all of the sub-component elements and provide the messaging and feedback necessary to execute more complex arrangements of applications.

A platform that does Application Chaining.  

This platform could also abstract away the complexity in creation of an application.  With the most simplified models providing a GRAPHICAL interface to the creation of an application.

Also, the sensors that this would provide would be incredibly valuable to the operator of the platform.  It would provide advanced knowledge of new methodologies of applications and sub-components.

Carriers could eat the WAN and more

In the previous article I shared a vision of a future beyond SD-WAN.  Requirements for this are the Telecom Carriers specifically not forgetting about their customers as they roll out the Network Function Virtualization (NFV) modernization they are currently undertaking.

This really includes, and I can't emphasize this enough, a service interface based on APIs consumable by the customer.

This means that all of the NFV MANO work they are doing needs to have a customer control interface that allows the direct consumption of their service(s).  Automated and orchestrated service chaining that speeds current methods of delivery is simply not enough.

There's also a coup in the works for those Carriers that get this one simple idea.  If they enable their NFV MANO platform to provide catalogs of consumable code, a marketplace, pioneers in WAN service enhancement will be positioned to develop new services directly for the network.

The Carriers will be able to utilize the pioneers in the WAN networking space not only to enhance their services using this platform, but they can use it to create an exceptional "sensing engine" for future products and industrialization within their ecosystem.

Let's have a look at the possible step function to get to this future state.

Figure 1.  Step Function to Carrier Cloud WAN

The starting point in this step function is the circuit based WAN topology that was primarily single customer, with the majority of consumption in the T1/E1 - DS-3/E3 range.  Through some fits and starts, eventually the predominant delivery became a shared service mechanism utilizing Multi-Protocol Label Switching (MPLS) and delivery was nurtured from at the very least custom build to a product with last mile delivery being the time consuming effort.

In the previous blog, we showed that SD-WAN is well positioned for the edge services consumption model of the future.  There are some drawbacks, particularly in the current levels of standardization, but this may well be a short stop on the way to bigger things.  Eventually this technology will incorporate all of the interesting features of direct internet offload and direct to ecosystem connections through the evolution to Hybrid-WAN.

But, I believe there's an immediate follow-on the carriers should be looking into.  The provisioning of Enhanced Cloud WAN Services.  Carriers already own all the WAN packets anyway, why not provide add-on services within their shiny new NFV frameworks?  Why not open up the platform to developers to enhance those capabilities within that new platform capability?  Why not develop a marketplace to provide new services and use the pioneers to sense the future services to industrialize?

Should this come into being, the Carrier Cloud WAN, becomes much easier to envision.  It is the industrialized future of the Enhanced Cloud WAN Services with something as simple as an Ethernet handoff at the edge and a marketplace of services, capabilities and ecosystem partners made available for Utility consumption.

Will there be business and security concerns?  Certainly.  Keep in mind, MPLS was a business and security concern because of its shared service nature when it first came out.  It's everywhere now.  #mapping

This is a followup article to:

http://www.abusedbits.com/2016/11/value-chain-mapping-and-future-of-sd-wan.html 

Future of SD-WAN and the Value Chain

Office and business campus locations utilize WAN, or Wide Area Network(ing), for connectivity to other business locations as well as to Data Centers.

There's new technology that is poised to replace the legacy of routers and interesting circuit and protocol types.  It is called SD-WAN, or Software Defined - WAN, and is used to apply software rules and network functions (sometime virtualized) to provide more instant gratification in the area of Wide Area Networking.

Of the things that can be done with SD-WAN, one of the more interesting is a combination of two delivery methods, like traditional WAN using MPLS and broadband Internet (similar to what you might have providing internet service to your home).  This combination, called Hybrid-WAN and using special protocols (read this as non-standardized and highly proprietary) running on the WAN device can provide 

• higher availability at lower run cost through the use of broadband internet
• secure connected perimeter with direct internet offload reducing the cost of internet access
• more direct interconnect to services like AWS and Azure avoiding the hairpin in the Data Center
• attachment to vendor ecosystems that sell services like SaaS, VoIP, storage, backup, etc.
• enhanced security services within the SD-WAN provider's cloud

What is even more interesting is the trajectory of this particular technology.

Figure 1.  SD-WAN WardleyMap for 2015

In 2015, this technology was arguably in the Genesis phase of the Value Chain.  There were some initial entrants to this capability, but it was mostly laboratory exercise to determine the art of the possible.

Figure 2.  SD-WAN WardleyMap for 2016

There was a rather dramatic series of changes that happened in 2016.  The viability of the individual vendor solutions started to show through in the market and even major telecommunication vendors started to take note of it.  

Early in 2016 a major telecommunications company even announced their support and pending availability of SD-WAN in the form of a Utility service model.  Others followed. This shifts the financial mechanism toward commodity.  

Late in 2016 some of the early adopters of SD-WAN stated publicly that they no longer had a need for traditional WAN deployments.

Figure 3.  SD-WAN WardleyMap Prediction for 2017

My prediction for SD-WAN in 2017 will be a complete commoditization and Utility release of SD-WAN by every major player in the Wide Area Networking space, if not the announcement of partnership with companies that have this capability.  

This doesn't mean that the undercarriage of the service will be 100% utility though.  This first step will provide the means to change the usage behavior of the WAN consumers and not necessarily the underlying components.  It will erode parts of the current business model and there is still plenty of movement available to the providers to eek out more efficiency as the technology evolves toward commodity.

What happens after that is probably more interesting.  I've a feeling this is simply a stepping stone to the next WAN delivery model.    The telecommunication carrier's network is undergoing a significant technology change with a base in Network Function Virtualization (NFV).  

Basically, the carriers are in the process of technology change that will replace legacy systems with modern systems that look quite a lot like today's Cloud Computing environments.  

As this rolls out and reaches maturity, the carriers will learn that they can provide many of the services in their "Carrier Cloud" that their customers currently solve with hardware and appliances and take up data closet and Data Center space with, in a monthly Utility model.

Once that happens, there may be few reasons left to maintain WAN equipment at a site, where a simple ethernet hand-off and network functions in the Carrier Cloud at a monthly Utility cost will suffice.

My one single hope is that, as the carriers are developing and modernizing their infrastructure and capabilities, they don't forget the consumer.  With all of the Software Defined Networking (SDN) and Network Function Virtualization (NFV) in play today, I hope at least some of their APIs are pointed in our direction.

What does the extreme future hold?  #mapping

http://www.abusedbits.com/2016/11/carriers-could-eat-wan-and-more.html

If this is the case, I think we live in interesting times and not the proverb with similar words (1).

1 - https://en.wikipedia.org/wiki/May_you_live_in_interesting_times