Some ideas on how not to be an “ivory tower architect”.

In my line of work as a Solutions Architect there are some patterns that I hate to see and bring a bad name to what we do. Below I hope to call some of these out so at the very least we can start a discussion. I have put these in the order they annoy me.

  1. Do not specify implementation.
  2. Write code.
  3. Always be available during implementation.
  4. Own and fix your failures.

Let’s deal with the first in the list “Do not specify implementation.” Now as with any rule this can be broken. If you have a very junior team on their first project or you truly have no choice due to reasons then yes you may have to specify implementation but these are very rare cases and most of the time they are early signs your project is going to fail.

Dictation is the enemy of empowerment. If you have a team with mixed experience they will look to you to validate their ideas and provide the benefit of your experience. A mixed team will likely overall know more than you in any given domain simply because there are more them than you so the best thing you can do is exploit this. Discuss with your team both early and often the bigger picture. If you are working with a typical scrum team this will likely be your epics. They need this information as much as you do to help shape their decisions on details so don’t try and hide it from them.

Specifying implementation is likely going to alienate your team and they will get bored quickly of being your puppet. The good people will leave and it will get harder to deliver on the commitments you have made when presenting your grand vision to your client.

One exception I do make to this is common patterns. When you are one team of many in a larger unit following common patterns can make life easier for everyone but these should not be a straitjacket. Any team should be allow to do tech spikes and show the value of their new approach to everyone else and if everyone agrees that can become the new pattern for everyone else to adopt.

“Write code” was one of my most recent lessons and on this one I had a great example recently from the ever awesome Peter Campbell on how this should be done. Our CTO was recently running SQL queries on RDS instances helping us debug performance problems and we all respect him more for it.

If you don’t write code, if you don’t get down and dirty with your team once in a while not only will your skills and experience become irrelevant but your team you should be leading to victory will lose faith in you. They will see you as this crufty old dinosaur that has been promoted above your abilities and the value you provide will slowly fade. If you are doing this job you likely have been at this for a while so I hope you loved doing what got you where you are today. This being the case why would not want to go and play in the sand pit with the other kids.

“Be available during implementation” is a trap I have fell into a few times recently. I am of course a very busy person but I should never be too busy to help the people who are helping make the crazy ideas I have had a reality. You are there not just to draw the boxes on the white board but also to answer the questions when someone hits a fork in the road.

Finally “Own and fix your own failures”. I think this is a general rule in life for me but it applies even more so when it is your job to provide guidance to others. No one can expect you to be perfect, even when you have a gray beard and have recreated the whole world countless times. We all make mistakes but the most dangerous mistake you can make is ignoring a bad decision and continuing with a bad implementation. It is always hard to explain to a client/user/customer that a large body of work has to be thrown away and started again but if this is the right thing to do it is your duty to explain the value of doing so. If you keep forcing your team to use a solution neither you nor them like no one will win. There is never a good reason to throw good money after bad and as painful as it can be sometimes cutting your losses is a good idea. A good recent example of this was a monolith API delivered in PHP by a team who mostly understood Java and other languages. While I believe any good coder can likely do a good job in any language this was the wrong thing delivered by the wrong people. Despite this the team in question delivered a working system that is currently in service but thankfully this was recognised and is being rewritten with Java microservices.

I would like to close with a personal example of the above fails from a project I worked on a while ago. One of the people working on the project wanted to dump the monitoring solution I had suggested we use and replace this with Sensu. I was nervous about this and I had some real concerns about how we could fit this into the security constraints of the platform. While I would like to think I did not just ignore the person that suggested this they most likely felt like I did and their chance to implement something good was ruined. It is not the reason they left, we did lose this person a little while later to a far more fabulous job than they had with us. Learning from this fail on the next project someone came to suggest we use Promethus. On the face of it at the time this appeared anything but production ready and we had a tight deadline to hit but having had my previous fail I suggested the best thing to do was a time boxed tech spike to show the value of this. Turned out to be one of the most useful things we delivered as part of the work we were doing providing both technical and business value early and often.

It is easy to write from the ivory tower too, to talk about how to create architectures so clean you can eat your dinner off them. It is not always as easy to write about how the experience was gained. I hope the above can make showing others the path a little easier.

Thanks for listening.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.