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.
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.
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.
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.
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".
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.