As I’ve noted a few times on my blog I seek the simple architectural answer when designing solutions. I try to avoid overly complicated designs and solutions in the end. It is part of what I have dubbed the Simple Architecture movement.
That said there is a place for complexity in the universe beyond Rube Goldberg devices. But the complexity of the view doesn’t always mean the solution that drove the view was complex.
For example, I was reviewing some old pictures and realized there are some very complex and intricate systems created by nature. The process of creation is simple, erosion or freezing but the result is complex.
Beyond that IT solutions that start complex and then well in the end if they start complex they run into two problems.
- Hit by the bus
- Cannot easily patch or manage
Hit by the bus is the bane of IT projects. It means that one person is a driver or so integral to the overall project that if they aren’t there the project will have issues or fail. We hear people say the phrase all the time but in the end Hit by the Bus is not part of the simple architecture movement. It is in fact a form of complexity.
The other side of complexity is the reality of patching and managing the environment. The harder it is to patch an environment the more over time you run into the complexity issues of solution drift and security risk. Solution drift is the Delta between the baseline (what we believed is deployed) and reality (what is actually deployed). The more complex the patching process the greater in the end the risk created.
Why is it then that sometimes software and solution architects seek complexity? Over documenting or under documenting a solution to the point of creating the hit by a bus issue? Job security.
I started the simple architecture movement with a posting nearly ten years ago (Difference Architectures) on MSDN. The reason for the original post was an internal argument about the size of architecture documents given to the customer and complexity. I broke up the various deliverables I thought ought to be included with an architecture. I struggled to convince my team members that they didn’t need to include every single mouse click in the overall architecture document – that was best included in configuration and operations guides.
Over time the customer started to agree with me which was the only thing that changed the teams mind. The risk of producing a smaller less “Thud-able” architecture and therefore jeopardize their careers was too much for them. There is a negative perception of self-promotion that I personally think is stupid. The only reason I think its stupid has to do with the fact that there are people that don’t do self-promotion but in the end don’t do anything that will jeopardize their careers. They belittle people that self-promote but then in the end they are risk free since whenever their career started.
Effectively my career protection is a pattern that isn’t communications but is actually personal style. So what you end up with is people so motivated to protect their careers that in the end they are paralyzed.
They create massive Thud Factor architectures not because it is the right thing to do for the customer but rather it is the right thing for them to do for their careers. They stand in front of you decrying the foul nature of self-promotion but in the end they seldom venture outside the safety of career protection zone.
Oh well. If you ring fence cow manure its still manure.