How do you Introduce Software Architecture?
The Integration Zone is brought to you in partnership with Red Hat. Download the IDC Report: The Business Value of Red Hat Integration Products to learn more about Red hat Integration.
It's easier to ask forgiveness than it is to get permission
I get my fair share of questions about software architecture; ranging from queries about the role through to "I have this problem, how would you design a solution"? This question, though, represents a fairly common situation but isn't one that I get asked a great deal. I'm paraphrasing a little, but essentially the question was:
I understand software architecture and I get the stuff that you talk about, but our team just doesn't have the time to do it because we're so busy coding our core product. Having said that, I know that we need some architecture because we don't have consistent approaches to solving problems, etc, etc. How do we introduce architecture?
From my point of view it's worth asking a few questions to understand the need for architecture.
- What problems is the lack of architecture causing now?
- What problems is the lack of architecture likely to cause in the future?
- Is there a risk that these problems will lead to more serious consequences (e.g. loss of reputation, business, customers, money, etc)?
In this particular case, after a short conversation and a little more exploring on my part, the reason that no architecture activities had been introduced was because:
Our managers won't give us time to do architecture. If we're doing architecture, we're not coding.
How much architecture should you do?
Okay, so one of the things that I tell people new to the architecture role is that they do need to dedicate some time to doing architecture work (the bigger picture stuff) but a balance needs to be struck between this and the regular day-to-day development activities. If you're coding all of the time then that bigger picture stuff doesn't get done. On the flip-side, spending too much time on "architecture" means that you don't ever get any coding done, and we all know that pretty diagrams are no use to end-users!
This is one of those questions that you can't really answer in a classroom based training course because it requires changes to the way that a software team works, and these can only really be made when you understand the full context of the team. On a more general note though, there are two ways that teams will change the way that they work.
The majority of teams will only change the way that they work based upon bad things happening. In other words, they'll change if and only if there's a catalyst. This could be anything from a continuous string of failed system deployments or maybe something like a serious system failure. In these cases, the team knows something is wrong (probably because their management are giving them a hard time!) and they know that something needs to be done to fix the situation. This, unfortunately, appears to be the norm.
Some teams (ironically, usually the better ones!) proactively seek to improve the way that they work. Nothing bad might have happened yet, but they can see that there's room for improvement to prevent the sort of situations I've just mentioned.
So how do you introduce software architecture?
Back to the original question then. In this case, it seemed to me that the person asking the question was doing so with a view to proactively improve their way of working. After all, if something bad had happened there probably would have been a push from "above" to get things fixed. Instead though, in effect, the team was asking permission to spend some time doing the architecture stuff but they weren't getting buy-in from their management. Perhaps their management didn't clearly understand the benefits of doing it or the consequences of not doing it. Either way, the team didn't achieve the desired result. Whenever I've been in this situation, I either take one of two approaches.
- Present in a very clear and concise way what the current situation is and what the issues, risks and consequences are if behaviours aren't changed. Typically this is something that you present to key decision makers, project sponsors or management. Once they understand the risks, they can decide whether mitigating those risks is worth the effort required to change behaviours.
- Be proactive and lead by example. For example, if I start working on a project that has no high-level technical documentation, I'll start to create it until other people see the benefits and start contributing. Automated unit testing is always a good example of this - people get it when they see it, but somebody needs to put the initial seeds in place.
Each approach tends to favour different situations, and again it depends on a number of factors. Coming back to the original question, it's possible that the first approach was used but either the message was weak or the management didn't think that mitigating the risks of not having any dedicated "architecture time" was worth the financial outlay. In this particular case, I would introduce software architecture through being proactive and leading by example. Find a problem (e.g. multiple approaches to dealing with configuration, no high-level documentation, a confusing component structure, etc) and just start to fix it. I'm not talking about downing tools and taking a few weeks out here! I'm talking about baby steps where you evolve the situation by breaking the problem down and addressing it a piece at a time. Take 30 minutes out from your day to focus on these sort of tasks and before you know it you've probably started to make a world of difference. Stealth is often the key. What they don't know won't hurt them and I find that "it's easier to ask forgiveness than it is to get permission".