For most of my software development career I cared about how software was organized, how I had to work with it; how I had change it.  I never had any formal training or courses on being an architect and, until recently, it seemed like such courses were few and far between.

Over the last few years I learned a lot about being a software architect through trials by fire.  When I left the Library world and transitioned into the Justice world I had to step up my game quite a bit.  During that time I learned what it took to build systems that had to work round-the-clock.  I learned what it took to make disparate systems talk to each other to perform work and remain autonomous.  I even tried my best to do things the way I was learning.  But often times I was learning more than I could apply and at the pace work was coming at me I couldn’t rewrite systems just to apply new things I learned.

The first thing I learned was that you can’t do it alone.  I knew that there was a better way to do things and I couldn’t settle for the status quo.  I also didn’t agree with all my coworkers, so I went outside for help.  Getting outside perspective was huge and hooked me into people who share industry best practices.  Blending that knowledge with inside perspective helped me see where best practices fit into the environment.

The next thing I learned is that people probably won’t like you.  Something about architects being perceived as telling people how to code leaves architects out of popularity contests.  Personality also works against you too.  Learning to control the personality traits that work against you (unwillingness to be flexible, “my way, no highway option”) and helping people discover best practices in the way they need to learn will help.  Both of those take time to do and you can’t reach those goals all at once.  The architects who learned this lesson are some of the best and I am fortunate to know a few of those architects.

You have to be willing to constantly question yourself. Software architects have to make a lot of assumptions.  Part of the key to success is to get good at making good assumptions.  Another part is to know when to question yourself and when to be OK with something.  These two attitudes can work for you and against you.  You’ll know when something is as right as its going to be.

Software architecture is personal and you have to be open to exposing how you think to others.  This is hard.  Especially when someone who you think is not capable of objectively reviewing a solution reviews one and gives you negative feedback.  Dealing with that requires more interpersonal skills than anything.  Be prepared to make mistakes and see lesson #2.

The final lesson I learned is that you will never be done learning and it takes small leaps to make big ones.  I was introduced to OO patterns by a Java programmer.  I was clueless.  As I studied those patterns and the concepts taught, I struggled to apply them in an OO world.  But in the SOA world things started to make sense.  Encapsulation.  Abstraction. Loose-coupling.  Suddenly concepts and patterns made sense at the OO level.  For me to learn I had to see the problems in context.  My context was SOA and the bigger picture.  When it all clicked, that “a-ha” moment helped me make leaps that I never imagined possible.

For a few years now I have considered myself an architect though I have never had that title from an employer.  A good friend and mentor told me that the way I worked and what I did made me an architect.  He had that title once, so I felt ok taking that advice from him.

The truth is, every developer is a little bit of an architect.  Some of us just care a little more than the next guy.