= = = = = INTRODUCTION = = = = =

Most of the companies I came across, either directly or indirectly, are all rushing to kick off ambitious programmes to realize a ‘digital transformation’.

What digital transformation means for each of these companies and the executives tasked to bring it about, is often blurred and buried within a number of other concepts like Agile, Pizza Team, Cross Functional Teams, Digital CX, Data Analytics, Start-ups Mentality, Failing Fast, etc. etc.

It is striking that all these concepts so intimately associated to digital transformation are in fact related to means. That is: approaches or ways to implement something.

It is the latter, the ‘something’ or the ‘what’, that is strangely referenced the least in these types of conversations. To such a point that one feels shy of openly and repeatedly asking the very starting and fundamental question: what is it the set of functionalities that makes up your vision for your company digital transformation? And, related to this first question: what is it the new digital engaging scenario that you are aiming at achieving for your customers?

Both questions are relevant and foundational as I will explain later in more details.

For now, I will simply say that digital transformation has two faces: one external towards customers, prospects and business partners, i.e. the set of functionalities we want to implement now.

The second is internal and refers to the ability of one organization to innovate fast to implement new future functionalities, not yet known. Hence digital transformation indeed also means reshaping the processes, operating modes and capabilities of organizations (i.e. the means) to allow them to respond fast to market changes.

However, a clear vision with the right level of details about ‘the what’ is still required to drive the process in a meaningful way.

One of the key difficulties in answering this question (i.e. ‘the what’) lies in the fact that without intimately knowing the possibilities that technology can bring, it is very difficult to imagine what could be the set of ‘digital functionalities’ and their underlining supporting business processes that would translate the usual 30 thousand feet PowerPoint vision into something concrete and executable.

I personally never bought into the idea that an architect can deal with a digital architecture whilst it is up to the business to define ‘the what’.

I have witnessed a few instances of similar situations: all appeared to share the main common feature of a lot of ‘running around’ with little concrete progress.

= = = = = WHAT DOES IT MEAN DEFINING ‘THE WHAT’ (FOR THE KNOWN) = = = = =

So in order to enable a digital transformation the first step is to imagine the ‘what’ or more precisely the first wave of the ‘what’, which means building a robust and detailed conceptual model that describes the new ways in which customers can interact with your company and also the type of information that get generated, validated, modified and consumed during these interaction events.

That is surely a business responsibility but it is also something the business and a senior architect need to do hands in hands.

Actually, in my mind, it should rather be the architect the one who is expected to articulate a coherent and detailed whole from the often scattered intuitions matched with some isolated example scenarios that business people often provide.

These latter should be considered precious starting points that give the overall sense of direction for the quest of details.

It is important to realize that a conceptual model is not a simple collection of shallow user stories ; it is rather the set of abstract concepts and their relationships that can make sense of all details (i.e. all requirements) that can surface from the user stories themselves.

Iterative processes, like Agile, do not guarantee on their own a successful outcome in term of the ability to build a powerful conceptual model able to provide enough precision and coherency to allow a reliable technical development.

Producing a conceptual model is an intellectual endeavour that often goes beyond technologies. It starts from examining a deluge of information coming from the minds of domain experts (i.e. business people), from users and technical people of existing legacy systems, from business models deployed by competitors, from existing IT systems capabilities, from relevant architecture patterns and tactics, and many more.

The trick is not to get lost in the details but also not to ignore them. It lies rather in the ability to aggregate them up into one organizing idea after another up to the definition of a coherent set of concepts from which all requirements can be derived like corollaries of a deeper theory.

Obviously are the business people those who ultimately make the final selection amongst the various types of ‘theories’ that can potentially be built. But are the architect those who are better equipped to build such theories.

One extra challenge that a digital transformation often poses is the sheer size of the business domain object the analysis. Indeed a digital transformation often involves the whole company operations and not just subparts of it.

However, big bang approaches that rely on the virtue of Agile, typically either fail or produce very little (and late) compared to the level of upfront investments that have required.

In a later section of this article I will propose an approach that has proved effective in my experience.

