Conway's Law and how architecture is also about people

This is based on a post I originally wrote for Nordea's internal architecture blog.

Many of you will be familiar with Conway’s Law: the idea that organisational structure determines the structure of the systems that teams build. The canonical example is “if you have three teams working together to build a compiler, you’ll get a three-pass compiler”. However, the implications run much deeper than this. I’m going to share with you two key thoughts that I hope will provoke a little discussion about how you do things in your organisation. Maybe you’re already getting this right – in which case, please share your story, especially if you're in a large organisation or not a software house!

Systems and processes should drive organisational structure, not the other way around

Departments are reorganised often enough, even in static organisational structures, but how frequently is the IT setup used as input to that? I have observed a tendency to group teams together based on their business function, rather than based on the dependencies between systems. So, you’ll end up with teams responsible for maintaining three different trading systems that have nothing to do with each other placed in the same group, while the systems that they each feed into are located elsewhere in the organisation. It's typical to split trading systems into front/middle/back office, when there are sometimes separate flows.  The strong dependencies in systems aren’t always reflected by close team connections. These strong dependencies could indicate value chains or business processes – why not structure based on those?

Think, too, about the consequences of the organisational structure. If you draw the enterprise architects above component teams on the organisational chart, you’ll probably end up with an architecture diagram where you have an enterprise service bus sitting above all the separate components. But, when the decision to structure the organisation was made, was it borne in mind that that would be the result?

When projects start up, I’ve noticed that two things seem to happen with alarming regularity. The first is that someone asks the question “but which team will be responsible for maintaining this when the project ends?” It's better not to take such a static view of the organisation – especially when it’s bound to change anyway. Instead, ask “How can we structure our teams to support the new landscape?”

The other thing I've observed in some organisations when a project starts up – especially if it’s an improvement project rather than green-field development – is that the project will be staffed without changing team structures, allocating “resources” sometimes even based on a percentage of their time so they’re not fully committed. So, you end up with people spread across different teams, perhaps even sat in different countries, with their focus being their team and not their project. Why? Do we really want to be building a bunch of disparate components? No. In order to build systems that look, feel and perform as seamless, integrated units, project teams that do the same should be created. Make one project team and one reporting line so that the project is their sole focus and the solution will be better as a result.

Watch how you communicate

More attention should be paid to the way that developers responsible for different components interact, because that will be an indication of how well the components themselves play together. If the maintenance teams for two components talk frequently to each other; have a good understanding of what each other is doing and achieve results quickly, you can expect that the interface that’s implemented between those components will work well. But if people have to send queries to a common mailbox and wait days for a response that doesn’t exactly constitute an answer, that could be a sign of bigger problems within the software that is built. Why? One reason is that the consumer will end up working with what they get and either guessing or reverse engineering it, working based on what they think they’re getting instead of a well-defined interface. Another is that, if people even have to be sending questions like that, there probably isn’t enough documentation. And if you find that the project is held up because you’re waiting for answers from some other team, chances are you’re building a tight coupling to the system you’re dependent on.

Now think about the wider context. How is the relationship between IT teams and their business counterparts? The strength of communication between business and IT is an indicator of how good a solution will be built; how well it will fit the needs and how satisfied the users will be. Large organisations are good at holding business and IT at arm’s length from each other, communicating through steering groups where there is no technical representation. It doesn’t have to be this way! Bring a solution architect or lead developer to a steering group meeting and stakeholders will get their answers there and then. (I'll leave the discussion about the pros and cons of steering groups to one side.)  Rearrange the office to sit business representatives and technical teams together to encourage communication – not just explicit communication, but the implicit communication of seeing how users work. Bring people closer together when you develop new systems, and you’ll develop systems that support what people do.

This drives to the heart of IT development

The word "digitalisation" has become immensely popular within the last few years.  IT is an increasingly large part of businesses, and in the finance industry where I work, IT is the business (even if that's not fully accepted yet). To succeed, and to do system design right, there is a need to base organisational structures on our systems and processes, and ensure good communication between teams so that they build components that play well together – in that order.