Aspiring Architects (AA: Arch-i-holics Anonymous?)

Are you an aspiring architect?  Perhaps you’re not strong enough to admit it?  Aspiring Architect – is that like the AA?  “Hi my name is Adrian and it’s been 3 days since I architected my last solution.”

I’ve been formally known as a solution architect now for about ten months, I’m starting to settle into a groove and look to be more pro-active in doing what I do and doing it better.  I’ve also just had my first proper performance review – which was positive (hooray) – so I’m starting to feel like I’m a position to tell you how the transition has gone and what to expect if you’re an aspiring architect.  (I’m going to do this as bit of a series as things of interest pop-up.)

Modelling complex business systems in duplo can be difficult, yet both fulfilling and useful.

Working at a higher level

By far, the most significant change that you need to prepare yourself for is that you’ll be working at a higher level – specifically, you won’t be doing any coding (I’m assuming you’re like me and are coming to architecture from a development background).

Nothing in my current role actually demands that I do any coding, and it’s quite possible that I could get by without doing any coding; but I want to make it very clear that this doesn’t mean I recommend not doing any coding. 

Small side note here; the majority of my opinion on this has been formed from my current position, and implicit in that is that everything is tainted with the specifics of that position: the culture of the organisation, the people I work with and their personalities, and so on.

The problem has different facets to it, and many influencers, but one of the main ones for me was the fact that I’m involved in multiple projects (to varying degrees) and you just can’t get down into a serious level of detail on all of them, as you just don’t have the time.

Initially it didn’t seem like a huge issue – I was still doing some recreational coding at home, and the projects I was working didn’t require me do get down and dirty at the coding coal face; but as time went by I started to feel a bit uncomfortable – I guess it was partly because (having come from a development background) I was used to dealing with code and not having it around me in the same way was simply new and different. 

Another thing which occurred was that I became more involved in projects using technology I’m not super familiar with; in addition, you get constantly overwhelmed with new offerings (The Cloud, HTML 5, etc) and you realise you’re out of touch (or in danger of getting too out of touch) – everything you know is theory or abstract, and there is something about physical presence that is so very reassuring.

The final important point is that the need for grounding is not always constant, one minute I’ll be cursing that I don’t know what’s going on and have no independent way of finding out, the next I’ll be dealing with things so far from the coal face it’s just not an issue.

So while my strong advice for all the aspiring architects out there (and this probably applies to existing architects too) is that you’ll end up working at a higher level and you’ll want to be prepared for it, I’m not 100% sure this means you need a development environment.  Common sense and general wisdom tends to indicate that it’s a good idea, but like anything it will be one of many tools and its use needs to be appropriate.

Case in point - we have a lot of Java based systems here; does that mean I need a Java development environment?  Due to mergers and restructuring we have large tracts of both Java and MS stacks, but I tend to be involved mostly in the MS side of things.  I don’t have anything going on or coming up that’s Java based, so as there’s no burning need it doesn’t seem worthwhile to spend all the time and effort on something which (at the moment) has a low probability of returning “value for money”.

5 Tips:

1. First Principles. Simply things.  Boil things down to what matters, don’t get confused by clutter / noise etc; I often find that bring things back to first principles is a great way of dealing with things, particularly new things (which you’ll face a lot of).  If you’re familiar with first principles, and can apply these to things that appear new and different they won’t be quite so new and different and you’ll be able to deal with them much more effectively.
2. Be aware of different views.  Cutting code isn’t the only way to stay grounded – look out for other opportunities like regular catch-ups with people from other teams to get their perspectives (i.e. your System Admin / DBA friends, etc), you’ll also be working with higher level architects (for me it’s the Data and Technical Architects) – they have really useful info too. 
3. Divide and conquer.  I can’t speak for women but I know men can’t multitask, so assuming you’re not multi-threaded focus on doing one thing (at a time where possible) and doing it well.  Be prepared to juggle lots of things at once.  Put yourself in the mental state that knows it’s ok to have loose-ends lying around – on the basis that you have a strategy or system in place to deal with them when the times comes.
4. Be ruthless.  You can’t be all things to all people – so in terms of keeping up with technology as well as your workplace I suggest you keep a wide a view as you can manage – but keep it shallow in depth; don’t go in deep unless you need to and not deeper than you need to.
5. Coal Face.  Consider if you need to have access to a development environment of some kind.  Ideally this will be at work where you can hook-up dummy services to that new ESB or dummy web sites that use that new security layer, etc.  If you can’t get one at work, consider one at home.

Although architecture isn’t rocket science it has its own set of traps.  As long as you keep your eyes open, apply some common sense and have a game plan you’ll be fine – and not end-up in Arch-i-holics Anonymous.