My role

Fri, 10 Aug 2007 19:31:00 GMT

Another week over and another two projects done and dusted. The first project started *and* finished this week. It was a two day technical consulting engagement where I helped out a support team fix some low level technical issues and assessed the suitability of a physical architecture of an FX trading system. The second, for another capital markets organisation, was the completion of a risk management system that we've been working on for the past couple of months. I've been working as the technical architect on a 3-days a week basis, where I've been doing everything including architecture, development, testing and support.

Although completely different, both projects have been fun in different ways and this is the thing that I really like about consulting. It does sound cliched, but I do like the variety of work. And that raises an interesting question that I *always* seem to get asked.

What exactly do you do?

I tend to introduce myself as a "technical architect" although, more often than not, I do clarify this by saying that I'm a "hands-on software architect" or an "architect with a technology focus". People ask me, particularly when I'm interviewing them, "what would be a typical role for you?". I actually don't have a "typical" role, but I do have a small set of typical *roles* that include the following.

"Hands-on" software/application/technical/system architecture, where I get involved in :

Requirements capture and architecture definition.
Delivery of the architecture, proving the non-functional requirements.
Design, development and testing.
Quality assurance.

Coaching/mentoring/training of aspiring software architects.
Technology consulting.
Technology troubleshooting.
Architecture consulting.
Architecture reviews.
Project audits and health checks.
Technical due diligence on projects and organisations (e.g. for venture capital companies, process improvement, consolidation, etc).

My biggest roles are certainly the hands-on software architecture roles, and I find that the other stuff fits in quite well in the spare time between projects or during those projects when I'm working in a part-time capacity. I also find that the experiences picked up from the shorter roles help when I'm doing the hands-on architecture work, and vice-versa. A good example came this week - seeing a support team in action has made my rethink the way that I architect new systems, making them more supportable and support team friendly.

So what do I do? Mainly software architecture, but then there's a whole bunch of other stuff that's also technical in nature. "Coding the Architecture" sums up my role well. ;-)

Simon Brown - consulting tag

My role