Agile architecture

How can Architecture be agile? Surely Architecture is about designing the big picture, and Agile is about incrementally building things as you go along? How can these two things be reconciled?

Most companies think of architecture as something that’s done before you get to “the agile bit”.

But of course the truth is that almost every aspect of an organisation has to be agile in order to succeed, and architecture isn’t just creating a diagram of an IT system for the developers to follow.

Ever since I first started to move from a pure development role to more of an architect role, I started to see that in engineering if you want to go fast and stay safe, you need to be agile, and you need agile architecture. You need architects who are engaged in guiding both the business and technical teams throughout the lifecycle of the products or projects.

I’ve written about this and done talks on this subject many times, and wherever I’ve worked, I’ve often been the person who introduces or encourages more agile working practices, especially within architecture teams.

But I don’t subscribe to a one-size-fits-all approach. Different organisations, teams, products, and projects demand different ways of working. Clients don’t hire me to introduce Agile into their organisations, and I certainly wouldn’t recommend it where it didn’t fit. But what I do get hired to do is to deliver the outcomes they want and need, to bring clarity to complex problems, and to help deliver it effectively and safely. Here’s how I go about it:

Architecture done properly

Here are some truths which I live by in my work, regardless of the context:

• It isn’t possible to be an effective architect if you don’t talk to the software engineers, ops people, support teams etc. who understand the systems. You can’t stay at 30,000 feet and expect to make good decisions. You need to work closely with teams throughout.

• It isn’t possible to be an effective architect if you don’t talk to the people who understand the business, product, or organisation. Ultimately, the technology has to meet those needs, and it’s all too easy for things to get lost in translation, especially if there’s a divide between “business” and “tech”. There needs to be shared understanding of the challenges in both worlds otherwise there’ll be nasty surprises and disappointments

• Risks need to be dealt with, not just logged and forgotten about. One of the biggest sources of risk in an IT project are the unknowns – the technical issues which crop up and require unexpected detours. If there are warning signs that something might be tricky, that needs tackling early on with investigation, proofs of concept, or, best of all, a steel thread.

• There will be a lot of trade-offs and decisions which need to be made. These need to be clearly articulated in terms of their implications, and pragmatic decisions agreed with the right people. Identifying who those people are needs to be done at the start.
• Documentation, diagrams, and plans which no-one ever reads are a waste of time and create false confidence. They need to be engaging, informative, and relevant. They should evolve as our understanding evolves. Clarity should be easily accessible, and knowledge should never be lost just because someone left.
• We need to get things done. We need to move fast, but stay safe. One enables the other.

People

Nothing is more important than the people involved. I make a point of understanding who everyone is, and communicating with them so that everyone feels involved, engaged, heard, and motivated.

It’s very important that people are able to play to their strengths, and feel proud of the work we’re doing. Negativity, cynicism, and blame have no place in a successful team, and so I always bring a constructive, friendly, and honest approach to my work. I look to empower people around me with knowledge and purpose, and in doing so I find that it’s reciprocated.

“we have three innate psychological needs—competence, autonomy, and relatedness. When those needs are satisfied, we’re motivated, productive, and happy.”

Dan Pink, Drive: The Surprising Truth About What Motivates Us, 2009

Want to talk?

If you find yourself strongly agreeing (or even disagreeing) with what I’ve written, and want to talk about it – or if you’re looking for a solutions architect who can bring some order to the chaos and help you deliver effectively – then get in touch. I’d love to hear from you.

Otherwise, take some time to check out my blog.