Being a Software Architect 101 – Part 1

I learned how to be a software architect (and consultant) from my two great mentors Ed Staffin and Steve Smith.  They taught me so many things.  However, I have also learned a few things along the way.

Before I get started, let me define the term “software architect”.  The job of a software architect is to identify what technologies should be used in a project and how they should be used.  A software architect should, on some level know about system administration, database administration, programming and security, but mostly programming.  A software architect should make models, demonstrating his designs and proving integration theories.

Those things are very 101 for being a software architect, (not implying that they are easy) but there are several pitfalls, that I have seen other people with a software architect role or title, fall into.

  • If you don’t know what you are doing, you better collaborate with someone who does.  Although wisdom will only help you with 2% of a project, that 2% might be the difference between a dream project and a nightmare.
  • If someone claims to know more than you, on a topic, listen to some of their ideas.  You might learn something.  To be a good SW architect, you better check your ego at the door and be ready to learn from anybody who has different experiences from you (ie, everybody).  Even mainframers and kids have gathered some wisdom.  They might just save your hide.  Then again, they might not.
  • You can’t know everything.  Develop a network of reliable people who know more than you (on certain topics) and defer to them when necessary.  Don’t act like you know everything about everything.  People know you are lying.  Also, know-it-alls are really annoying.  You will have much better credibility if you can refer to an ACTUAL expert instead of insisting you are the expert on everything (just because the people around you don’t happen to know any more than you do).
  • Models are not programs.  Software architects are more valuable making models that show other programmers how things work.  Writing CRUD code is a colossal waste of a software architect’s time.  So is making nice-looking graphics or web pages.
  • Teach others.  If you know how something works, so what.  Yippee, we have one person who knows how things work.  If you are any good, you should pass your knowledge on to anyone/everyone on your team.  Then they can be the masters of that easy old technology and you can free your mind for something more cutting edge and valuable (and difficult).
  • Size your solution for the project.  Rational Rose is not needed for making notepad.exe.  Neither is 110 pages of documentation or a two-week testing cycle.  Likewise, a 20 page spec is a little light for a 2000 person-hour project.
  • Try to stick to solutions that are mainstream.  About 90% of all enterprise development is being done in Java or dotnet, connected to DB2, Oracle or SQL Server.  “Boo” might be a fun language to mess around with, but if you deliver a solution to a customer, written in Boo, you have screwed your customer because they will never find someone to maintain it.  Their only choices are 1) stick with you or 2) rewrite it.
  • KISS principal should be your #1 priority.  Brian Kernighan (one of the fathers of OO) once said, “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”  Amen brother!  I can’t tell you the number of projects that I have seen where the customer had to pay top dollar to bring in a genius to fix some crazy code.  I have also refactored and rewritten several projects, just so ordinary human programmers could maintain them.  Its really crazy and irresponsible on the part of the original authors.
  • Don’t let untrained people talk you into bad designs.  The CEO may dictate that you need to use ColdFusion 5 and Oracle 7 connected via home-made SOA (XML web services), because that is the SW and skill-set that they have in-house.  However, if they brought you in because they can’t get work done in ColdFusion 5 and Oracle 7. You may need to work on your communication skills (speaking, persuasion, etc) this week instead of your technology skills.  Don’t abdicate your responsibility to get them into a technology that meets their needs moving forward.  Seriously, you are better off walking away from that project instead of agreeing to a horrible hack.

About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in Architecture, Professionalism. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s