A particular idea I really liked to write a post about a while ago is to summarize errors that IT architects (including myself) make from time to time. The underlying motivation was based on the hunch that there’s a finite and quite limited list of actual root causes, and by having the causes listed and reflected would help me and anyone else avoid this kind of mistakes in the future. As a result I’ve started to put together a let of ‘capital sins’ of an engineer.
And this is where problems started. As we all know there supposed to be seven deadly sins, but despite my efforts I could only come up with six at most, and even then I wasn’t actually convinced about whether the last two were independent or just special cases of earlier ones.
So, I decided to take a step back and put everything into as few broad categories as possible in order to make any subsequent refinement and adjustments easier. This post is about the first category, first and foremost cardinal sin of an IT architect: Ignoring the People.
Legal-ish definition of the sin, which could be used at the Engineering Last Judgement, sounds like the following: neglecting, by omission or admission, the fact that at all stages of its lifecycle a system is interacting with people in various roles, including but not limited to sponsors, developers, and users.
There are multiple manifestations of this kind of neglecting. The effects may look different depending on the role a particular group of people plays with regard to the system, so I’m going to give few examples for each group to give an idea.
The first and the most notorious instance of neglecting people happens with users. You can tell if an architect has neglected his users very easily, i.e. system is not being used or users hate it when they forced to. This surely means that the architect have never ever spoken to any end user, or never understood what has been said, which is the same thing. Funny enough, if the architect cared about the users, they quite often merely think that the system is ‘okay’, nothing more than that, one shouldn’t expect to see users adoring or enjoying working with a system in enterprise IT context. Well, we, architects, have other means of job satisfaction.
Next role suffering from being neglected are developers. Oh, how often is it when an architect sketches a couple of obscure UML diagrams (or even PowerPoint slides!) and throws it over the fence. Aside from being bad for relationships, there’s a practical consequence. Fatal architecture flaws surfacing during the development phase is much easier to address compared to later stages such as when system becomes operational. Lots of projects implode because of developers are not being fully engaged and introduced to a bigger picture, so they can’t (or even don’t want to) see a problem early and it’s too late to change something.
There are more obscure but equally dangerous cases of groups of people ignored by an architect.
- Ignoring the sponsor who pays for the system. Cheque-writing senior executives need to be shown the value, otherwise they lose interest and refuse to discuss change requests and subsequent tranches.
- Ignoring the project or programme manager. These folks are supposed to look after resources, dependencies and risks. If they are not aware of the risks and trade-offs made by an architect, they can’t do their job properly.
- Ignoring the manager of end users who have to authorize any end user involvement in your project, which could be perceived as a distraction from his perspective.
- Ignoring internal and external governance bodies, who put together all sorts of policies that a solution has to comply with, e.g. security, technologies, processes, etc. Failure to comply could damage one’s appraisal (best case) or cost his company a fortune (worst case).
- Ignoring the IT operations. Hard working DBAs and system administrators have their own favourite ways of looking after applications and systems and an architect have to take it into account. If neglected, be sure to expect delays and downtime.
- Ignoring fellow architects, who may be doing something interfering with your plans in the long run.
- Ignoring the vendor who supplies major component of the system. Unless you’re using only commodity packages such as JVM, which is tried and tested by thousands, having a third-party component is a risk. This one is similar to neglecting developers, i.e. if vendor doesn’t know precisely what you’re doing, you might miss an opportunity to get an early warning.
Any sort of enterprise software solution is a risk. However, in my view, any architect who fails to take those people into account and build healthy relationship is endangering the project he is working on far beyond necessity.