Having helped many companies with their architectural decisions, both big and small, I have in my bags a few tricks to make things go smoother and more effectively for everyone.

One of the major issues is that no one team is the same. I don’t have in my bag 3 solutions that I simply hand out to my clients. The same basic problem, solved by 2 different teams, should likely have different solutions. Your architecture and design should be tailored to your organization: strengths, talent, business needs, all vary and have to be considered on a case-by-case basis.

And ownership is a big part of this, of course. A solution dictated by an outside consultant wouldn’t go well with your team, as well it shouldn’t. While I’m only there for a few months, they will be living with this vision for years.

The issue is getting the right feedback from people, and getting the ball rolling. One of the tricks I use here is to use the fact most technical people can’t resist debugging a solution.

That’s where the straw-man architecture comes in. Much like a straw-man argument, this is a high level solution diagram that is mostly intended to be taken down by the team. I start with the most trivial flows, lay them out in front of the team and then let us all attack it.

Having something concrete to start mulling about, instead of having a freestyle “let us all design together” meeting seems to work much better in practice. And after you’ve written down the decisions, or extra research that needs to be done, you update the diagram to un-straw-man it. This process can repeat in multiple levels, going higher and higher in resolution, straw-man to concrete, straw-man to concrete, until we’ve reached the level of confidence we wanted.