= = = = = WHAT DOES IT MEAN DEFINING THE ‘WHAT’ (FOR THE UNKNOWN) = = = = =

So far so good for the ‘known’.

However, one key characteristic of digital transformation, perhaps one of its most defining traits, lies in its prescribed aim to build a new set of capabilities (both technical and organizational) that will allow the company to innovate fast and reliably into directions not yet fully known.

Ultimately Digital has been brought about by the convergence of a number of new powerful technologies that have opened up the possibility of embracing radically new business models, yet to be explored in their fullness.

Hence, digital is intimately linked with the race it brought about towards innovation.

A key business consequence is the importance to avoid being left behind, since the latter might have dire consequences for the viability of the companies affected.

Typically when a company wants to implement new business processes it would still require new IT capabilities to support them. So the ability to innovate fast boils down to the ability of the IT function to make available such new capabilities fast and reliably via successfully executed transformation programmes.

Something that historically has been a real challenge up to now.

This time the challenge is even more acute due to the fact that the new innovative digital business models typically exhibit a much higher degree of pervasiveness, a distinctive lack of business boundaries, a much higher degree of automation and, most importantly, a much higher degree of relevance towards customers.

That in turns implies a much higher and smarter level of integration and therefore the need to overcome the old silos based IT capability approach where data is produced and consumed separately within applications each dealing with a specific and usually narrow business domain.

Also innovation requires the ability of rapidly acquiring and deploying the best of niche innovative applications in a seamlessly plug and play mode whilst maintaining a highly coherent and integrated data fabric at enterprise level.

In short it is like having to architect and then realize a whole ecosystem of modules that can easily be reassembled together (or integrated with new ones) to generate new set of functionalities with minimum pain and maximum reliability.

That is in essence the ‘what’ for the unknown: It consists in correctly identifying the business semantic of these building blocks and also the mechanisms by which they can interoperate with each other, whilst maintaining maximum flexibility.

All that on top of the many technical constraints that a legacy IT landscape obviously poses.

= = = = = SOME COMMON PITFALLS = = = = =

There is no magic recipe to achieve that. There are, however, a number of interesting new ideas that have augmented and enriched the old set of traditional approaches, despite the fact that, often, they are overhyped and portrayed like panaceas.

Needless to say, if such new ideas are applied thoughtlessly the results are far from being encouraging.

Here, I would point out some of the most common mistakes.

• The first is to try to tackle the whole company business domain at once. It is true that a Digital Transformation has a company-wide scope, however trying to do everything at once is not a good idea.

• The second is to try to do it via deploying a large number of Agile Cross Functional Teams each focused at a usually narrow application domain, in the assumption that the sum of the parts will automatically yield a coherent whole.

• The third is to forget about the technical interdependencies and to assume, even if it is not true, that each team can really operate independently from each other. Typically, in such situations, there will be a lot of technical escalations that will end up unattended in a no-man’s land.

• The fourth is to rush to do something for the sake of it, i.e. “fail fast”. The latter is a powerful concept that though shouldn’t be abused by justifying senseless and unplausible activities.

The virtue remains in not failing at all if possible, though failure should also be considered part of the game.

• The fifth is to solely focus on the UI whilst underestimating the importance of coherently articulating the underlying broader business model that is required to both support and to contextualize the user journeys. That often brings about a never ending prototyping, moreover quite removed from any required concreteness.

• The sixth, and the last one I would mention here, is the lack of any company-wide reliable mechanism to properly monitor progresses against expectations and level of investments. This is, after all, one the foundational tenets for Agile projects and it is definitely very useful to fine tune the company-wide adopted approach should it be necessary.

I have seen many more naiveties, but the common theme appears to lie in the false belief that a Digital Transformation can somehow be achieved by adopting some of these new ‘digital’ approaches (e.g. the likes of Agile or CX or Cloud) and that, this alone, is sufficient to realize something big and coherent as a digital transformation.

Unfortunately, as I have illustrated earlier, a Digital Transformation is much deeper than that.

= = = = = HOW TO EXECUTE = = = = =

So, how to successfully execute a digital transformation?

