Thinking about Software Architecture & Design : Part 3

In software architecture and design we have some pretty deep theories that guide us on our way. We know how to watch out for exponential run times, undetectable synchronisation deadlocks, lost update avoidance etc. We have Petri nets, state charts, entity/attribute diagrams, polymorphic object models, statistical queuing models, QA/QC confidence intervals....the list goes on....

...and yet, in my experience, the success of a software architecture & design project tends, in my experience, to revolve around an aspect of the problem domain that is not addressed by any of the above. I call it the experiential delta.

Simply put, the experiential delta is a measure of how different the “to be” system appears to be, to those who will interact with it – experience it – day to day.

A system can have a very high architecture delta but a low experiential delta and be many orders of magnitude easier to get into production than a system with low architecture delta but a high experiential delta. 

It pays to know what type of experiential delta your “to be” solution represents. If it has high experiential delta, it pays to put that issue front and center in your planning. Such projects tend to be primarily process change challenges with some IT attached, as opposed to being IT projects with some process change attached.

In my experience, many large IT projects that fail, do not fail for IT reasons per se. They fail for process change reasons, but get labeled as IT failures after the fact. The real source of failure in some cases, is a failure to realize the importance of process change and the need to get process change experts into the room fast. As soon the the size of the experiential delta crystallizes.

Indeed in some situations it is best to lead the project as a process change project, not an IT project at all. Doing so has a wonderful way of focusing attention on the true determinant of success. The petri nets will look after themselves.