The art of the digital transformation

I read an article about a New York restaurant that saw a significant impact to its business because of mobile devices playing a much bigger role in our lives. Even though the article is most likely fabricated it brings yet again to our attention how our world has significantly changed over the last 7 years and that we’re still adjusting to the new (and ever changing) reality of “smart” mobile devices.

In all fairness, this development didn’t start 7 years ago but we’re in the midst of an acceleration that not only forces whole industries onto these new devices - be they faster smartphones, smart watches or IoT - it is also driven by a shift in a variety of business models that accompany this trend. The beginnings of which we had experienced through the digitization of music, books, movies and newspapers by leveraging well established e- and m-commerce platforms. The introduction of the smartphone and especially the notion of context has moved this much further ahead into what is commonly referred to as the sharing economy. Good examples for this are Uber and AirBnB where a resource is shared among participants in a particular context. The companies behind this are essentially brokers of that resource. There is nothing fundamentally new to these models - what is new is the sheer amount of data and technology that is thrown behind these models to make them work efficiently.

Already these business models have put tremendous pressure on well established and regulated businesses such as Limousine and Taxi services or Hotels.
This trend of disruption to established industries will continue and the incumbents will have to become much more agile and flexible in order to respond.
The challenge with medium and large companies is that their IT mindset is still somewhere in the 90’s or early 2000’s where IT is largely looked upon as a cost center and the primary goal is to reduce costs and optimize the operations and not investing into IT know-how or infrastructure.

The challenge for these companies then is that at many levels they are simply not prepared for this new world. This is evident in the way that their existing processes can’t cope with the agility of new market demands - for example, the classical waterfall model that works when building bridges but doesn’t work that well when creating new applications in an ever changing and ambiguous world.

In short, these developments culminate into a perfect storm scenario between process, investments and infrastructure.

But that’s already old news. Here are three things that might help adjust and accelerate internal/external developments:

Choose your team structure (and/or location) wisely

Offshore, near-shore, on-shore and mid-shore are buzzwords with a single focus to cut costs. What is not a buzz word is productivity. All these mentioned models can work but there is always a give and take, short term wins and losses and long term implications.
Agile teams work best when in the same room for the duration of the sprint. Trying to do agile across multiple timezones and/or across different disciplines is hard. It’s not impossible but hard and the outcome will not be optimal. However it is also clear that especially for large decentralized organizations, it’s not viable to fly in whole teams for sprints. That undermines the primary reason why these teams were decentralized: to cut cost. The company therefore has a decision to make: keep certain team decentralized and fly in key resources when needed, relocate strategically (all resources to the same offshore center) or abandon the decentralized model in favor of higher productivity and higher cost. All these options work but they have to be done in such a way that the disruption to the organization is limited. More pragmatic is a combination of these models that can be implemented and then streamlined as the best strategy develops. The challenge is to keep the approach consistent and insulated from senior management reshuffles.

Lean Product Development in the organization

The basic idea behind the lean product development is to create an MVP (minimum viable product) that can be launched to gauge and measure the interest of early adopters (Test & Learn). The goal is to fail or succeed quickly before there is a significant resource commitment made. The MVP can be a non-functional mock-up of an idea or it can be a limited functional prototype. Anything that provides sufficient understanding to what the actual (or real) product will do or look like and that provides an opportunity to measure that interest.
Another core principle of ‘lean’ is to iterate over concepts until they are either proven to be failures or successes. To measure this, the product manager might use tools such as A/B testing or co-creation. In the case of failure, the MVP can be abandoned or a pivot needs to take place to steer the concept into a different direction. Obviously, the challenge is to recognize when the end of the line is reached and when further pivots become counterproductive.
The obvious challenge of this approach is the need to fail. This isn’t a very popular notion in large and complex organizations where someone's elbowing upward aspiration depends on successes. There are ways to mitigate this by, for example, outsourcing the process to a third-party but this only works if there is buy-in at the top.

Abstraction is everything

In complex enterprise environments, abstracting functionality through the use of services and API is fast becoming the remedy to reduce impacts to the infrastructure and the underlying systems. The idea is to create APIs (application programming interfaces) that standardize the underlying service in such a way that the consumer (or contributor) of data is forced to leverage the service the way it was provided. If there is a need to change the service (for example: to add an additional data element), this would be done as part of a new API release through versioning. The existing service would remain and continue to work. The result is: a) little or no impact to existing infrastructure, b) enhancements to existing services that every consumer can leverage [when ready to do so] and c) opportunity to externalize or internalize these layers of abstraction so that other parties and systems can benefit from the service. This all sounds complex and to a certain degree it is - the hard part is to set the organization up in such a way that IT groups follow the principle of service generation consistently. If they do, they will create platforms that can be tremendous sources of revenue and other benefits. The best example of this is Amazon where according to Steve Yegge, Jeff Bezos mandated that internal systems should only communicate through services. In his opinionated rant, Steve thinks this is the single most important thing Amazon has ever done.