This is from a blog post I wrote in around August 2005. At the time it got linked to a lot, read and laughed at in various degrees and even got reprinted in an industry magazine (but with vital professional edits such as my name being removed, I imagine to save billing complexity). In one of my ‘clear outs’ of online writings around 2008 I trashed the blog, but then late last week someone emailed me the text of the post they had kept. If for nothing else, it provides an odd glimpse back to my early Benjamin Button like computing career where I started at a 400,000 person company wearing a suit and worked my way back to being just me sat here in my Fez and fishing waders. As much as it pains me, and it’s deperately unfashionable skinny jeans terms, I’ve left it unedited – it’s still too long, but there it is.

An Overly Long Guide to Being A Software Architect

It is probably wise to start off with what I mean by the term ‘a software architect’. Well the answer is unfortunately quite oblique. It really is up to you. You may work on your own, you may work in a team the size of the Ben Hur extras but you may still be an ‘architect’.

The best I can do is say that it’s all to do with the breadth of responsibility you have for the solution.

Another more evasive but satisfying way (well, for me anyway, who has to type all this rubbish in) to answer would be for you to take a look down the list below and see if most of the items means something to you and your job. If they do, then chances are you may call yourself a ‘software architect’ if you so desired. Alternatively you could also call yourself ‘Supreme Commander of the Lesser Dominion of Greater Officetania’ if you like too; I’m happy either way.

Here are my top 11 bits of advice for aspiring and/or perspiring architects: (warning, this is a little long, so I’d grab a drink/snack and comfortable shoes now):

1. Politics. I put this first not because it’s the most important (there is hope still left in this world) but because it is the least discussed tangible thing that can make a difference. Nearly every book I have read on the role of the software architect tends to punt this thorny subject gently to one side. The general advice tends to be ‘The Esteemed Author doesn’t have this problem so recommends you getting another job, or something’. How nice for them.

Politics is a dirty word and brings images of an unshaven Nixon or of 22 year old MBA graduates in suits that are too big for them – but it doesn’t have to be quite like that. In most cases you need to sell ideas on their merit as well as your reputation. I have seen a great deal of genuinely magnificent ideas flail on the rocks due to misspent karma between peers. The corporate world is largely a playgrounds and the players much like children. People attach various weightings to people’s opinion based on their previous encounters as well as the opinions of you of their peers. If nothing else do try to realize that your actions with people have consequence. Relationships need to be nurtured. This doesn’t mean you go around inanely grinning at everyone like Tony Blair, but don’t ignore the fact that people need attention and listening too to – however impo®tant you may have become.

It was once remarked to me ‘Why do software architects listen so carefully to developers? It’s because they are watching their lips – that way they know when it is time to immediately start talking’. The best corporate politicians I have worked with have known when to shut up and listen and absorb.

Corporate politics is tricky, unscientific and dull but unfortunately it comes with the territory. What you need to do is face up to it, think about how you want to portray yourself, try to stay consistent and try not to take it all too seriously. Rather than going to buy that latest ‘C# SOA Gingham Patterns Revealed!’ book, take a walk on the distasteful side and go and read an old Dale Carnegie manual. That way you could have the brains plus the charisma and the good looks – and two out of three ain’t bad.

The software architect’s role is about 49% technical at best. Talk, listen, smooch, follow-through. Carnegie. Communicate. If you think that you are above politics, then you are wrong.

2. Perspective and Views. If I had to pick one tip to give on being a software architect I would say it was to remember the responsibility to take a series of views and a wider perspective on the system design – everything else is gravy. The nature of any complex system is to take a complex problem and functionally decompose it into modules and aspects. (Don’t get hung up on these particular terms, I just mean that there is a ‘zoom’ feature on a system design and that the architect is meant to be at a higher and wider viewpoint.) These modules and aspects are then strung together to make a system. So the architect’s job, and one that does get overlooked from time to time, is to go through the system design from many different perspectives and check that everything is still as good as you think it will be from different viewpoints. Remember that everyone else is busy beavering away on their various ‘next level up or down’ so you had better keep your head above the gopher hole.

The obvious perspective usually took is the functional path of how the system operates. Use cases are nearly always like this, which is why most people struggle when they start with the ‘UC1: User logs in’, as it required a series of non-functional decisions to be made up front. These non-functional requirements and constraints are usually the reasons most systems don’t perform well as they are harder to ‘mentally model’ from different perspectives.

