Organize by Architecture

Most companies start out making one product. Then they add another, and another, and soon chaos ensues as the team is overwhelmed. They start splitting people into more teams, each with managers, each handling one or more products, and each reporting to another manager. Hey, it's only natural and it sort of makes sense.

A tree structure evolves, one that we have all seen countless times before throughout our careers (Often hailed as the amazing result of the latest re-organization):





Now the question is... Is this the best we can do as an organization?

Really?

What if instead your organization was organized by Software Architecture? What if each team was responsible for just a part of big picture, their part, their module? You may say that they already are, but I want you to ask yourself if each team performs these tasks:

1. Analyze and design their own code?
2. Manage incoming requirements, specifically for their code?
   
3. Test their own code before releasing to other teams?
4. Manage their own bugs?
5. Know which other team they are receiving software from?
6. Make their own release plans?
7. Make their own releases, planned out with release notes and features?

Do you know when team X will deliver their next version of their code, who they will deliver to, which features are included (a feature being a feature for that code), how it was tested, and which bugs there are?

Most likely, you may have team responsible for parts of the code, but requirements comes through a central process, testing is done by a separate team on entire products, releases are done 'as needed', or through a central repository, and updates to any part of the code are done, well, whenever some little part maybe complete.

The result? Organized chaos. Each team will release each little bug-fix, each little feature, in random intervals, and as testing for the next product commences, a truckload of big nasty bugs pops up.

Yes, even with Agile, this can happen.

Organize by Architecture

There is a better way. I know, I tried it when I worked at Nokia Mobile Phones (I was the Chief Software Architect for the CDMA Business unit in San Diego).

Organize your organization the same as your software architecture. Treat each team as a separate unit, and let them plan their releases, architect their solutions, test their code, and deliver to other modules. Doing so is part of the Software Product Line paradigm, and it will give organizations with many products and large code bases a way to improve their delivery quality and times. If done correctly (And Nokia did not always do everything correctly).

In my next posts, I'll touch on how this works, and what such an organization may look like. I'll also write about some of the pitfalls I've seen, and my own suggestions on how to avoid them.