Architecture enabling business

Don’t you love it when you think of things to blog about at 3AM… I guess I would have preferred to be asleep, but having a (hopefully) interesting blog post idea is a reasonable second choice.

Let me start by saying that I’m focused in this posting on organizations of a “certain” size – say bigger than 50 developers. I’m not talking about small companies. I’d offer a pretty much totally different set of thoughts and opinions for that kind of organization; I’d even go so far as to say that a small company has the responsibility to pretend that there’s nothing to see here, and should get back to getting product out the door.

So, standardization. It’s an idea that management loves. By management, I mean people that are primarily focused on large-scale organizational planning and budgeting, rather than on the specifics of executing projects. Perhaps a fuzzy line, but bear with me. Management loves standardization because you can make arguments like: “if I only have one {platform, language, pattern, keyboard, kind of chair, brand of monitor} to worry about, I can get more out of each precious dollar.” To an extent, this is true. Unfortunately, it deprives us of the opportunity to leverage something special – i.e. non-standard – when that special, non-standard thing could make my problem much easier to solve or help me get my project done that much sooner.

Sometimes this tension surfaces as an organizational allergic reaction: you’re killing my innovative spirit, man! Let me be to use Jimbo’s Foobarilicious Language #4, v.001alpha, it’s the coolest thing ever and I’m going to get my project out the door in a week and a half! But seriously, it’s probably just “I know the company standard is Java, but why can’t I use .NET?” Or, “I have tons of experience with Python and Django, why do I have to write this greenfield web application in ASP.NET?” Good questions.

Both sides of this argument have good points: there’s a lot of advantage to be gained by avoiding unnecessary or inappropriate proliferation of technology. It makes organizations more agile, because more people can work on more pieces of the puzzle, assuming that we’re not all capable of really, truly, being effective on more than one or two technology platforms at a time. However, getting painted into a technology corner makes companies more susceptible to crustification – getting rigid and boxed-in, while the technology train rolls on.

How to reconcile? It doesn’t take much to reach the simple conclusion that one-size-fits-all isn’t the answer. Even if you have the luxury to focus on a single, uniform technology environment, you’ll eventually get to a crossroads where you have to face the tension between following a standard or taking on a new approach. I should make the point here that this isn’t always a macro concern – it comes into play at the micro level in the context of design patterns, naming conventions, tool selection, and so on.

My answer is to find “a few sizes that fit most”. That is, figure out what classes of solution (that’s purposefully vague) can respond to the needs of your business, make informed choices about adopting a small subset of these solution classes that cover most of the needs, and be prepared to have exceptions sometimes. In my experience, this approach manages to strike a balance between unbounded technology proliferation and over-constrained standardization on too few solution options in a given problem domain. I’ve had good success with applying this approach in large enterprises by standardizing on a single technology platform for all customer-facing (maximum reach) applications, another for backend transactional systems and a third for internally-facing (maximum richness) applications. There were exceptions, but they were identified and managed explicitly; this explicit management gives us some leverage over the problem of managing the solution portfolio, so we can avoid getting painted into a corner over the long term.

UPDATE: This morning, while waking up (apparently when I do my best free association), I realized that I started talking about some of these ideas during a panel at OOPSLA 2003!  Unbelievably, I also found a long-forgotten blog I wrote about it; unfortunately, the link to my notes is broken.  I’ll try to track them down.

UPDATE: I found my notes from the OOPSLA panel.