I have seen very talented developers who have lost perspective or been in denial of a certain failing aspect of a system. These perspectives are never usually ‘forgotten’, as in ‘Oh dear, we forgot to add a secure admin interface’ but talked down in subtle group conspiracy of ‘not being that important’ at some stage of development. One curious thing is that this weighting of aspects is still more of a skill than a trade. Software architects can sometimes be like old army generals at a war college, in that they keep trying to fight the last war even if the battlefield has changed.

The rather tired but still relevant analogy is how an airline pilot does things different from a software architect. The two pilots sit at the front and ticks off a series of mundane sounding items (Flaps 10% – Check, APU standby – Check, Nice Hat at Rakish Angle – Check etc) even though they do this every single day of their lives, while an architect would happily do all this from memory even though they do it every 2 years. The difference isn’t in the brain power of the pilot vs the architect, it’s in the relevance importance of forgetting something. A slow web page hasn’t ever killed 200 people, just annoyed them.

So for me the trick with systematically checking your views is to adopt some sort of team methodology that suits your level of comfort. Maybe take a look at the Zachman framework, take a look at the old P. Krutchen 4+1 concepts pre-fatso-RUP or maybe just make up a checklist of all the perspectives on the system. Data Security, Bandwidth, Response time, Data growth, Integration are not the sort of things you can put on a design spec and ask someone to singularly ‘make sure they code it well please’, you need to go an purposely go mull them over up-front.

I know a lot of popular blogs that recommend an artisan craftsmen style of ‘if I wrote it down you wouldn’t understand it’, magic-circle style approach, but that doesn’t mean you can’t have a deliberate exercise of checking all your viewpoints and widening your perspectives to see if the system will work or not. Just because you are a Scrum Coach Lead Brownie doesn’t mean you can’t have some simple models and checklists.

Put another way, the primary role of the software architect is to be at fault when the system sucks at what it does.

3. Specialize or Don’t – But Do Decide. The classic bear trap for most software architects is to convince themselves that they can do everything well, or even ‘the best’. The approach of the architect is often to think of their job like an Olympic Decathlon event. All they need to do is run around monitoring everyone and offering tips to the sprinters, javelin throwers and pole vaulters on what to do. The flaw with this way is that a specialist can nearly always beat them in their respective events – and the generalist needs to remember and respect that. The problem is usually the architect came from a background where they were considered one of the best in a certain area, normally design/coding.

For what it is worth, I am a firm believer of trying to know enough about an area to have a representative appreciation of it, but of not trying to rule all the roosts. I have learnt to live with my limitations.

Team leaders can be good software architects, but you don’t always have to be the Glorious Leader to be the software architect. Great developers can be good software architects, but you don’t always have to be checking all the code. Put simply, this tip is to try and appreciate that your role may now mean you will have amentallossy-style algorithm for remembering the other team member’s particular skills or expert areas. If you consider yourself the team’s best Coder/Tester/Network Engineer/DBA/UI designer/Manager, then as a software architect you won’t be much fun to work with.

4. Patterns, Logic and Algorithms. People not in IT sometimes get the impression that this industry is radically overhauling itself with exciting new concepts and languages at a half-life of around every 2 minutes. While it is true that terms and technology keep the trade press busy, a lot of what we basically do more or less stays the same. Most designs can be expressed as a series of patterns implemented through a narrow set of algorithms. Once you get the basics ingrained then you can spot the similarities and speed up your learning-by-example process.

I came into IT from a maths and comp.sci background and felt that a basic understanding of stats, number theory and logic has, despite my grave and commercial misgivings at the time, actually been quite useful. I tend to side with those that think that introduction into systems is probably best from a non-vocational aspect, i.e. who cares what particular syntax and language you learnt as long as you got to experience a few of them.

So this tip is that the next time you get ‘syntax anxiety’ in that you can’t remember how to do something from memory in code XYZ, try to step back and find the essence of what is the same from what you already know. Rather than trying to be a complete C# generics expert next week, take a look at Eiffel or even Ada and look how they achieve polymorphic data-type signatures. Rather than review large pages of code or spaghetti models, try to step back and recognize what the base algorithm is doing. This exercising of your focus muscles is a useful skill for gaining perspectives as an architect too.

As an example, take a good look at how a proficient developer debugs a difficult problem, it is usually the same process and logic apply each time – regardless of the situation. If you learn this ‘abstract essence’ approach then the ongoing technology and language changes can get enjoyable rather than onerous.

