Some time ago, when Corona virus pandemic hit the world and travels outside one’s home were totally banned, time flew quite differently.

I personally spent most of my days sitting in my home studio from where I used to work. In front of my desk lied some of my bookshelves that I stared at, from time to time, during my idle moments.

The vast majority of books in those bookshelves were related to IT and they spanned a vast array of topics, some still very current but some almost forgotten by now, though they were at the top of the curve a few years back. And indeed they had some merit!

_- - - - IT shared body of knowledge - - -

So it is natural to start reflecting about the shared body of knowledge in the IT field. Any mature engineering or science discipline has it.

New items are constantly added to the body of knowledge once proved valuable and therefore accepted as true by consensus.

Typically there is a well-defined and robust process for proving something as true that guarantees a good level of objectiveness and take away vested interests and personality issues. So the body of knowledge keeps growing coherently and new topics are constantly added and harmonized.

It gets refined too.

Old truths don’t stay the same over the decades or centuries as they had been articulated and understood at the beginning. They can get qualified as pertaining to a specific and narrower context. Also they can get reinterpreted by reshaping the underlying concepts in such a way to make them more usable, less cumbersome and more coherent with the remaining body of knowledge.

That means achieving a deeper understanding or developing a different and more general point of view about old truths.

So the technical language and its underlying concepts might get repurposed but old truths are rarely completely forgotten as they had become irrelevant. And of course they get into the curricula and students are required to learn them during their training years.

--- IT productivity depends on its body of knowledge ---

That doesn’t seem to be the case of IT. And I do not believe these are futile academic questions.

On the contrary, this is an extremely important topic that has massive business implication since it translates into how making the IT discipline more effective and efficient on the whole.

That is: how to improve productivity of IT personnel and departments.

It also leads to the important question of what is the really useful skill set its practitioners should possess and how to measure the achieved level of proficiency.

--- IT productivity should be one of the top CIOs concern ---

So all that is something CxO and senior IT leaders should ponder about extensively, given they have the power to select (or can strongly influence) their company specific IT body of knowledge.

As I said in the title, once upon time there was an approach called Domain Driven Design . . .

This book’s blue-ish coloured spine has a vivacious graphics and it lied still, right in front of me. I still remember the vivid impression I received by looking at it from my desk.

It was authored by Eric Evans. I read it many years before and I read it more than once.

Personally, I found that this book was articulating the merits of an approach that lies right at the hearth of the IT problem.

The notorious high level of failures, delays, budget overruns affecting too many IT programmes. Also it was doing so with remarkable clarity focusing at identifying the mental processes that need to take place in people heads. A topic skipped altogether by most recipes IT books.

It was revolving around very key topics, the likes of “how to build a rigorously organized and selective abstraction of domain knowledge”. It was arguing that it is not so much about methodologies, but rather the need of “correctly abstracting the principles behind requirements to arrive at a point where powerful new features unfold as corollaries to older features”.

--- Domain Driven Design and Digital Transformation ---

Domain Driven Design is an attempt to provide guidance about how to build robust, flexible and easy to maintain solutions. In other terms, solutions that can be quickly repurposed to support new disruptive business models, something key to the success of digital transformations that all companies are scrambling to achieve.

Nowadays digital transformation is one of the most popular catch phrases. Around it an intense competitions amongst IT service suppliers has unfolded. Such competition is played around the self-asserted know-how about how to help companies to successfully achieve it.

So developing or possessing a proven method is of prime importance and business impact.

But this book seems to have been forgotten, ousted by a new breed of recommendations and approaches that totally ignore its focus on the mental processes.

Were these recommendations truly effective? Or simply too few people properly learned how to apply these concepts and therefore the Domain Driven Design method did not produce business-level tangible results and faded away? Like a few others approaches in the recent past.

If Evans’ insights were wrong or irrelevant it is right to forget about it, as about any other ‘theory’ that has proved not correct. It is a matter of software engineering history for those who are interested in it.

However simply forgetting about it because the marketing noise has simply moved on it is to me a quite immature business practice, given the fact the problems this book tried to address are still very much with us.