My first thought when considering digital transformation, and drawing on my academic background, is to see it as a heavy-sided function with a scaling factor of one. It is only natural to see situations through a subjectively tinged filter that builds on past experiences. If the right perspective is lacking, this may lead to problems because, as with cargo cults, the issue might be oversimplified. This simplistic model is then used to address complex questions. Every analogy has its limits, and it is important to be aware of them. If a wave equation is to be solved, then knowledge of quantum mechanics is required. Applying this thought to digital transformation means a serious approach requires executive management to have thorough knowledge of information technology and how digital business models work in practice.
Scaling factors in digital business models
Digital business models are primarily characterized by scalability without requiring resources to scale linearly. In other words, for a given customer base, if you double the number of customers, you do not need twice as many staff or twice as many machines, as long as the process design is adequate.
Of course overlapping does occur, like in major internet-based mail-order companies. Logistics is key here, and automation can bring about huge efficiency gains. Relatively speaking, these have greater impact the higher the volume processed. However, if a business model scales up in direct proportion to the resources deployed, the question then has to be asked whether it is actually digital.
The ability to improvise and perfectionism
The design patterns common in analogue processes are often used in digital models. Just imagine you are in Raffles Hotel in Singapore and you don’t want to order a Singapore Sling, but instead would prefer an Old Fashioned, but the latter is not offered. You will still get the drink you wanted and the bill for it too. That means the bar-man has given you an item that is not included in the product catalog. He has also worked out an approximate price. In other words, he has improvised, something application programs can still only do to a very limited extent. Anything that is not explicitly envisaged in a depicted business process, cannot simply be solved by an algorithm.
If you’ve only got a hammer …
Both scalability and the need to differentiate all business processes mean that it is the speed of change that has the greatest impact on commercial success. This is because each new function has the potential to translate into an immediate business benefit and offer higher customer satisfaction.
Digital transformations are often seen to be similar to a product launch, i.e. without the corresponding implications on organization and collaboration models. Successful enterprises with fully digitalized business models have developed new forms of cooperation that support them as they continue to strive for greater efficiency.
Waterfalls and their levels
The tendency for long latency periods between idea, conception, implementation, testing, acceptance, and live launch means a waterfall approach is not the optimum for projects. After all, each function can lead to increased concrete business benefit and, on the other hand, digital business models are ultimately capable of being scaled up almost without limit as long as there is customer demand. This means that an effort should be made to test new functions as quickly as possible (“fail fast …”) and bring them to market as soon as possible (“… and iterate”). For instance, most bank customers do not want to change banks, they merely want the new function because it makes their life easier. For example, fintech companies have had years to build up their customer base because the competition is so sluggish. Against a background of 18 to 36-month release cycles, market shifts suddenly appear to be the logical result.
Process support or business model
Digital transformations often suffer from the tendency to view IT as a process support rather than as a business motor. This view is reflected when IT departments are run as a cost factor, with resulting pressure for local optimization. This is often carried out at the cost of overall complexity and leads over time to a hodgepodge of workarounds and hacks. In modern IT-geared enterprises, these are known as “technical debts”. However, data and service-driven companies, especially ones with purely intangible products, are nothing more than the sum total of their IT. Every department in an isolated state can take a week off without causing much of an impact, but if all the computers are down, everyone might as well stay at home. Indeed, they might as well stay there permanently.
Digital transformation and approaches to governance
Changes in technological and organizational prerequisites result in completely new governance models with a stronger focus on taking responsibility and a collaborative approach. This is due to more stringent controlling possibilities. An ongoing improvement is usually evident in estimates as well as in the number of completed story points (SCRUM unit of measurement for projects) by means of cost estimates, reconciliation of ad hoc estimates and post hoc measurements, and tracking of KPIs over time. Development time usually correlates to a steady decrease in the number of bug tickets, i.e. errors that arise and must be corrected. The clear improvement in self-monitoring together with collaborative work models mean that external supervision may no longer be needed to the same extent as it was before. Work should also be organized much more collaboratively across the organization, meaning that “product owners” from the affected areas participate closely in development from the very beginning rather than throwing a specification of dubious quality over the wall.
In the iron age of IT, all systems had to be linked to physical hardware. This involved intensive and often repetitive manual provisioning and maintenance. In native cloud architectures, systems and applications (even including networking etc. to some extent) are abstracted from the physical infrastructure. Provisioning and maintenance can thus be delegated to software by means of high-grade backend interfaces that can be automated. Changes can be carried out quickly, and fully reviewed. It is possible to define automatic fallback scenarios (e.g. to a guaranteed working version and configuration) and change management processes can be sped up and reduced to essentials. The fully automated deployment pipeline from the development computer to production is termed continuous integration. This allows enterprises like Amazon and Netflix to make up to 120 releases on a single day. Bill Baker of Microsoft summed up the scenario of server-independent applications in the aphorism “Servers should be cattle, not pets”.
The technical and organizational opportunities together with demands for rapid change and new functionality have brought about a tremendous boost for agile approaches such as SCRUM in recent years. From personal experience, we can say that it is very well suited to tasks ranging from relatively small implementation projects to the total transformation of complex bank architectures and the implementation of regulatory requirements. Furthermore, it is significantly better than the waterfall approach in many cases.
Agile methods with tight feedback loops between IT and departments lead to better mutual understanding. That, in turn, means higher quality implementations in a shorter time. Sometimes it may even make sense to begin the integration process much earlier on, and design the entire product cycle together with the departments concerned, from product development to front and back office, or transaction handling to development and operations.
In the vast majority of cases, better optimized processes are enough as a first approximation. This is especially so if steps can be carried out in parallel. Experience shows that calculations are rarely carried out across the entire portfolio even in the banking sector. If you have developed your application to be stateless and capable of running in parallel, so that you can operate it on a scale-out basis rather than scale-up, you have a well-tailored microservice architecture, and a good application architect was commissioned before the implementation phase to design a module plan, then you should watch out if someone around you starts talking about big data and in-memory databases. These technologies are often used to try and solve implementation problems rather than as a way of clearing real performance bottlenecks. Reorganizing batch processes and process management may often be a much more effective way of improving performance. “Infrastructure as code” and elastic infrastructures can even be used to allow resource usage to be dynamically adapted to requirements. Consequently, machines and applications only need to run or be scaled up if the capacity is actually required, and architectures no longer generally have to be designed for peak load.
When you plan your new infrastructure, think of Antoine de Saint-Exupéry: perfection is attained not when there is nothing more to add, but when there is nothing else to take away.
This blog post was originally given as a talk on November 3, 2016 on the IT Application Performance Day at COREcampus.