We recently had a discussion with a group of colleagues on the dynamics of digital transformation. I thought it would be useful to put featured arguments down in black and white.
As far as digital transformation journey in an enterprise is concerned, one can talk about human and corporate culture, strategy, processes, equipments and technology as the contributing factors.
Technology can be considered as a catalyst that gives boost to the effectiveness and efficiency of equipments and processes. In other words, it is embedded into these two factors. On the other hand, equipments as a factor is the most and fastest changing of all, depending on the circumstances of the day.
Among all factors, needless to say, human resources and corporate culture is the most influential one(Culture eats strategy for breakfast. Peter Drucker). A reliant, committed, resilient and hard-working team can and will make up the inadequacies and inefficiencies in the strategy and processes. They will eventually achieve the desired goal even if it will not be in the most effective and efficient manner. Especially if they are involved in the decision making processes, they will hit the target both not to be ashamed and not to put to shame those who involved them.
However, the team has to be mostly in a GTD(Getting Things Done) mind-set as phrased by Joel Spolsky. Along with being smart, the essential requirement of being GTDer is to be resilient and result-oriented as opposed to be picky.
Unfortunately, it is unrealistic to expect the majority of the employees of a large organization to be in a GTD mind-set. Yet, there have to be core teams throughout the organization that are mostly comprised of such personas to drive transformation.
It might be tempting to put forward the “Tech. Monkeys” whose primary focus is playing with new technologies rather than adding value since they give the impression that they are very well aware and having good command of new technologies. Even further, they might make some meaningful contributions to the projects in varying degrees depending on their personal traits and motivations. However, building the backbone of the teams on such tech-monkeys and exalting them on top of GTDers would be an inappropriate strategy, because they are neither resilient nor value-oriented. They will dislocate the focus from adding value to playing out or experimenting with new technologies.
The GTDers who rightfully gained the explicit or implicit respect and appreciation of their colleagues must be strongly represented in the core star teams even if they do not perfectly master the technology stack in question yet. The benefits of building star teams around GTDers include;
·They will lower corporate resistance against change.
·Since they know very well where the true value and big risks lie in the existing system, they will make better prioritization and execution.
·They will avoid and prevent over-engineered systems that can be built with FOMO(Fear of Missing Out) psychology.
However, mixing these profiles with somewhat avant-garde profiles could be helpful to attain an optimal balance and encourage fruitful discussion. Furthermore, GTDers might put on the back burner to look at the greater picture from a bird’s eye view with a long-term perspective because of over concentrating on the healthy execution of daily routines. The true leadership must bring them to that long-term point of view for the good of both the enterprise and their own career advancement.
We can make an analogy between this core star team and a special operations team. The most critical characteristics of a special forces members is not how they look, not how big, hefty and muscled they are but rather how brave, cold-blooded and indestructible.
We can think of this core team as pioneering troops trying to take over a fortress. The primary goal here is to break the castle door like a ram, flag the walls or infiltrate and neutralize the most effective points of resistance inside. In other words, this team must attack the most difficult and worthy mission. Hence, it will be possible to establish a belief, morale and motivation in the rest of the team and to spread the desire to be a part of success with a snow ball effect.
One of the important issues related to the transformation strategy is to correctly shape the perception and culture of the evolutionary change. A luminary figure in Software Engineering, Fred Brooks, in his legendary article “No Silver Bullet Essence and Accident in Software Engineering” in 1987, says “the software product is embedded in a cultural matrix of applications, users, laws, and machine vehicles. These all change continually, and their changes inexorably force change upon the software product”. This implies that no transformation project is final. At an increasing pace, a never-ending quest for change will come into question. Therefore, it is necessary to inscribe this fact to the DNA of the enterprise (Change before you have to. Jack Welch).
At this point some people might be tempted to think that “If we happen to design the core business model in a perfectly isolated model we would be able to accomplish occasional transformation projects with minor cost and effort, without much hassle”. Although it does help significantly to make powerful abstraction of the core domain model, unfortunately that does not bring in paramount reduction at the cost and effort required for transformation projects as hoped.
This illusion stems from the fact that we tend to imagine the whole model having a gigantic core and a thin peripheral layer around it. However, in practice, most of the cases, the opposite holds true, i.e. the volume of the periphery surrounding the core gets too large inevitably. Even-though some fundamental algorithms and business rules tend to remain unchanged across many trend cycles or transformations, UX is always subject to change, perhaps, must change over periods. The UX is not only comprised of UI but also the “application logic” that represents the stories, flows and scenarios that users experience. Consequently these components become larger than the core business logic itself for many enterprise systems. In other words, the size and complexity of the periphery is not largely “accidental” as it is supposed to be, but rather “essential”. For instance, various client agents(web, mobile, kiosk etc.) or 3rd party integrations dictate various presentation and flow logics for the same core model. Moreover, that periphery is more prone to technological changes and advances compared to the core business model.
I compare this situation with the neighborhood barbers changing the decoration of the shop periodically. Neither the core model of barbers’ business show much variation, nor the change in hair and beard cutting fashion require changing the decoration of the shop and even changing the scissors or knives at hand. But they do think that they have to change the decoration occasionally even if it is not directly related to the core business with the concern of keeping the user experience and satisfaction at the highest level despite being very costly for them.
Another point I would like to raise here is the interesting dichotomy between human civilization and digital transformation:
Traditional history of human civilization comes out in the form of urbanization, permanent settlement, building large and flashy buildings, infrastructures and superstructures that will survive for many years, taking root in one place -the word civilization comes from civitas i.e. city-. On the other hand cloud native transformation evokes the nomadic culture: It doesn’t matter where a piece of software works. It should be able to work here and there today or tomorrow. Be able to work on-premise private cloud today, on the public cloud X tomorrow and on the Y cloud the next day.
Systems should be like small tents or caravans that can easily be lifted and transported to a different place, as if it were a nomad camping site, rather than a gigantic high-rise buildings with enormous furnishings and decorations inside. In other words, instead of making huge systems interconnected with each other and with the infrastructure they work on through intricate and inseparable connections, we should build systems that are not dependent on any specific infrastructure, but consist of small components that contain the essential infrastructure they need and are ready to change and migrate at any time. That’s exactly what container-based microservices architecture is all about.
Being always ready for change can be made possible just by minimizing the risk of change. That can only be achieved by maximizing the level of automation at all levels:
· Keeping the whole system in an easily packable and replayable form, back and forth as required, by adopting “Infrastructure as Code” approach at the infrastructure and provisioning level,
· Building and maintaining a comprehensive regression test suite to be able to make changes and trials without fear at the application level.
In summary, rather than long-term horizontal courses intermitted by leaps at very high staircases, we should address digital transformation in the form of ascending a slight slope at a mild pace, and engraft this understanding into the corporate culture.
