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…
Demystifying the role “Software Architect”
Introduction
The following series of articles are based on my personal experiences gained in the past year working as a “Senior Software Architect” at a super-cool telecom company.
The scene
Two words: Satellite. Broadband.
…and one more: Combined.
On the one hand you’ve got the space industry with it’s “sky-high” level of entry on it’s own. On the other hand you’ve got the already complex “down-to-earth” reality of the internet service providers.
But it’s real: you can use a communication satellite to offer broadband internet services to areas where other means of connectivity is not feasible. Being the “software architect” in this realm is full of challenges but it’s great fun.
The role
In my job title I’ve got this word “senior” which always makes me smile: I take it means that I’ve reached too high too young.
So what do I do?
In the next couple of articles I’m going to cover all aspects of my day-to-day job simply to give you an idea of what skills and experiences are required by this role.
…you know, just in case you want to end up in a similar role one day…