As an aside I want to comment (yeah, because that’s exactly what this article needs is more words…) on two misconceptions I have regularly seen on the use of patterns in software architecture. Ok, here we go: (1) You not only have to identify them but you need to actually do what they say – I know this sounds trite but just because you can recite their name doesn’t mean you are helping. The code is the deliverable, the pattern was just there anyway. (2) patterns are a form of ‘language’ and if you sit there alone in your Grand PooBah office and talk to yourself about them then they lose an awful lot of their goodness. A shortened way of expressing something is only really useful if everyone actually knows what they mean – it is an oxymoron to be the team’s ‘pattern expert’.

5. New Technology Fetishes. I absolutely love technology, it’s a weakness, but it isn’t actually what an architect does. The dark side of technology is that you can tend to lose focus on what your original business problem was. A brand new set of shiny technology techniques tend to lead to zombified software architects wandering around the IT landscape looking to pin their new found toy onto a project that doesn’t move away fast enough – ‘BRAINS BRAINS XML XML’. We seem to all have an unbelievable faith in extracting out just the potential positives with something we aren’t that familiar with. It is remarkable how goldfish memory like our retention ability is of however bad the previous version was. I see this as akin to childbirth memories in women, if anyone remembered how truly bad it really was then we as a race would only ever have one child, i.e. game over humans. The body has endomorphines, software architects have MSDN Magazine?

The tip here is to make sure you contain yourself and your enthusiasm when presented with an unfamiliar technology. Pilot it, research it, go slow if you can – but don’t just go and rush to 3rd base with itjust because your friend said they did.

6. Build vs Buy. In today’s cornucopia of frameworks and platform features one of the most difficult architectural decision is on whether to build or buy major parts of your system architecture. On one hand it is quite liberating to have all the difficult decisions taken away from you and that you can’t go and tar-pit yourself into a Don Quixote chase of rewriting your own mini relational database. The other side of the coin is that nearly always by making an ‘embedding’ decision you are actually changing the systems requirements in a way that might not be obvious at the time. If you don’t have the mandate to make that sort of compromise then the inflexibility of a buy decision can be painful. You can get a lot out of buying components or frameworks but you must quickly shift into the attitude of knowing where the sweet spots are – in other words, ‘Stay On The Path’. There comes a time where you stretch the original metaphor so far with what you bought that you just need to hold you hands up and say ‘enough’. It seems to be a harder decision to drop a bought subsystem or framework that it is to first adopt one.

Very few teams are just reams of pure virgin code anymore – they now start from a level of having to understand a set of libraries or application model. As a software architecture your familiarity of the constraints and the ‘normal path’ is very important in this respect.

My general advice for build vs buy as part of a software architecture is to make sure you know what you are getting into and that you probably has an obligation to try not to invent anything. The painful contradiction here is often that clever architects want to innovate and that for the vast majority of business cases they probably shouldn’t be – at least not in the area of choosing what to build themselves or buy.

7. Resources, Money and Economics. The amount of money to spend on a project is the ultimate non-functional requirement but rarely gets explicitly discussed with architects. Practically every decision you need to make can be traced back to how much or how long. As the software architect, whether you like it or not, you will have a constraint of what you can do with that money, even if you don’t have direct budget control. One unobvious and often unstated goal of a software architect is to give excellent value for the money to your employer.

Money also has a large bearing on what Build vs Buy decisions you need to make. It is a strange thing now I think about it, but I have seen many more over-architected systems than ‘under-architected’ ones, as in they just lacked features but worked very well. The norm seems to be that they over-extend what they need to do. In economical terms this is a curious situation, in that like a child with a new crayon set we seem destined to try to used every single colour regardless of the picture. Some architects seem to naturally fight the constraints of budget and run-time license costs, as if they weren’t part of what they do. Well they are and you can chose to have a voice or just complain. A lot of methodologies would do well to stress plain old stuff like return-on-investment rather than the more exciting.

In terms of advice for aspiring software architects in terms of handling resources is to make sure that they fully understand the economics of what they are trying to succeed at – it may be an incredibly dull subject but you might just implement a successful system for the people paying for it and be allowed to do another one.

8. Requirements and The Domain. It is no accident that the most common business domain that software developer feel they could start up their own company in is in the area of software development tools. The ideal thing about a source-code trees or bug tracking products is that you can reality-check everyday that your product is sweet without having to interpret with someone that doesn’t understand software development. (Of course the irony of this is that you then try to sell to a market that ultimately doesn’t really value your tools as they rather foolishly think they could do an ad-hoc themselves or just make do. Cobblers and their children’s shoe is the pertinent saying, I imagine. The other outcome of the dev market is you just end up with a set of small but really smart customers, and that can present it’s own set of commercial problems way beyond the remit of this ditty.)

