The Pendulum of Architecture

If you’re a developer, you’d probably have to have spent the last couple of years in a coma to not notice a trend towards simpler tools, but I want to write a bit about the changing tides in software architecture because I think there is more below the surface.

Around 3-5 years ago was the peak of an era that could be called “the Church of Martin Fowler”. Big software design patterns were in. All of our domains were to be modeled, everything needed a service class, and interface oriented design was all the rage.

Before anyone gets upset that I’m disparaging Martin’s name, let me see the man is a genius. And like any object of worship, terrible things have been done in his name, whether or not he asked for them. In other words, many of these patterns were applied to pieces of software that did not fit the patterns.

But I’m less interested in debating the past and more interesting in discussing where we are now. Rails was one of the first blows against large, complicated software creation. Today, many in the ruby community talk about the bloat of rails, preferring frameworks like padrino, sinatra, etc. Most new languages build super light weight web frameworks first. Look at compojure for clojure, or express for node. Personally, I happen to really like Sinatra, and have used it for a handful of sites that I help with in my personal time.

Does this mean software patterns are dead? Should we all move back to php (which may have been ahead of it’s time)?

I think there is something else going on, namely that tools are addressing a different level of the problem. Pragmatic programmers (literally, not referring to the publisher) often site the adage “use the tool for the job”. Combined with the long cited un*x philosophy that its tools “do one thing well” we can see a pattern emerging. Sites can do one thing well, expose their interactions via http, and build a system of of smaller systems and their interactions.

I don’t think the tools are moving away from complexity for simplicity’s sake, I think they are moving to a new way of dealing with complexity. The tools (sinatra, express, nancy) are designed to create subsystems and you are expected to stitch the subsystems into the complex systems.

It’s like SOA, with http as the service bus, and more explicit dependency bindings.

I think that’s an important distinction. Enterprise architects look at some of these simpler tools and feel that they are toys for smaller sites. But those that embrace them are saying back to that architect “why have tools that provide safety and assimilation across 50 developer product teams, when you can avoid having one big project with 50 developers?” And that’s not a bad question. There are some real analogies to Steve Yegge’s recent software conservatism vs liberalism post.

I’m not taking the position that one side is always right. These are approaches, and any approach tends to have contexts that are it’s sweet spot. But I think this new trend is massively misunderstood. Similar to how many folks think that NOSQL means “No SQL”, instead of “not only sql”.

One question is, can the vendors catch up? Or will this only be an open source trend? Microsoft cleaned up it’s web stack with ASP.Net MVC, but it’s still on the heavy side in comparison to the direction that the open source community is heading. Does Microsoft have the capability to embrace something the size of Nancy? Some would argue web pages (razor) was that answer, but it seems to lack the first class prioritization of routing and http that the open source frameworks do.

Thinking back, it’s easy to wonder why this didn’t happen sooner because of SOA. Maybe this is what the SOA community missed, that better (and simpler) tools were needed to build at the new level that SOA asked the developer to target.