The Pitfalls of Technology-Driven Architecture

Software architecture is about technology, and it's nearly impossible to talk about software architecture without talking about technology. But software is meant to serve the needs of a particular set of users, to solve the problems in a particular domain. Likewise, the architecture of a particular piece of software should be intended to solve the problems that face the software within a particular domain. Architecture is driven by business need.

Architecture is Driven by Business Need
For instance, the domain of mass-market internet search requires searching for words within a vast quantity of data, returning the results very quickly, and doing so for a large number of people. Accordingly, the architecture is one of work-division and work-sharing, scale and data-handling, as is evident in the details of the architecture that Google has occasionally shared.

Technology-Driven Architecture
Unfortunately, it's common to see architectural discussions revolve solely around technology, where the technology and the architecture are not clearly linked to the problems facing the business, at least in the near term.

You can often see this when technologists of one shade or another (architects, chief technology officers, developers, whatever) get excited about a particular technology. That technology starts to show up in discussions without being grounded in business need. For example, if a technologist believes that .NET has better tooling than Java, he or she might start suggesting that any new project be built in .NET without having considered the cost and benefit to the company or organization in which he or she works.

Warning Signs
The most concrete and obvious warning sign for technology-driven architecture are when new software designs and architectures are proposed and discussed, and the technologies and the generalized benefits of those technologies are described at length but are not tied directly into the problems that are facing the business.

A secondary warning is when the architecture is tied to problems facing the business, but not the most immediate problems. If the architecture addresses future-facing or secondary problems, you have to ask yourself: Are these the right problems to be traclking right now? For instance, cloud computing architectures address scale, but many businesses have much more immediate problems than how to scale.

These choices are less black-and-white. It's true that many successful software businesses will eventually face the problem of how to scale, and if you ignore that potential problem right through the architecture and design of your application, you may end up paying a heavy cost at some later date. On the other hand, if you decide that scale is a problem you will eventually face, you might spend a lot of time building solutions to scale-out into early product designs, slowing down the development, restricting choices, and generally making it that much harder to succeed. These kinds of long-term architectural choices can be insidious in both directions.

You'll also find warning signs whenever anyone argues that a particular technology is just better than the alternatives, as if there's no trade-off to be made. There's always a trade-off to be made, and ignoring the costs in a new technology has sunk many a project into unexpected quagmires.

Common Examples
Some technologies make regular appearances in technology-driven architectures. They're technologies that sound good, that cause some people to believe they're just better, without seeing the inherent tradeoff. These examples are probably no surprise to anyone. :

• Enterprise JavaBeans
• Service-Oriented Architecture
• Rule Engines
• Workflow Engines
• Business Process Management (BPM / BPEL)
• Enterprise Service Bus
  

Each one of these can have benefits when compared to some of their alternatives, but each comes at a cost. They have a tendency to complicate the architecture, add more moving parts, reduce the predictability and testability of the final solution while slowing development. They can require a different mindset in order to use effectively. And then there's the more visible costs: learning curves, licensing fees, support contracts.

Exceptions to the Rule
There are exceptions to every rule, including the rule about there being exceptions to every rule. This rule is no exception. ;)

There are some instances where technology-driven architectural choices make sense:

• Good prognostication is very hard, but if your team has a great track record of taking on future-facing problems in advance and you trust that, if the team wants to explore a technology, they probably have a good reason for it, and it'll work out in the end ... well that's a judgement call you can make.
  
• Choosing an architecture based on a technology for a project that isn't on the critical path for a business can expose the development team to a new technology, allow them to explore it, find its strengths and weaknesses. This will allow them to make business-tied decisions about that technology in the future, and increase the odds of success if that technology does prove valuable on a more critical project at a later date. Even here, though, if the technology doesn't have an obvious link to the problems facing the business, it may be a waste of time to explore it at length.

There are all sorts of reasons to make technology and architecture choices, and I can't possibly tell you that your architectural choices are right or wrong. Mostly, I'd just like anyone proposing an architecture to stop and ask themselves what business problems this architecture addresses, and if those are the right problems to be tackling.