Portability

Table of Contents


PORTABILITY

TTM ROI Sellability Agility Reputation

The ability to migrate an existing system, feature, practice, or dataset to another environment, with minimal change.

Portability is a more contentious quality, and one in which I often find myself vacillating over. Fundamentally, portability enables us to take an existing solution and move it (port it) somewhere else with minimal change. This is certainly possible, but why do it in the first place?

When I ask people to describe the benefits of portability, their answer is often of the ilk: “why, it gives you the ability to port”. As in, “surely it's obvious, no?” But this is describing the action, not the desirable qualities worthy for us to to consider performing that action. Let's start there.

Portability can promote great business versatility and Agility. Maybe you feel you're getting a bum deal and there's a financial imperative to move. Maybe it's to be closer to your customers. Maybe it's part of a merger or acquisition, or to leave your options open for operational costs, or discounts etc. You might simply prefer another offering. My point being, there are good reasons to port.

LIFT-AND-SHIFT

The Lift-and-Shift technique is a popularised term for what is - in essence - a Portability practice, in which we lift an existing solution and shift it to somewhere else. It's a term commonly associated with migrations from on-premise to the Cloud in order to reap some benefit from that new environment.

Whilst a tantalising prospect (extended product lifetime, better ROI etc), it's a common fallacy to think that Lift-and-Shift will solve all problems through a single wave of a wand. It often leaves us with unresolved “legacy” issues (e.g. inflexible technologies, poor practices, manual Circumvention, security concerns, slow delivery cycles, and costly scaling). Being portable doesn't necessarily mean the underlying system is healthy, only that it can be shifted.

So far we've established what Portability is, and why it's useful. But where do the challenges lie? We'll discuss the practicalities shortly - as with much in life, the theory is easier than the practice - but let's first briefly pause to consider the qualities that make up portability. Portability thrives on commonality and standardisation - i.e. I can take this and place it over there because that thing over there provides the same (or very similar) behaviour. It doesn't like proprietary and divergence - divergence indicates differences (or variations), and differences create complexity that reduces our portability potential.

One way to avoid divergence is to incorporate purely standardised technologies and tools, avoiding any whiff of the proprietary. This might include the runtime platform (e.g. Java), middleware, runtime services, tooling, or even configuration.

CONFIGURATION COUPLING

I've seen vendors provide an implementation of a standard, but then extend it with their own proprietary configuration, create a level of coupling (The Many Forms of Coupling) that we might not anticipate. We end up with a hybrid model, with some parts flexible (and portable), but other parts less so.

We must also consider all of the services that we rely upon. Consider, for instance, an application that persists its data to a specific vendor's relational database. Could we port that application onto another runtime platform (e.g. Cloud) that doesn't offer this database service? That depends. If that application only uses standardised features (e.g. ANSI SQL), then probably [1]. But most vendors also offer a suite of (proprietary) features unique to them, like UUID generation, primary key id generators, null checking, and paging. I could go on. And what about provisioning and administering them? That's almost entirely proprietary. What about opting for a specific vendor-managed NoSQL database, with proprietary APIs? We can't find the exact same service on the target platform, so we're either stuck with that vendor, partially stuck for that service, or forced to rework and regression test it all.

So what am I saying? It's unlikely that we can avoid any change, rather we should limit its Blast Radius. The larger and more complex the system, the more likely we'll (unintentionally) introduce tight-coupling onto something proprietary. A somewhat pedantic view might suggest we avoid any of this - the “portability without change” mindset, which is fine if we can sensibly achieve it, but it's not always practical, and as I describe later, may limit our Optionality.

STANDARDISED

I know of some businesses who chose the standardised model in order to broaden their sales reach to the most clients. Surely - you might think - this would be the SAAS model? But these were Business-to-Business (B2B) sales to large enterprises and corporate heavyweights, who had a lot of power (and therefore Control). By considering what their customers needed (and realising that the fully-fledged SAAS model didn't fit all of their customers' needs), those businesses gained a great deal of flexibility and Agility. They could do both a SAAS, and a single-tenant hosting model for those clients.

Some might view this as being too flexible, and certainly there's a fine line between supporting clients needs, and being dictated to by them. But what do we do if a client absolutely, categorically decides they will host it, or that it has to be their vendor choice?

Ok, let's now discuss what we may lose from being portable. To reiterate, standardisation likes consistency, and can promote Portability and Agility. On the other hand, divergence likes uniqueness (diversity), and can promote rapid change and Innovation. Consider the Innovation Adoption Lifecycle below.