For the rest of us that don’t actually day-to-day need to use the systems we develop then need to form some sort of relationship with people that do. I don’t have a table of stats to show you but I personally have a deep feeling that software projects fail in two main ways:

(a). The system doesn’t work that well.

(b). The system works well but doesn’t do what you need it to do.

By and large it’s mainly always (b) in that it missed the need of what is actually useful. But it seems that we as an industry seem to concentrate our collective brain power on solving (a) much more though. The Agile approaches seems to at least attempt swing the game back into admitting that we can’t really go that long before doing the wrong thing, but in my limited experience, it often seems to just accept that this developer-domain gap exists as an unavoidable ‘tax’ to be amortatized over a short set of more rapid releases.

You can go either way with trying to understand the domain problems as a software architecture. You can choose to fully surround yourself with them in an attempt to understand them more, or you can trying to step right back and just call them ‘Widgets’. The danger with not getting involved with the business requirements is that it is tragically easy just to hear what you think are justifications for the architecture you have in mind. This problem is also compounding with the fact that if it takes 6 months to gather the requirements then they are probably not going to be correct in six months time. Requirements are a 4-dimensional problem.

The first part of my tip for the software architecture in terms of the requirements is to at least spend as much time listening to the users as you do your implementation team. Also try to actively look for aspects of the system you know are difficult to implement and go around with active questioning on those early on. If you passively ask a user what they want then consider that they might not actually know, but they will still say something.

Setting expectations with the users is a double-edge sword in that a lot us of can’t down-play the system to such an extent that it gets cancelled versus the more likely reality of placing some limits on what can be achieved. Good software architects can actually say ‘No.’ though, it just takes some finesse.

The second part of my tip is try to resist extensibility because of open-ended requirements. This is very hard and it is so tempting to add points throughout the system design where you try to foolishly anticipate growth. If you talk to a user and give them the following options:

• Please tell me what fields you need on the Insurance form

vs

• Do you need user defined fields on the Insurance form?

I mean, what would you say? What is the least work and safest thing for them to answer with? You may already have in you mind that this glorious architectural adventure of a system will need variable data-structures, so you can quickly get to into a mutual deadly embrace of you both wanted to do more than is strictly wise or necessary. Of course it then goes bad for both of you, but the User can safely just say that the requirements have evolved.

9. Trust and Communication. Trust is the key to not going insane in any sort of team. As a collective sliver of an industry it is my observation that software architects are rarely good at delegating or handing off. There is nothing more pitiful to behold than a single person being mentally Slashdotted was a ‘knowledge bottleneck’. You can tell the signs of a person thrashing to disk with their brains and it’s not fun to watch for anyone concerned.

The software architect is not the Central CPU of the Tron movie or even that ‘Ergo’ bloke from the Matrix. You don’t have to be some walking giant brain that knows all the answers. The primary job is not to know all the answers but to know someone that does. If you can’t clearly and plainly communicate what you mean then you aren’t much good to people.

As a software architect if the core of your team can’t all decently describe the intended architecture through the stages of development then, in many ways, you have failed in your job. The tip here is to remember that the team, however large or small, is what makes the software and that conception and orchestration are important roles that have a limit like any other in the team. Practice explaining what you are intending to do to people above, below and sideways from your position. I have never heard of a software architect that failed for talking or trusting too much.

10. Learning. Like this article, It Just Never Ends. Some people have the impression of a software architect as being some higher level pinnacle of a developer’s career ladder, in that once they get there then things will be easier somehow. Well, here’s the good news and bad news – the pace of learning never lets up. The only way to cope with this is to try and get into the mindset of continually learning and enjoying the feeling of not knowing something.

After a while it gets quite Zen-like and you start to recognize the cycles of the older ideas being given new names. If this bothers you then just have to try to relax – it terms of emotional involvement with what you do for a living there are few jobs as enjoyable as being a software architect.

11. Advice. Finally my last tip is to never take advice from Top 11 tip lists. In nearly all cases there was only about 3 good points and with about 8 padding. Here’s a proof: The movie Pearl Harbour was 240 mins long and had the same amount in duration of edutainment as this article; it also cost ~$200 millions dollars to make. The comparative maths would then be p = 240/200 * 0 < 3/0 * 1. Actually I don’t know what this equation proves, but I really didn’t like that movie.