So how many times have you been in the situation where, having heard an outline of the system a customer needs, you find yourself animatedly sketching out architecture on a whiteboard while the requirement documentation sits unopened on the desk behind you? All goes well until someone who is a bit more detail oriented and has gone through the document in excruciating detail, starts asking awkward questions.
Please tell me I’m not the only one!
Does this make us bad architects? No, I don’t think so. In fact I think it’s a symptom of the ability to ‘think big’ which is a fundamental skill in architecting large systems. Our brains are wired in this peculiar way that, when presented with a problem, we immediately visualise the end game and then start breaking it down into components and more detailed processes until the boredom of dealing with the minutiae sets in and we try, hopefully successfully, to hand the detail over to someone else.
The only problem with this is that, for the best of reasons, sometimes our brains shoot off in the wrong direction and if we’re not able to be a bit self-aware about it, we can get ourselves into a really sticky situation. At best you then have the problem of trying to squeeze a bunch of awkward requirements into a set of components that aren’t ever going to be a very comfortable fit. At worst you end up responsible for the business spending a shed load of money on a system that can’t work. Not a nice place to be!
So, in the hope that this isn’t just me, I started thinking about some of the factors that might lead us to go launching into a system design without paying enough attention to the system requirements. I think this can be internally or externally motivated.
From an internal perspective, as system architects, we have a deep interest in emerging technology and as a result, are constantly looking to see what new and exciting stuff is out there. This can include new products and services, new thinking on system design patterns and new processes and ways of working. Given that these things naturally excite us (or we wouldn’t be in the job right?) it’s hardly a surprise that we want to try some of them out ourselves and start to look for reasons to do it.
Now it may well be that the latest whizz bang idea does fit the bill nicely or it may be that the entire concept of the project is born from a new technology (although this is far more likely to be the case where a project is engineering led innovation) but the question to ask yourself here is this. Did the people who put these requirements together have this in mind when they they wrote them down? Chances are they didn’t and by presenting them with something new and different, you could be scaring them off.
Another factor that can come into play is where we look at a new system at a very high level, compare it to a system we were previously involved with and start to make assumptions about the second, based on our understanding of the first. This is something that less technical management can be especially prone to and it can make your life hell. Quite often these similarities are only skin deep and fundamental differences are exposed once you break through the surface of the requirements documentation.
External pressures to push a specific set of components can often come from the business. This can be frustrating when you see that the components being pushed are not necessarily the best ones for the job. This can appear as management meddling in technical decisions but if you step back and take a look at it from a business perspective, it’s clear why considering these options is important.
Firstly and most obviously, component re-use reduces cost in the project which translates either to a reduced price allowing the business to stay competitive, or to increased margin which then helps grow the business. A business works by investing time and money and expects to get a return on that investment. By re-using something it has already developed, it is increasing the return on that original investment and for the bean counters at the top, this gets them pretty excited.
Secondly, it can be seen as a way to reduce risk on a project. Those charged with making sure the business remains sustainably profitable need to fully understand where the risks are in a project so that they can understand what can go wrong, how likely that is to happen and plan accordingly. No one wants to be the one in the hot seat if a project goes wrong exposing the business to millions in liquidated damages and as the system architect, that could be you!
So how can we spot and deal with ‘Solution First’ architecture when it happens?
One indicator that this is about to happen is when you are called in to look at a new project and instead of getting a breakdown of the key requirements, you are presented with a block drawing which looks like a previous system but ‘with a few small changes’. Big architectural questions such as, “so is this a batch system or does it need to be realtime?” are usually met with a blank stare.
These sorts of situations can be very hard to deal with. To maximise impact, it’s generally a good idea to reserve opportunities for telling your boss flat out that they’re wrong for times when it is really, really important. At times like these however, I’ve found it best to go along with the idea until you’ve had a chance to fully digest the requirements so that when you come back to them with a more considered solution, you are arguing from a place of authority. I also find it really useful to be able to argue my case in terms of risk, benefits, commitment, cost and impact on the business case. This is the language of the business and the ability to translate technical speak to business speak is a core skill for an architect.
When the pressure for ‘solution first’ architecture is external, it’s pretty easy to spot. It’s much harder to deal with when it comes from yourself though. One thing I’ve been doing that I find quite helpful is, having sketched out my outline architecture, to go through each individual component and ask myself exactly which functional or non-functional requirements it satisfies. If I can’t pin it on anything specific or it is out of scale to the problem it is trying to solve, I try removing it completely and seeing if the system can still do what it needs to do. If I don’t know the answer to the question, I’ve clearly not spent enough time digesting the requirements and another trawl through the documentation is in order. Quite often on the 3rd or 4th reading, it’ll become really clear what the customer is expecting and I sometimes find myself reworking vast chunks of the design as a result.
Additional check list items can include questions like, “Does this project just happen to need the latest cloud widget, big data, internet of things, mobile platform or whatever it is, or am I just really interested in this stuff?” If so that’s great but be aware that justifying that outside of engineering is going to be a big ask and one thing I’ve learned the hard way is that while you may find it interesting, by pushing new stuff like that onto an already stretched development team, you could be setting yourself up for open rebellion!
I’m not saying that you should never try anything new, far from it. All I’m saying is that I think it’s a good idea to be thinking about the balance of stable and well-established against shiny, new and interesting so that you can make considered choices about when, where and how to engage with new ideas.
So for me at least, having some idea of what my head does when presented with the job of designing a new system is key to making sure that the end result actually does what is required. My internal checklist includes asking myself questions like, “what do the requirements say? No really, what do the requirements say?”
I also try to avoid starting with system components and instead look at things like the flow of information through the system, who the key users of the system are and how do they expect to interact with it. What are the processes that the system needs to carry out and where are the external interfaces, do the systems they connect to already exist and if so, how do they work?
For me the most important question of all though is, does the customer already have a really clear idea of what they think system should be and if so, what is it? Only after these questions are answered can we really start making technology decisions and selecting components and thereby ensure that the systems we design and build perform well and deliver the functionality that our customers require.