Technical Debt, and Wookiees™, in a Star Trek™ world

In information technology, the goal of design is 100% uptime, be it of the equipment infrastructure (and oh by the way we shouldn't be doing this anymore) or the application (it's really what we care about).

I often think of this as the Star Trek™ conundrum, where the desire is to have something absolutely perfected.  In this way, it will work the way you want it to, when you want it to, each time you want it to.

The components ideally fitted at the subatomic layer for exactness.  Software tested to be infallible. The entire system redundant with tolerances that leave no excuse for failure.  All parts upgrade-able and replaceable within a specification that meets the test of time.  Ultimately, the ideal of the star ship Enterprise.

In other words perfect.

This perfection ends up being quite expensive, so the tolerances are loosened.  The software is released in stages of development.  The parts have finite longevity with future specifications not well understood.  Redundancy placed where traditional mechanisms fail the most frequently.  Sort of like the Millennium Falcon.

So, there will be a really tall and hairy guy with an intergalactic spanner wrench banging on the console of a component that is failing due to something else failing in the power room, 100 meters away under the floor.  It is inevitable.

As the Wookiee™ is banging on the console, just remember that at some point it did the Kessel Run in less than twelve parsecs.

Maybe it's time to establish a new Kessel Run record.

NFV - Service Consumption

As the telecommunications industry starts delivering on Network Function Virtualization (NFV) via delivery of Virtual Network Functions (VNF) there should be a consideration for the service consumption mechanism that is driving this industry.

Consider that startup players in the market are approaching this market segment from enabling developers to directly integrate with their systems.  As the network ecosystems have evolved to include demand based services, these new players are providing the means to directly consume services that have been historically managed services.

There is a direct parallel of this model with the likes of Amazon Web Services and Microsoft Azure.  They have build a platform and enhanced it over time to directly address the service consumption model.  As a demand based service, compute and storage have largely been commoditized, or in the vernacular of the Value Chain, they are utility services.  You pay for what you use.

Telecommunications carriers need to be aware of the conditions this placed on the entirety of the IT market.  It shifted major capabilities to Hybrid Cloud and may further shift the entirety of workload execution to this demand based service area before the next major scale out.

During this evolution, traditional managed services may not survive in their current state.  Further, the directional of OSS and BSS have almost always been northbound.  As the digital shift continues, these functions need to be both North and Southbound.

Finally, there cannot be enough emphasis on this, this is technology segregated by logic.  Policy Enforcement that is well understood and tied together from MANO Service Chaining to VIM and finally to the consumer needs to be a foundational part of the plan of service delivery, enabled and enacted upon by API and made available to the masses that will be in a position to consume it.

The evolution of this space is ripe for a lambda function like execution in its maturity.

WAN Ecosystems - Evolution

Looking forward to the day of enterprise SDN and NFV for WAN service delivery.

This graphic is how I'm depicting the evolution underway:

WAN Ecosystems

Area 1:  Move toward Virtual Network Function, where individual devices are replaced by virtual network functions on as close to commodity x86 servers as possible.  This is a very pragmatic change that is already underway, with major companies like AT&T and their Universal CPE.

It will allow the edge to evolve in software timescales rather than hardware timescales.  It also makes practical large scale deployment at fixed monthly costs.

Area 2:  Deliver Ethernet to the edge and run the Virtual Network Functions, along with Enhanced Cloud WAN Services from within the Carrier estate.

Area 2 may have dependencies on local capability requirements, like application acceleration.

Consuming services from the Enhanced Cloud WAN area could provide rapid evolution, in software, of things like security perimeter enhancements as well as more options in routing traffic.

Area 3:  My personal favorite area.  Deliver any connection to any service within the ecosystem, on demand.  Programatically.

The delay between want and ready reduced from weeks to minutes if you are already attached to the ecosystem.

Make everything catalog based, so the order to fulfillment time for pre-existing customers is under their control.

Eliminate "stickiness" wherever possible.

There are some maturing vendors in this space and hopefully adoption will pull standardization along with it.

As the Pendulum Swings

Figure 1.  As the Pendulum swings

There's a relatively constant motion in the IT industry that we tend to think of as a pendulum.  As technologies evolve, we often see a swing toward "what was old is new again" and "what was new is old, again."  

It is at least partially represented by these two graphics.  

The first being price vs performance.  We often liquidate performance for price as we abstract or redefine products.  There are evolution resets that cause it to restart again, frequently to the detriment of the previous technology course, but often looking like something that skipped a generation.  This is a foundation of the pendulum swing and why we think of it as a pendulum.

The second can be thought of as dedicated vs general purpose or locked in vs open.  As an example: IT functions dedicated in hardware are created to optimize performance, at the expense of great cost.  IT functions created in general arrive with a performance penalty vs the dedicated systems, but become extremely versatile.  These will often lead to a stair-step function in the next technology evolution.  This doesn't correlate directly with the pendulum swing but a shift in position of the pendulum, see below..

Figure 2. Efficiency Improvements - shift in position

Special thanks to Simon Wardley @swardley - http://blog.gardeviance.org/  mapping