It begins as a divergence (from the norm, otherwise it can't be innovative) and then - if deemed successful - it is normalised, (sometimes) standardised, and incorporated into our standard practices. But that activity takes time, and normally involves the agreement of many parties.

The Cloud offers a case-in-point. Each vendor may advance their platform in the way that best suits them. They can do this very rapidly, and connect things together with excellent Integrability options, but typically into their own (proprietary) services first. As customers we benefit, for example, with early sight of new ideas (and technologies) that whilst aren't widely available, may give us a competitive advantage, or the ability to quickly integrate. These vendors want us to be productive, but probably don't mind if we tie ourselves to their technologies. Divergence though hasn't yet become normalised so, by its very nature, probably hasn't been scaled. From a business perspective, normalisation occurs by embedding those techniques widely, allowing everyone to do it; from an industry perspective it typically occurs through standardisation. All that takes time.

If portability's advantages still seem blurry, don't worry. I too have found myself both its strong advocate and a steadfast adversary of Portability. So how do we navigate this thorny subject? Well, let's start with our customers, shall we? What type of customers are they, and what are we offering them? Are they single consumers, typical of a Business-to-Consumer (B2C) model, or enterprises, typical of a Business-to-Business (B2B) model? Or to put it another way, would they care about where (which platform) those services run? And if they do care, is it appropriate for them to?

Secondly, I think it's important to understand one's position on Efficiency v Scale (Unit-Level Efficiency v Business-Level Scale). It's easy to successfully argue that technology A will make someone more efficient than technology B, but can it be scaled? Can we broaden its use across the organisation before the next great idea arrives? As they say: "The King is dead, long live the King!" Businesses are littered with technologies that were once advocated, adopted for a short while, and then dropped when the next great prize arrived. Ad infinitum. Think about that from a Manageability perspective, or when complexity slows our Value Stream.

And finally, how do the engineers want to work? Do they prefer a more specialised technology platform (e.g. for its efficiency or integrability), or are they more familiar with standardised technologies?

PILLARS AFFECTED

TTM

There are winners and losers on both sides here. New, innovative, and (initially) proprietary technologies often offer significant Productivity benefits and high Integrability. So, great TTM potential from an efficiency perspective. But they don't always offer TTM from an Agility or Flexibility perspective. When we need the ability to port, we want it to be fast and easy.

ROI

There are very similar arguments for ROI as for TTM. As stated, Integrability in the Cloud is fast, but naturally it seems to happen quickest between vendor-specific services. Faster Integrability means faster value release, and thus, faster investment return.

On the flip side, should Portability be our foremost concern, then spending many months to make an existing solution portable is a good way to alienate our investors.

SELLABILITY

Portability's impact on Sellability depends on both the offering and clients. Rightly or wrongly, some clients have strong opinions on where they want their workloads (and data) to run. In the most extreme cases, they may wish to dictate those terms. A free lunch is a rare thing indeed. Sales is but the first stage of a relationship, and one that develops over time. Is the cost of maintaining the relationship worth more than the additional effort (and complexity) of multi-platform support? If it's not, then why enter into it?

On the flip side, most customers don't particularly care which platform their services run on, particularly if it's a SAAS solution. Portability here is irrelevant, enabling conversations to focus on features and SLAs.

AGILITY

Portability is most strongly aligned to Agility. From a business perspective it may open closed doors. Don't like a vendor price, or offering? That's ok, we can deploy your service over there instead. Want your services more localised? What about the platform over there? Want to move your old Java 8 service onto the latest Java runtime? Sure, that should be ok.

But we should also consider competitive advantage and nimbleness. Standardisation can be great, but it might leave us slightly behind bleeding-edge Innovation.

REPUTATION

A lack of Portability can have reputational consequences, but it's entirely dependent on context, and therefore doesn't have a strong binding.

SUMMARY

The aim of Portability is to increase business Flexibility and Agility. It offers us with greater optionality, and that's something we can pass on to our customers. But don't be fooled into thinking that porting requires no work; it rarely does. There's too many moving parts and temptations to guarantee that. Realistically then, Portability is about our ability to easily move a solution from one place to another, and that is predicated by our dependencies on proprietary implementations, or coupling.

COUPLING

Portability relates to Coupling, and how we tie ourselves to specific interpretations that we cannot find elsewhere. But Coupling isn't always the big bad wolf. It's ok to couple (we must somewhere) as long as we're aware of its ramifications. This choice isn't just technological, since it affects a business' ability to react and adapt. The tail does not wag the dog.

There's also the small matter of Complexity. Standardisation helps to create commonality and Uniformity, which is great for managing complexity, but not everything can be standardised. How we provision or configure our service may still differ per platform - does our business possess sufficient skillets necessary to do this?

Finally, whilst I've focused almost exclusively on platform portability, there are other forms. Data portability, for one, is another interesting concept.

“Data portability is a concept to protect users from having their data stored in "silos" or "walled gardens" that are incompatible with one another, i.e. closed platforms, thus subjecting them to vendor lock-in and making the creation of data backups or moving accounts between services difficult.” [2]

For instance, can I easily port my data from my current mobile provider or bank to another provider, should I find their quality of service unsatisfactory?

FURTHER CONSIDERATIONS