Coding the Architecture - tactical tag

London User Group - Tuesday 4th September 2007

Wed, 05 Sep 2007 19:01:00 GMT

A big thank you to everybody that braved the tube strike to come along to the Coding the Architecture session last night. We started the evening with about 6 people and ended with around 20, which was excellent. Thanks also to Skills Matter for hosting us and to Neil from Omni Resources for coming along to buy us all a beer afterwards.

For those of you that came along, we hope that you found it a useful session. For those that couldn't make it, I presented a short session about architecting tactical solutions before we broke into a group discussion, during which some really interesting points were raised.

Your tactical solution might not be so tactical if you spot the following warning signs : "the system must be secure", "the system must be centrally deployed", "the system must be auditable", "we need pages/screens to administer the system", etc.
The effort that goes into developing a tactical solution often outweighs the lifespan of the system (assuming that it really is limited, of course). A couple of examples cited were a 2 week build (1 person) with a 1 week lifespan and a 4 week build (4 people) with a projected 3 month lifespan.
Your technology choices and decision on how much quality assurance to perform (e.g. automated unit testing, coding standards, etc) probably reflects your thoughts on whether *you* will be the one that has to support the system and come back to sort out problems in the future.

The entire discussion was very good, but those are the points that stick out in my mind. At the start of the session, I said that we're looking for other people to suggest topics, present and lead sessions. We're not necessarily looking for polished PowerPoint presentations or expert speakers, but we are looking for people that are willing to share their software architecture experiences. Here is our list of potential future topics, but please do get in touch if you have your own ideas and/or want to present. Case studies of software projects from an architecture perspective would also be interesting.

Making the jump from developer to software architect.
Coding and the role of a software architect.
What do you capture in your software architecture document?
Dealing with non-functional requirements.
Real-world experiences with SOA.
Agile architecture : How much is just enough?
Hiring software architects.

Again, thanks for coming along. You can download the slides from here and please feel free to use the Google Group if you want to continue the discussions from last night. We hope to see you next month.

London User Group - Tuesday 4th September 2007

Wed, 15 Aug 2007 13:07:00 GMT

Here are the details of the first Coding the Architecture London User Group.

Title : The Implications of Architecting a Tactical Solution
Summary : The topic for this, the first Coding the Architecture London User Group meeting, is tactical solutions. We've all come across tactical solutions, but what exactly are they and how do you go about architecting them?

In this session, Simon Brown will present his experiences of architecting tactical solutions, including a look at how to take advantage of the fact that such solutions typically require a fast delivery and have a limited lifespan. Simon will also be talking about what happens when you get it wrong.
Date : Tuesday, 4th September 2007
Time : 18:30-20:00
Location : Skills Matter, 1 Sekforde Street
Format : Presentation followed by a breakout for discussion, with further discussion in a local pub (The Crown).

Please sign-up on the Skills Matter website.

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.

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.