The Drawbacks of Architectural Freedom

A couple of senior architects from eBay dropped by the other day and gave an excellent talk on the architecture of the company’s systems. It’s public domain stuff and you can find the slides from another presentation of the same talk here.

At this point, eBay doesn’t have a Service Oriented Architecture (SOA). Most of the systems are deployed as a monolithic application that access the usual Oracle database backend. The development environment is more or less aligned with this architecture in that there is a single set of libraries that all applications use for cross-cutting concerns like abstract data access, logging, etc. The eBay guys called this set of libraries “the eBay kernel”. They also have a company-wide software rollout schedule. Their guiding principles include never doing client-side transactions, never, never doing distributed transactions, and favouring optimistic data management combined with asynchronous reconciliation over strong referential integrity.

This is vastly different from the environment that I work in: in my world, each team (service) operates relatively autonomously and has the freedom to choose whatever technologies it deems fit for the purpose. Each team cuts releases as it sees fit. As you might imagine, the result is a hodge-podge of different technologies used for the same functions and constantly broken service dependencies due to constant deployments. There are no principles regarding transactions or architecture besides just good software engineering principles. While the freedom is empowering, it also results in a lot of wasted engineering time setting up, say, an object-relational mapping engine or logging infrastructure. On the same vein, the engineers in this environment essentially need to know how to do everything. They need to know databases, they need to know subtle details of their applications’ interaction with the operating system in some cases, they need to know system and network operations, and they need to know deployments, all in addition to just writing good software. These types of engineers are expensive. So is the freedom worth the cost?

A buddy of mine spoke to a senior principal engineer about this matter and he analyzed the argument as follows: In Singapore, there a many rules. One is bound to follow these rules, but the results are significant: goddamnit, the streets are clean. In America, one can generally do what one pleases, and so the story goes, this is what provides the fuel for growth. At the same time, many people think nothing about throwing unwanted paper on the street.

I don’t think we really need to throw out the benefits of SOA and architectural freedom just to get the benefits of what they have at eBay, however. The trick is in the development environment. Give engineers common libraries for implementing cross-cutting concerns and provide incentive for them to use such libraries, and they will use them. In other words, give engineers some incentive not to make a mess and there will be no mess. I really do believe it’s that simple.