Demystifying the role “Software Architect” – part 2: infrastructure, hardware and software tools
“…if the hardware is the brain and sinew of our products the software in them is their soul…”
(Steve Jobs, June 6, 2011 WWDC keynote, 02:26)
This article is about the brains and the souls, the tools of the trade.
For a medium sized company (100 – 200 employee) it is safe to assume that besides the personal computers and laptops there is some sort of internal virtualized infrastructure as well.
As a software architect you’re probably less interested in the actual hardware parameters (number of CPU cores, amount of RAM, etc.) what’s really important though is the level of virtualization.
Study at least the most popular virtualization tools like Xen or VMware.
Design and build your development environment: DEV > STAGING > QA > INTEGRATION > LIVE
Automate where possible: use continuouos integration (Hudson / Jenkins) to script and automate the most time consuming processes: build, test, report, package, deploy regularly.
Use scripting to test your applications (Selenium).
On your development PC / laptop keep your main OS clean but use local virtualization (VirtualBox) to maintain several versions of the DEV / STAGING environment.
Did I mention to master Unix / Linux on the way?
Check what OS is running on the production servers, clone the configuration and bring it “down” to your STAGING and DEV environments.
Even better if you automate those steps as well, with Puppet for example.
Once you’ve nailed the build – test – report – package – deploy process and you keep those processes alive you can have some rest.
Chose an IDE and try to make it the standard within the company.
If you’re building web apps install several browsers and use the user profile features (e.g. in Firefox) to manage multiple user sessions at once: log in as “admin” in one window and as a normal user in another.
Learn to use at least one diagramming tool well (yEd, Inkscape, ArgoUML), your manager / boss / sales and marketing people will love you for that.
Use a tool to manage your backlog (XPlanner, Redmine).
Set up an internal knowledge base – wiki style.
Maintain a secure password database – ideally use a tool that allows you to build a hierarchical structure or at least use tagging for the entries.
At the moment in my company password database (KeePassX) I have 200+ unique entries.
Back up your PC / laptop regularly.
…and most importantly: version control your code base. Keep a central location (Subversion) – or use a distributed tool (Git). Or use both at the same time. It’s great fun! 
Unless you’re working at a startup – or working on a greenfield project you’re most likely to meet your greatest enemy:
Old hardware can be replaced, software tools require extra care and planning if they need an update.
Not to mention your own code and legacy systems that you need to maintain.
There is no silver bullet in this area just hard work and better planning next time…
