The Orangutan Architect
One of my most successful articles was the IT Animal Kingdom piece I wrote a couple of years ago. It was picked up by both BlogCritics and Internet Duct Tape. I wrote the article based on many of my past experiences in the IT world and even though I made fun of the Orangutan Architect, I am starting to understand him that character a little more.
In that article I defined this animal as the ones that…
create the most complex systems for simple solutions. If you have ever had a conversation with someone that talks in circles, never getting to a point, you might have encountered an Orangutan. Like their conversational skills their code is extremely hard to follow and it resembles a bowl of spaghetti. Somehow they are also backed by the predators, I believe because of their uncanny capability to confuse.
If you had to study its DNA, it would have come from two of the great software architects I have worked with in the past. The tone of the article only captured the funny and satirical side of what an architect is, however it did not talk about their brilliance when it came to being able to see systems as a fully integrated machine where they were aware of the skeleton and many other pieces inside of it. Now that I have 10+ years of experience in the world of IT I find myself becoming more and more like they were.
When talking about software development there are many schools of thinking. Some of them are almost like religions and you can encounter people that blindly follow a methodology even it if leads them into dead ends. One of the most dangerous is how configurable and flexible a software has to be. Most architects that I have met love making something so generic that we can use it for any widget. I still think this is the wrong approach for most solutionas and adhere myself to the mentality that it has to solve the problem first and then become generic, not build something generic that also solves the problem. Neither approach is wrong all together; finding the happy medium is what good designers ultimately have to do. It also varies greatly between internal IT shops and people that write software to be packaged. The closer the IT shop is to supporting the software and have ownership of it, the less generic you the software tends to be.
Now we get to the part where I am becoming more like the orangutan, and it has some to do with time management. Every architect I have met does not have time to explain details to others and they want to be trusted fully by everyone in the team. I personally lean more towards the business analysis side where I want to be close to the problem that is at hand and providing the right solution. Some of it can be attributed to the many small environments that I have worked inside where I saw my user all the time. That made me a better analyst, but it also tends to make me more reactive. The right thing to do is to compromise between talking and doing, and I have slowly come to realize that if you talk too much, meet too much, plan too much, you end up not doing a lot.
Navigating the sea of users trying to please them as well as the decision makers is quite a task. I have learned from the architects that being good at it is not just about being able to describe the big picture, but at the same time understand all the details that make it up. That skill develops being involved in various projects and being able to see things coming that others never expect. It is great to know methodologies and know how structures get built on top of solid frameworks, but the architect should plan for the pitfalls that others don’t see. It is not a perfect science, but it is something good architects do well.
After writing the article two years ago I thought about what it really meant. In some ways I was trying to see what traits I did not want fall pray of as my career started to get to the next level. Business Analysis and Software Architecture are both things that I have been doing for some years now, but it is recently that I feel confident that I can play in both of those realms with some authority. The key to all of it is not only experience, but realizing that you truly need a full zoo to really run a successful IT shop.