Coding the Architecture - design tag

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.

Simplicity

Fri, 17 Feb 2006 21:24:29 GMT

As an architect, you'll undoubtedly be called upon to make decisions about how a particular requirement should be fulfilled. Remember, you bring together the appropriate balance between functional and non-functional requirements to produce what the end-users need. However, some decisions are easy and others are hard. To take an example, imagine that you're building a new website to replace a couple of sites that exist already. Also, let's say that all users of the new website must re-register their accounts in order to consolidate their logins across the existing sites.

Now, clearly there several ways to make this happen. The first of these is to provide a transparent re-registration process so that users can enter their existing username/password combination. Upon logging in with these credentials, an initial attempt is made to authenticate them against the new consolidated authentication realm and, when this subsequently fails, tries to authenticate them against the existing realms. Assuming that the user is authenticated against one of these existing realms, their credentials are then automatically migrated into the new realm.

Ideally, this is great because users can just use the new website without any knowledge of the re-registration process because they use their existing username/password as normal. From a technical perspective, however, this raises some interesting issues, particularly if you want to take advantage of something like Java EE's container managed authentication or any other mechanism that expects you to perform authentication in a specific way. True, you could customize a security framework (such as Acegi) to incorporate this credential migration behaviour, but would you really want to pollute a simple authentication process with it? Think about how difficult this would become to implement/test and what happens if a particular username is shared by different users across the different existing realms?

There is, of course, a much simpler solution whereby the user is offered a facility to explicitly migrate their account via a "click here if you've not used the new site before" link. Just think about it. No complex authentication/migration logic and the user knows exactly what's going on because you can explicitly ask them for a specific username/password combination.

For me, the latter solution represents something that's much easier to design, build and test, which leads me to imply that it's going to be developed quicker. Also, it's potentially more secure and can easily be "switched off" when it's deemed that all users have (or should have) migrated their existing accounts.

Simplicity is something that an architect should strive for, especially when the elements (such as time) are against you. Clever solutions are often complex, but simple ones can be clever. Always strive for simplicity.

The Top Ten Ways to Botch an Enterprise Java Application

Wed, 25 Jan 2006 13:28:33 GMT

If you're planning on heading to JavaOne this year, Cameron Purdy will be presenting what sounds like a very interesting talk on the top ten ways to botch an enterprise Java application. From his blog...

Two of my presentations were accepted for JavaOne, including a new one that I've been working on: The Top Ten Ways to Botch an Enterprise Java Application. I think the hard part will be limiting myself to only talking about ten of the things that I've seen! ;-)

I've given some funny (and unfortunately real-world!) anecdotes as part of some of the presentations that I've done on scalable performance and distributed caching, including the "checking the HR database on each HTTP request to see if the current user got fired since his/her last HTTP request" (one of my favorites). So what is your personal "Top 10 List" for ways to completely botch an application?

Reading through the comments, there are some funny stories and I only wish that I could say I've not seen these myself. One of the best ways to learn about architecture, what works and what doesn't, is to listen to others talking about their experiences. If you're at JavaOne, don't miss this opportunity.