Designing the tactical solution

Wed, 27 Jun 2007 20:16:00 GMT

In my previous post I asserted that there's really no such thing as a tactical solution, but what should you do if you are asked to design one? Before I answer that, let's summarise what a tactical solution is all about.

... 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.

Tactical solutions are all about fast delivery and limited lifespans. You need to take *both* of these into account if you are asked to design a tactical solution because they will undoubtedly influence your design decisions. Let's look at each in turn.

Fast delivery
Compressed timescales will alter the way in which you tackle the design process, so here are my suggestions for dealing with this.

Don't agonise over design decisions. Do the simplest thing that could possibly work in the available time and then stop.
Be explicit about what your solution will and *won't* do. If the timescales have made you choose a design with limited future extensibility and flexibility, make this explicit so that everybody (including the stakeholders) understands the trade-offs that have been made and the impact they have in the future.
On a similar note, make sure any assumptions you're working with are known by everybody.

Limited lifespan
A limited lifespan typically provides you with some boundaries for your key non-functional requirements and you can use this to your advantage.

A tactical solution with a one year lifespan means your solution (in theory) only needs to scale to support data volumes for one year (plus a bit for safety). This makes some design decisions much easier, such as whether you need to design a solution that is horizontally scalable.
Be explicit about what your solution will and *won't* support. If the limited lifespan has influenced your decision to build something that is simple rather than highly scalable, make this explicit so that everybody (including the stakeholders) understands the trade-offs that have been made and the impact they have in the future.
Again, don't agonise over design decisions. Do the simplest thing that could possibly work for the anticipated lifespan and then stop.

As Kevin commented, a better approach to building a tactical solution is to make it the first delivery of a larger and more strategic solution. Sometimes this isn't possible though and delivering a solution with a limited lifespan in compressed timescales means that you have to make some trade-offs. If you find yourself in this situation, don't agonise over design decisions and make sure you're explicit about what the solution will and *won't* do.

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 - trade-offs tag

Designing the tactical solution

Options