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.

2 Responses to The Orangutan Architect

  1. I’m an IT sloth, I’ll hang with you in the tree and tell you about the glory days of DOS or Linux. And maybe even Unix on an old T-map II mainframe. But the world of IT keeps on moving to fast for me. So i’m creeping my way over to accounting. For as we all know. Math never changes. =)

  2. interal standards also help.

    most orgs these days are coding to j2ee specs for an soa architecture while clinging like lamprys to itil/mof guidelines…

    the last is the most important in terms of end user experience. both mof/itil demand a change management process that requires documentation before release:

    1) business flow doc for software
    2) architecture doc for software
    3) install doc for software
    4) end user guide for software
    6) debugging doc for software
    7) network logical diagram of software, to include port ingress/egress, FWs traversed, F5/L4/5 Load balancing across multiple stacks/sites
    8) Backup strategy

    …and the above’s at a minimum.

    the worst place for an agressive Orangutan Architect to work is in a small shop where there is not an Architecture Office that overseas the devlopment of a company’s series of products. In small shops the Orangutan Architect is, indeed, the red ass monkey among the small poo flingers and an inordinate amount of the company’s future hinges on the Orangutan’s ego not flying out of control….

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Go to top