Line-of-business teamwork

Somebody asked me what technologies had recently piqued my interest, and in what ways.

I'm actually more focused on solving interesting and/or hard problems, rather than on the technology itself. Without a specific grounding in the business problem, any technology-related changes that you make (for example, introducing NoSQL) will be built on a weak foundation and can be fragile and prone to disintegration.

Having said that, I'm just pushing the question one level down the stack. There are indeed some interesting and hard problems where I think that new technology ideas can make a big contribution. One area that I've been thinking about recently is how you should assemble IT project teams within a line-of-business enterprise such as a bank. 

Traditionally you assemble a team using people with specific technology skillsets. Let's say that you've decided to build a new commodities trading system. This is going to handle trade capture and position management for base metals, precious metals, and energy. You might start by recruiting developers that each have a specific technology focus:

• UI specialists for the GUI.
• Server-side specialists to build the business and API logic.
• Database specialists for the persistence layer.
• Finally, the only real concession to the business domain would be to hire a business analyst with good knowledge of commodity products.

So each team is built around a specific technology skillset and a specific horizontal slice through the application. The whole team might logically look something like this:

But what happens if, instead of focusing inwards on the technologies, you build your teams by focusing outwards on business capabilities:

• Full-stack specialists for Base metals .
• Full-stack specialists for Precious metals.
• Full-stack specialists for Energy.

Now your whole team looks (logically) something like this:

And this is a very different way of thinking about the world! Now your teams don't come together to build specific systems or to make specific technology changes. Instead they come together to introduce new business capabilities, and stay together as long as that business domain needs more changes. There are several benefits to this approach:

• Each team specialises in a specific business domain. That means each team faces directly towards their specific business, which quite naturally coincides with the way that business views (and wants to fund!) the world. 
• Teams tend to be longer-lived, as they're supporting a business domain rather than a specific system or technology domain. Developers certainly aren't plug-compatible components, and are usually happier when they're working with other people whom they already know and respect. The longer a team works together and builds its social capital, the better that team performs.
• Each team can use, and be totally responsible for supporting, their own technologies and technology implementations. They face outwards by providing APIs to other teams over universally-used protocols such as HTTP request-response. Don't get me started on the the interesting idea of HTTP as an application protocol.
• This approach fits quite naturally with interesting technology architectures such microservices and interesting patterns such as composite front-end.

Of course this "new" way of thinking about the world isn't actually that new, and also brings with it a whole new set of questions. For example, refactoring is much harder with remotely-connected services than it is with in-process libraries. But I think it's still interesting to think about new approaches to teamwork, and how these can be enabled with new technology and architectural ideas.