Musings

Perspective of a Solutions architect

In my daily work there is little room over for what you might call a singular attitude towards a certain technical solution or another. There are gradients of what can be considered good and bad of course. But agnosticism is more or less a requirement when the whole is to be considered.

This post will discuss a bit about how I think about legacy. Let us call it a self-reflection on how to recognise when you are stuck in the bad path of assuming that you are any different.

Setting the premisis

For those whom do not know me I “solve problems”, specifically IT problems. This might be assisting a customer to migrate a application to a new better platform. Or helping them make reality a idea of continuous (or nearly continuous) deployment of code.

The bubble

The first mistake is that one always assumes that there is such a thing as a clean slate. Be it a new project to create a platform built on the latest technology. Or migrating an entire company over to newer infrastructure.

It is always a good idea to walk into a project with firm belief that the principals of Security, Usability and Function can be followed but never actually fully attained.

Because even in a clean slate situation there will be concessions made to facilitate the functions required by external entities. Or in simpler terms you have to make things work for everyone outside of the vacuum of the perfect situation.

Learning from mistakes

From the vantage point of today, yesterday seems to have been managed by a small group of drunk monkeys regardless of what one might be looking at. So how does one navigate days, weeks or years of legacy in a an effort to make improvements? First what usually occurs is the same as the last time, history repeated itself. Not learning by the mistakes of the predecessors.

Another mistake is to think that due to the fact that this is now and that was then would shield you from bouncing up against the same issues as earlier. There is usually a somewhat good reason for the state of things regardless of circumstances that they were created under.

Principals are good too

Usually during a project you put the bar high, which is not a mistake. Assuming that nothing can knock it down is. My methodology might be seen as fluent (or even irresponsible) but solving issues is not only on a technical plane, there is business, humans and usability plane to consider to.

The learning phase

First of all having a birds eye view of a situation is always good, meeting talking and discussing is always a good way of getting the hang of the current situation. Talking about what the expectations are and how to achieve them will not only make sure that you at least make everyone heard but also that you have the scope of the project.

The next step is usually to take all that has been said and create the framework of what is to come. Be it via visualisation or meetings with the interested parties.

The understanding phase

As we continuously discuss the different aspects of the scope and how to achieve the expectations of the project we also start to understand the intricacies of the platform(s) and/or product(s). As we go along the understanding also should bare the issues inherent to any and all platform(s) and/or product(s).

The compromising phase

When enough has been understood to begin the work, bare in mind that the above phases are repeating over time.

“No plan survives first contact with the enemy”

So the perfect road has been laid down. So the question is why someone just pulled up alongside in a old-clunker ready for the scrap-yard. It is the legacy-mobile, and yes now is where the principals will both be tested and bent. But never broken.

Understanding why this happens; because there is such a thing as reality and this is almost always the case. This is the part where a rigidity will not serve well. But the all important principals are never to be broken since they are what will be questioned and measured after the fact. Still the problem has to be solved, usually by bending one of the principals a bit.

Conclusion

During my time working with IT solution’s I have learned to be the straw of grass in the wind rather then the stone. Flexible up to a point, in the end this is what create the greatest value for most people. But it is also what the next person thinks was done by a drunk monkey…