So what should an ‘agile architect’ be doing?

“So many architects walk around with the world on their shoulders. The responsibility of figuring out all this ‘stuff’ is supposedly taxing. Screw that… You are a creator… Go create…”

Agile Architect in his natural habitat.jpg

“An agile architect in his natural habitat dancing in a field of complexity…”

I recently wrote a blog on whether software architecture matters. It was a quick stream of consciousness hacked out in record time like most of my blog entries (probably riddled with grammatical errors and spelling mistakes). And like many of my blog entries it got a few muted grumbles from my extended professional network, especially from those that are ‘architects’ by trade.

The one thing that all of the grumbles had in common was the question of what I think a so called ‘agile architect’ should  be doing? This because I suggested that most of the design decisions should sit with the team. Not wanting to disappoint my somewhat less than usually chirpy ‘architect’ counterparts here is my list of things of things I believe we should be doing collectively:

1. Be part of the the development team

You are there to inform, motivate and influence the team without expending social capital by forcing your decisions. Being removed from the actual development effort and simply flinging architectural documents (that probably don’t reflect actual system code) at devs is not good enough anymore.

2. Adapt to the team’s way of working, not the other way around

In order to build high performance teams you need to create space for autonomy, mastery and purpose. The autonomy boundary can be constrained, but each team’s sweet spot in terms of their way of working will differ slightly. Standardizing your approach will simply lack the flexibility and variability that modern teams need and require.

3. Your job is to accelerate the project not to slow it down

Change priorities, trash requirements, architecture spike yourself to death. Whatever you do don’t stop the flow of value creation. There are many things that need to happen in projects. Many of those don’t need to stand still while perfect understanding (or consensus) is sought. Too many ‘architects’ plant their heels into the ground demanding big analysis when uncertainty is encountered. By nature they are top down thinkers that want to completely disseminate and understand a problem before making decisions. This however introduces a ton of friction into the development process. Defer as much decision making for as late as possible, outsource as much risk to others, focus on the really scary parts that can blow your design but don’t become another blocker.

4. Your job is preliminary about communication, do it often and early

It is really hard to create a shared understanding in the minds of everyone involved in a project (business, tech and design). Add different personalities, skills and backgrounds and it gets even harder. Heck even involving too many people or the wrong people too early is enough to explode the number of communication paths you have to contend with. So be transparent and open at all times. Trash complicated diagram standards and do everything in your power to drive context and understanding. Simplify and re-frame things over-and-over. Repeat this relentlessly until a semi coherent common understanding is reached and people start taking initiative on their own. Once that happens simply curate and make sure it is correct being careful not to trample and people’s attempt at contextualization.

5. Focus on the essence of the problem, the simpler the better

Stop creating artifacts, documents and stuff that nobody can contextualize. Even if you have to explain things over-and-over again this will refine the concept in your head and provide extra insights. Look at initiatives like C4 diagrams to get your drawings more in line with the actual thing being built.

6. Test your architecture

POCs or Architecture spikes are single-handedly the best way to validate parts of your architecture. But in too many organizations this is seen as a waste of time and money. Change the way you fund projects and cater for this activity. While you are at it always add slack for testing the non-functionals of your architecture (scalability, performance and robustness).

7. Question standards

Corporations are rife with cargo-cults that never question why they do the things that they do. “It is just the way it is done, or the standard”, is a common refrain. This is such a bullshit attitude that guarantees sub-optimal solutions. Be ruthless in questioning ordained “standards”. Especially if a “standard” is merely written down glorified opinion piece that has never been tested and validated.

8. Promote agile practices in other areas of the business

Unfortunately most organizations only embrace agility in their delivery teams. It is your job to promote lean and agile practices in the supporting functions that support the team.

9. The most important thing: Don’t take yourself so seriously

So many architects walk around with the world on their shoulders. The responsibility of figuring out all this “stuff” is supposedly taxing. Screw that… You are a creator… Go create great things with your teams, have fun with them and enjoy it. Stop taking yourself so seriously.

 

Advertisements

Does software architecture matter?

“This means that no distinction should exist between architecture and the act of coding. It is an activity that should be a shared concern of an autonomous team building a system collaboratively.”

fba7038527ae2d58a26a984c58e6e95d.jpg

The strangest version of this functional role is when someone that does not come from a technical background starts making proclamations about architecture…

One of the strangest functional roles that exist in corporate software development environments is that of the “software architect”. The very term evokes images of a senior engineer that has by virtue of his or her experience mastered his or her craft so well that they need not partake in trivialities such as writing code anymore.

Just like the architect in the movie ‘The Matrix’, these individuals can simply sit and make high brow proclamations about how software should be built. Afterwards they can marvel at the genius of what they have supposedly conceptualized while skeptically bemoaning the apparent failures on part of the people that had to execute on their vision.

The biggest problem with having these ivory tower styled architects is that if you are going to be conceiving of software design (and be a “technical person”), you simply have to be comfortable with the actual act of coding. That is after all the activity that makes the design real and has it own set of nuances and intricacies.

This means that no distinction should exist between architecture and the act of coding. It is an activity that should be a shared concern of an autonomous team building a system collaboratively.

Of course it helps being able to articulate architecture and highlight impacts of technical decision making especially in ways that non-technical people can understand. But that is a skill that every technologist should strive to perfect, not just the select few that carry the title of an architect.

The strangest version of this functional role is when someone that does not come from a technical background starts making proclamations about architecture and gets labelled as one. The subtleties of technology frameworks and practicalities of actually building coherent software systems would be completely lost on such an individual. Yet modern corporate environments are rife with these types of individuals who “build” systems every day.

So what is architecture then if anything at all?

Personally I like Martin Fowler’s view that if there is such as thing as architecture, it is essentially about two things. One is about creating a shared understanding in your teams and the other is actually investigating and answering the things in the projects that will be hard to change in the future.

The rest you can leave to your very capable and trusted development team.