Skip to main content

Archetypal architect?

Pondering software architecture yesterday and I thought I'd write a little piece about it - (a) because I have started a new job in 2013 as a software architect and (b) because I want to make a blog post before the end of February! 

[edit: 2012-03-02] Caveat emptor - although I've tried to make it an interesting and beneficial read - this is undoubtedly an introspective post, perhaps bordering on egotistical...I was at my last job 6.5 years and I guess this bit of writing is a function of the metamorphosis that I'm going through, in adjusting to being with a new company and in a new job after so long...

Unlike the conventional “construction” type of architect, a software architect almost certainly will not walk into an architecture – or even architect trainee – job straight after they have finished their studies (assuming they have studied computer science/engineering, etc).

Here’s a picture of a Saab – according to Top Gear, all construction type architects own one of these:

A software architect will typically have moved (from programming) toward software architecture as they have gained life and work experiences, over a number of years. For some, the pull toward architecture is inevitable – and whether one holds a title that has the word “architecture” in it or not, they may be practicing software architecture. The traits that are developed by work/life experiences which – IMO – are key to being successful as a software architects are:

  • A strong desire/drive to work with - and resolve - complex problems.
  • Relatively deep experience in dealing with complex problems.

These traits I think may not necessarily (initially at least) be associated with experiences in the software industry (or in any “profession” at all), in order for someone to have the makings of an effective software architect. They could be developed for example, as a result of dealing with traumatic experience(s).

These traits are also intimately connected; in order to have gained experience in dealing with complex problems, we must have a strong desire to solve complex problems. Otherwise, if we are faced with complex problems and we don’t deal with them, they’re just an impediment that we live with (and/or ignore and/or let someone take responsibility for) – am I right?

So, I was thinking, if there were a 1-dimensional "software architect type continuum", with these two traits at the extremes – where would I sit on that continuum? I reckon roughly here:

I may not be a technical top gun (although I reckon I can hold my own), but I think I do have a fair bit of experience in dealing with complex problems, in a variety of contexts. And also – I've made a few mistakes along the way (and recovered successfully from...well, most!). I think that, in order to have developed a fair measure of both of these traits, one must have made at least a few relatively serious mistakes – in life and at work - after all, practical experience and making (and hopefully recovering from) real mistakes I think is the only way to really learn; everything else is theory. Finally, if there were such a continuum, I think we'd drift along it - sometimes we are more technically up-to-date and driven, other times we are "wiser" and more guided by experience. Things - and people - change, sometimes quickly!

This way of thinking could probably be applied to a range of different professions. I suppose the real purpose of my writing this is that I have been thinking fairly deeply about why I changed jobs and how I ended up in software architecture - this is one of my conclusions. Perhaps it will help someone else, perhaps not...

In Patternsof Enterprise Application Architecture (recommended reading for anyone who is in software development/design-esque line-of-work) Martin Fowler describes software architecture as being - The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system's lifetime; and, in the end, architecture boils down to whatever the important stuff is.”

I think this fits – in order to have the confidence to deal with architectural decisions and problems, you need a degree of desire/drive to be involved with this type of stuff, and also the experience to be able to make informed/effective decisions – or at least, to get yourself (and the system) out of the schtuk if you make the wrong decision.


Popular posts from this blog

HOW-TO: Apply a “baseless merge” in Team Foundation Server 2010 (and 2012)

Another purely technical post on TFS...
The scenario We wish to migrate code between branches that do not have a branch/merge relationship, in order to expedite urgent changes being made by a project team, without disrupting on-going BAU development work. Sample branch hierachy/strategy Imagine the following branching strategy in TFS (visible by connecting to TFS via Visual Studio 2010 or 2012):

Essentially you have a "DEV" branch, which has a "QA" branch, which in turn has a "PROD" branch. DEV is the branch that you would be using for BAU development. As a piece of development matures, you move it into QA, where it is tested by your internal QA team. There may be further changes made in DEV that are moved into the QA branch as the QA team pick up issues. Once the QA team are happy with a packaged of changes, they will move them into PROD, which is essentially the hand-over to the customer. The PROD branch represents the software that the customer has.


HOW-TO: Add/edit a field in Team Foundation Server 2012 using Visual Studio 2012

It's been a while since I made a purely technical post...

So, today I wanted to make a change to a Microsoft Team Foundation Server 2012 (TFS2012) instance that I am working with to reflect "Actual" time spent on a task - mainly for reporting purposes, and because I have found in the past that making this minor process adjustment yields a relatively useful metric over the long-term.

I am using the Microsoft Scrum 2.1 Process Template ( for a project that I am working with. So that I don't forget how to do this (again!) I will blog-post the procedure I've used to add this field to the template as a screen-shot-based tutorial, as follows...
Before Assuming you are familiar with the Scrum Process Template (2.1-ish) - open a task and take a look at the "Details" section, as follows:

 This is where I want my "Actual" field to show up.
Get the Power Tools Download and install the latest v…

Eclipse/Android error: "Multiple dex files define [...]"

Wow, I am really going nuts blogging this-evening - 2nd post in less than an hour. 

Anyway this is a particularly nasty error that I keep running into with Eclipse/Android when starting the emulator after I have not run it for a little while. Since I run the risk of permanently forgetting the solution to the problem every time I walk away from my Android project (and thus having to spend a painful hour-or-so digging up the procedure again), I will blog it here, for my benefit, and for the benefit of anyone who may also suffer the same problem.

The gist is that when you start the emulator in debug mode (that is, you hit the button in the following image), you get the following error message come out on the console and a nasty popup telling you nothing more than there is an error with your program and you need to fix it:

[2012-04-06 23:20:57 - Dex Loader] Unable to execute dex: Multiple dex files define Lcom/google/gson/ExclusionStrategy;
[2012-04-06 23:20:57 - SimpleList] Conversion to Dal…