Here I won’t claim to have the magic stick, however I would like to briefly share some elements of an approach I have successfully applied in the past.

As mentioned earlier, an unavoidable starting point is defining the first wave of the ‘what’ (i.e. the ‘what for the known’). However, at the same time, some hypothesis about the set of capabilities required to deal with the ‘what for the unknown’ are still required to be identified upfront.

Needless to say, it would be unfeasible trying to analyse the AS-IS at an enterprise level in search of the best TO-BE technical solution when the overall direction is yet to be identified.

In such a circular situation, what is really required is a promising way to partition complexity. And the concept of an API layer nicely fits the bill. It allows to put aside, at least initially, the mighty intricacies of the legacy technical constraints and to focus on identifying the ‘what’ with the required level of details and comprehensiveness to enable a subsequent reliable implementation.

Indeed an API, if properly identified , is in effect a modular unit of functionality and together they partition the digital domain space into smaller elementary units: a sort of alphabet that can potentially express the whole space of requirements (both known and also unknown to an extent) with endless possibilities.

However as I have said, a digital transformation typically spans across the whole company and it would be a mistake trying to tackle the whole company business domain all at once.

So here is a good way to solve the problem.

1. Identifying a manageable number of domains, possibly within a different set of representative regions , to provide a complex enough – but still manageable - set of requirements. The complexity needs be representative of the whole space complexity, a bit like a statistical sample. It follows that some care in identifying the initial domains is key.

2. Model each domain (in an iterative way and just enough!) driven by the ‘scattered’ requirements available and start identifying the server side calls and their canonical data model towards their respective UIs or clients. This should be still at logical level.

3. Iteratively analyse the relevant pieces of AS-IS architecture especially in terms of existing legacy data interfaces and their semantics. Some upfront due diligence about technical feasibility is always recommendable.

4. Iterate across the domains to make sure the set of APIs in the process of being identified have a robust enough business semantic, no overlapping or inconsistencies, the optimal level of granularity, and together provide a powerful aggregated canonical data model towards the external world.

5. Keep iterating, top-down, bottom-up and across the domains until the right trade-off is likely to have been correctly identified and the APIs definition reaches the precision required for its subsequent implementation.

As mentioned earlier, that ecosystem of APIs should be able to act as basic building blocks for the first wave of the ‘what’ but also it should become a good fabric to enable innovation (may be with some extra APIs added later).

There are other benefits worth noticing of such an approach.

It reduces the complexity and therefore the risks of modelling the business domain, by allowing a two steps analysis. Initially, the focus can only be on the business domain constituent building blocks (i.e. APIs).

Other details, not immediately relevant, can be overlooked and tackled at a later stage possibly by different teams.

It also reduces complexity by decoupling the requirements from the architecture since the APIs layer can well be used as the single relevant point of contact between the two and architects can well start their technical analysis moving from the API definition.

Having said all that, I would also add that the only good way I know to comprehensively tackle for the unknown (i.e. the ‘what for the unknown’) lies in a robust and modular architecture (both at enterprise and point solution level) which needs be articulated beneath the API layer.

This is a big theme on its own right. It involves new governance concepts and new organizational mechanisms required to foster the development of a good architecture practice and of course the related indispensable ‘check points’.

Regular checks, to assess if the produced architectures are weak because, for instance, they are ambiguous and what it takes to make them accurate are essential.

This is something no organization I saw ever does in a convincing way!

Incredibly, no organization is seriously trying to establish shared and effective criteria to assess the correctness of their architectures and, most of the time, architecture remains a PowerPoint exercise.

A very important topic that, to be properly articulated, would require another article on its own right.

= = = = = CONCLUSION = = = = =

In this article I have tried to clarify what digital transformation means and I have offered a point of view that hopefully helps in shaping digital transformation programmes more effectively and reliably.

= = = = = REFERENCES = = = = =

Evans E. Domain-Driven Design. Addison Wesley 2004

Leffingwell D. Scaling Software Agility. Addison Wesley 2007

Taylor N. R; Medvidovic N; Dashofy M. E; Software Architecture – Foundations, Theory, and Practice. Wiley 2010