Business are changing, segments are disrupted by new, fully digital enterprises. Information Technology is creeping in everything we do. Some call it the digital enterprise, others digital transformation, yet others industry 4.0. What-ever the name, companies better understand what happens and act on it.
Digital Natives, a disrupting force
Start-ups, appearing from nowhere, disrupt whole industry segments. Amazon changed the bookstore forever. It also transformed the IT industry. Uber and transportation, AirBNB and hospitality, Spotify and the music industry, Tesla and the car industry are all similar examples. These are digital native enterprises. At their start is the use of information technology to address an existing business differently. They have no ties to the old way of doing things, they have no assets. So they have all the freedom to innovate as they start from scratch. A group of generation X/Y engineers in a garage or a basement, that’s all they need to get going. Enthusiasm, the belief they can do things differently, an excellent idea and a lot of sweat gets them going. The rest is history.
Because they start under the radar screen they have the time to build a basic service before they expose themselves to competition. And as Uber showed, competition can be rude.
But you are a Digital Migrant
This is all very nice and fascinating, but you are part of an existing enterprise having a position in the market. You have an existing business model, applications supporting that model, maybe channels to market, a brand and above all, a reputation to keep. You cannot suddenly transform you in a digital native, except by creating a separate start-up.
So, what can you do? Should you just cross your fingers and wait for a disruptor to enter your market? No, you can transform yourself and become what I call a digital migrant. For many enterprises this is counter intuitive as it will most probably imply that you will end-up competing against yourself.
The next argument I often hear is that you cannot just start from scratch as a digital native will do. But why should you? You have many assets you can re-use. You just need to make sure they do not become barriers. Your enemy is most often not technological but organizational and cultural. Let’s look at how to take advantage of these assets.
Design and document your new business model
The first thing to do is to design and document the business model you want to follow. In this you are no different from the digital natives. Put a small team in place and have them work at this business model. Don’t stop their creativity. You know your market much better than most digital natives. That is both a benefit and a barrier. You can judge how the market will react, but pay attention as this may limit your creativity. Steve Jobs used to point out that, if you wanted to be truly disruptive you should never ask the users (the market) as they are unable to imagine breakthrough ideas. There is some truth in what he said. Don’t invite the “advocate of the devil”, he or she will kill all your good ideas.
You must take an entrepreneurial spirit. It’s important to recognize you may not have it right the first time. Accept failure, but take the time to analyze the reasons and extract the learnings. Make sure the team that is working with you will understand they are not at risk if they fail, or they will become their biggest censors and this is not what you want. Build a spirit of experimentation. Try ideas out, look at the reaction not just of your customers, but of people you never did business with. Take what you learned in the next experiment and so on.
Don’t rush to build the digital platform. That will come in due course. In the early days the limited amount of clients may enable you to do a lot of things manually.
Design the supporting business processes
Once you have a potential winner at hand it’s time to get the back-office going. Don’t develop everything from scratch or rush to your existing applications to transform them.
Put the team in a room and design the business processes that will support your business model. Identify which step in the process requires “digital support”. Describe the service you actually need to support the process step. Identify the data you require.
This is an important step. It will achieve two things. First it will help you gain consensus of how the business model will operate in practice. Second it will allow you to understand what digital functionality you need to put in place. This will lead to a review of the existing landscape and a re-use of components that are already existing. But that functionality will have to be “migrated” to the digital world. This is why I call existing companies making the move “digital migrants”.
Analyze your application portfolio and re-use your digital assets.
You now have a description of the services you require to support your new business model. Identify what functionality is already existing and in which application it can be located. You now have to decide whether your new business model will cooperate with your existing business and use the same IT environment or whether you want to create a completely separate environment, fundamentally splitting the company in two.
In the first approach you will need the existing IT environment to address the new requirements, in the latter you may want to “fork” the identified functionality, transform it in services (in the SOA sense of the term) and run them on the platform that is dedicated to the new business model. You will need to expose the functionality using APIs and depending on the role of the functionality, you may have to transform it so it becomes cloud aware.
What do I mean by this?
You’re going digital. The experience your end-users will have from your service is paramount for adoption. Having a second to none quality of experience is critical. So, it’s important to understand how your end-users will access and operate the service. Particularly if you touch them via mobile devices, the utilization pattern is most often unknown. Your back-end services need to respond swiftly regardless of the demand. This leads to the use of cloud technologies and its capabilities to scale-up and scale-down services. It leads to loosely coupled services connected through a message bus. Each service should be self-contained and not rely on another service so there is no wait time. You may want to re-factor the functionality you identified to ensure it follows the above principles and delivers to your client the experience he expects. One mandatory element is to ensure the functionality is exposed through APIs. If you can, use Restful APIs as these are widely used.
If you’re going with the first approach, think through whether you can keep the required functionality within the application. It is the easiest way of doing things, you just need to expose the service. However, if, as described above, the service needs to scale-up/scale-down, you will end up scaling up and down the whole application. Can it cater for that and what are the implications? If this is inconvenient, you will need to split the whole application in separate services each running in their own VM or container.
One alternative is to take a copy of the functionality you require and create a separate service with the extracted code as a basis. In that case the original application will run the existing business while this new service will take care of the new business. Is this feasible within your organization? Can I have two different services performing the same functionality? That should be analyzed on a case by case basis.
Going Digital, mine your applications
Where start-ups need to create their supporting IT environment from scratch, you can take advantage of the functionality you already have available in your application portfolio. Take advantage of that. Review how you can transform your applications to address both the existing and emerging businesses.
Looking forward to your comments.
Have a great year end. I wish you all the best.