To the IT department a minimum viable product can mean an opportunity to interact with customers with a basic new prototype. To a business leader, a minimum viable product might mean the minimum that is viable in the market. There are big differences between those two - from a few wireframes to help elicit interest, to a debugged system ready for prime time.
Very often business and IT have this underlying problem. They can see development needs in quite different ways. They might talk past each other. They can be in conflict. For companies aiming to break down silos, that kind of conflict can be the single biggest barrier to success.
To get a good dialogue going all sides of the business need to learn each other’s language.
THE NEW LANGUAGE OF IT
In the IT environment a new language has evolved around new brand names like Docker, concepts such as containers and microservices, PaaS, IaaS, continuous delivery and the tools or methods (more visible knowledge for example, devops, MVP, sharing tools like Slack or planning tools like Trello) that support “the new IT stack”.
Not all developers are up to speed with these changes, and business people certainly are not. An important component in this new mix is the fact that the risk profile of a business changes as it begins to experiment more with new ideas. The experimental enterprise has to be collaborative if risk is to be contained.
How can business people learn more of this new environment so they enter the IT Business dialogue as equals?
THE NEW IT ENVIRONMENT
The business person’s entry point to the modern IT world is usually the API – the application programming interface.
Standing in the Costa coffee shop in a London hotel is a case study in a successful API.
Look at it this way – APIs let services interact. We think of them as software but actually the integration of two businesses, say Costa and Hilton Hotels, is a bricks and mortar API. The application is third party coffee shop provision and it is programmed by a contract and Costa’s brand promise.
Most business people think of APIs in this way – the API is a mechanism for getting two or more services to appear integrated.
However, software APIs are now changing and are becoming an essential element of the wider IT infrastructure, knitting together many “microservices”, or small software packages that replace older “monolithic” software architectures.
APIs are becoming more important but not just as a way of engaging third party innovators in business ecosystems or for accessing legacy assets.
As IT switches from being an infrastructure guardian to a driver of new business opportunity, pioneers are re-architecting the business around those smaller software packages.
In this new environment, where there is much more software communications, the API becomes the connector for a more modular IT system.
Business people will come across the language of microservices (which are often packaged in containers) and might confuse them with the language of business services.
There is more language to learn! “Containers” are the deployment and scaling packaging of microservices. New software and services are coming to market to orchestrate their interaction and in the process to scale their deployment.
This same architecture is moving to continuous deployment (CD) or continuous delivery – the holy grail of innovation where there are opportunities to improve customer experience continuously.
In an ideal environment, these different elements create the conditions for greater experimentation – after all, a new application, or feature, requires a much smaller adaptation, i.e. change at the (micro)services level, rather than change to a monolithic system.
Business needs to be onside with the idea that relationships with customers will become more experimental too!
Architects are redesigning systems so that developers who know containers can be up to speed and productive very quickly when they join a new firm or project.
The other big payoff is that this type of architecture can scale. It doesn’t create the drag of legacy.
On the downside it also means though that IT shops have to learn how to orchestrate multiple containers – maybe hundreds. Developers, designers, operations and business people have to learn to work together. Meanwhile business leaders have to pick their way through this. IT colleagues can be busy learning this new domain and short of time and patience when it comes to exploring its value in some instances.
The key for business is to be aware that they need to think more in terms of which customers or prospects might be willing to become part of this more experimental environment.
That is scary to some business people. Often it is structurally difficult to achieve because client relationships can belong to teams that are not part of the business-IT dialogue. For everyone it means operating in a looser environment with key tenets that are different from the traditional.
The companies that have benefited most from this approach are, not surprisingly, those where the culture is intrinsically interdisciplinary because the business proposition is IT-led.
Think Netflix, which is scaling a global video streaming business. Of course it needs marketing and it needs branding and sales but the basic proposition – create a global streaming business that can deliver to any device (they currently deliver to over 1,000 different types of end terminal) is, at its heart, an IT proposition.
Netflix faces an unprecedented technical challenge, so the new tenets of business really suit it. In fact Netflix has pioneered light touch guide-rail style management where most activity is guided by a few broad brushstroke rules
- Be experimental within the guide-rails
- Be driven by customer needs
- Use evidence
- Drive out cost
- Scale everything
Despite the fact that these approaches have been pioneered by tech companies, the achievements come from interdisciplinary work.
The key aspects of this change are best managed through much lighter touch supervision – typically allowing for much more developer and business interaction and autonomy. That is, in itself, challenging for any company, especially those in regulated industries.
In the same context though it involves more business discipline, particularly in the use of the extensive amount of data that an experimental business environment creates. Business becomes more evidence based.
There is one more feature to this. Companies that get it right have access to much cheaper forms of scale. It provides real competitive advantage.
So going back to the beginning, how do you get around problems like two entirely different interpretations to a term like MVP?
It comes back to customers. There are customers for whom anything other than a system primed for prime time is a failure.
However, there are customers too who are on their own experimental odyssey. If the focal point is experiment then everyone is learning, everyone gets payoff even if the cooperation fails in some way. The business-IT dialogue can only work if it is focused on those like minds.