Thinking about Software Architecture & Design : Part 4

Any new IT system will necessarily sit inside a larger context. If that context includes the new system having its own identity – from “the new system” to “Project Unity” - it will be anthropomorphised by its users. This can be good, bad or neutral for the success of the new IT system.

It does not matter what form the naming takes e.g. “Project Horizon”, “Bob's System”, “The new HR system” or even a visual identity such as "the new button", or even a tactile identity such as “the new panel under the desk at reception”. In all cases the new IT system may be treated by existing team members in much the same way as a new team member would be treated.

New systems get “sized up”, so to speak, by their users. Attributes such as “fast”, “unreliable”, “inflexible” or even “moody” might be applied to the new system. These may be factually based, or biased, depending on the stance the community of users adopts towards the new system arriving into their team.

One particularly troublesome possibility is that the new system may be seen as causal factor in events unrelated to it. “X used to work fine before the new system came along....” The opposite can also happen i.e. the new system get plaudits for events it had no hand or part in. Causality versus correlation can be a tricky distinction to navigate.

Takeaway: sometimes the human tendency towards the anthropomorphic can be used to your advantage. If you suspect the opposite may be true for your new system, it can be useful to purposely avoid elaborate naming and dramatic rollout events which can exacerbate anthropomorphisation.

Sometimes, new systems are best rolled out with little or no fanfare in a “business as usual” mode. Sometimes it is not possible to avoid big bang system switchover events but if it is at all possible to adopt a phased approach to deployment, and transition slowly, I would recommend it for many reasons, one of which is the sort of team dynamics alluded to here.

As AI/Robotics advances, I think this will become even more important in the years ahead.

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.