The tactical solution

Thu, 21 Jun 2007 19:08:10 GMT

Those of you that get involved in the very early stages of a software project might have heard this a few times before.

We just need a quick tactical solution.

In my experience, there is no such thing as a tactical solution and a translation of what is really being said is as follows.

We need something built as quickly as possible and, although we *think* it will have a limited lifespan, it will more than likely remain in use for some time into the future.

In the fast paced world we live in, everybody wants everything as soon as possible. Building something quickly isn't the same as building something tactical though. For me, a tactical solution can be thought of as a stopgap. It's an interim solution. It's something potentially quick and dirty. It satisfies a very immediate need. Importantly, it has a limited lifespan.

Working software is what our industry is all about and when people see it, they often start thinking about new ideas. And it's here that the biggest danger lies. On paper, a tactical solution looks exactly that; tactical. A real-life, working tactical solution can easily be perceived as something much, much different.

Being the software architect of a tactical solution is a potentially tricky situation to be in. On the one hand you have to balance the need for a fast delivery and on the other you have to balance the key non-functional requirements such as performance, scalability and system lifespan.

I want to keep this blog entry short so I'm going to finish by saying that there is no such thing as a tactical solution. As an anecdote, the last tactical solution I built has been running since 2005. I'm sure you have similar stories. Next time I'll share some of my thoughts and experiences about designing a tactical solution.

Options

Thu, 07 Jun 2007 18:26:00 GMT

A recent consulting engagement has involved me defining a system architecture to solve a particular business problem. While coming up with something that meets the functional and non-functional requirements can be hard in itself, you always have to bear in mind there are always alternatives. In essence, you'll probably come up with several options, regardless of whether you present them all.

The key thing that really struck me recently is that options can vary quite dramatically when you start to think about some of the additional constraints and trade-offs that can be/need to be considered. For example, your "ideal" architecture might be a distributed n-tier system but an alternative architecture might be a simple desktop application if infrastructure simply isn't available. Likewise, if time-to-market is the critical factor, you might even find yourself going down a number of different routes, some of which might be highly tactical and some might involve the use of an off-the-shelf product. Other important aspects might include existing vendor relationships, in-house skillsets, functional scope, non-functional scope, etc.

Whatever options you come up with, whoever is making the final decision needs to have as much data available in order to make the most informed decision possible. Unless you really are spoilt for choice, options represent trade-offs and sacrifices. If you know what these are, you have a much better chance of choosing the right option.

Coding the Architecture - sacrifices tag

The tactical solution

Options