Earlier this year, I twitted this:
and that:
Though seemingly disconnected these tweets are actually related. So here we are, in the blink of an eye, almost five months later and I can finally find some time to circle back to these ideas and expand them a little.
Both these tweets are related to the problem of growth and the pains a software company goes through when it expands.
At the beginning of a company, life is good, sharing code is easy. Whether everybody sits in the same room or not, the number of people involved in coding the product is so limited that synchronization is easy. Friction is limited, things go fast. Conflicts can be resolved with beer and pizza.
If by accident (!) the company ends up being successful, things change, sometimes very quickly and most of the time not for the best. So the team grows, divides into groups, and once the 150 persons mark gets passed, people start losing track of who's who.
The traditional path to a graceful handling of growth consists in adding layers of management. Whether the control this approach brings is actual or illusionary, the fact of the matter is that it increases the distance between teams. Here I'm not talking about physical distance, though it may be the case, but really about the
perceived distance, the kind of distance from which the "us versus them" mindset stems.
Independently of all that, code still gets written. As the business has grown, so did the code base. Teams are sharing code. But now any code change must go through several layers of management, both up and down for each team. Fluidity has been lost in favor of process, which protects the business stability by doing what process does best: slowing things down, if possible to the point nothing happens thus preventing anything bad to happen.
At this point, the sheer fact of sharing code becomes a heavy burden. In software companies, shared code doesn't typically consist of pure libraries, like Apache Commons. Shared code more often than not involves shared dependencies on enterprise resources, like databases. High level of coupling, if not tangling, exists in the shared codebase. The mismatch between the boundaries that have been cut across teams and the actual software artifacts' delineation becomes an impediment to progress.
This is where the idea for a Service Oriented Organization comes from (notice how I avoided
Service Oriented Business for obvious "acronymistic" reasons). It is not about getting rid of management or meetings. It is about
organizing teams around tangible boundaries that fit the needs of sustainable software development.
In a Service Oriented Organization teams interact around well defined contracts: APIs and SLAs are the promises teams make to each other. And they fully define the actual extent of their commitments to each other. Teams do not share code but services.
Having clear objectives in order to achieve common goals without exposing any gory details is beneficial both for people management and software development. Whether APIs expose fine-grained technical methods or coarse-grained business ones, teams will have the rabid desire to provide the best service possible for what they're responsible of, and this for functional and non-functional qualities.
Of course, all this sounds nice and rosy and quite possibly the wishful thinking of an utopian. The quest that many people have embarked upon is to find ways for corporates not to succumb to the illusion of control and grow themselves into dumbness.
Service Oriented Organizations have been
discussed before. This is just my two cents about the concept. Please share yours.
