Coding the Architecture - architecture tag

How much architecture is enough?

Mon, 08 Sep 2008 16:01:00 GMT

Thanks to everybody that came along to our "in *our* brains" session last week where we tried to answer the question of how much architecture is enough. The event was part of Skills Matter's London Agile Month and it was a great turnout where we had some interesting disucssion ranging from what agile is all about through to how architecture tasks should be tackled during an agile project.

The set of slides that I used to set the scene can be downloaded from here (PDF, 0.9MB) and the video from the session can be watched from here (this includes the presentation and the discussion). Also, Alberto Brandolini has a really good blog entry, which covers the session along with some of his own thoughts that followed. See you next month!

Discussion from the May 2008 user group

Sat, 30 Aug 2008 06:57:27 GMT

Although this happened a few months ago, we recorded the discussion that followed our London user group where Moudud Ahmed talked about building a high volume, low latency system in Java. Here are some of the topics that we talked about.

Performance and scalability.
Measuring latency.
Domain-driven design.
BEA's real-time Java platform.
Writing applications with large heap sizes that can survive not doing garbage collection during the working day.

The audio levels are very low on the recording, but we think that the interesting discussion was worth rescuing and publishing. You can grab the discussion from here (mp3 format) ... just don't listen on a tube train! If you missed the user group, a streaming video of the presentation is also available.

Mind the gap

Fri, 02 May 2008 10:58:03 GMT

Our industry has a love/hate relationship with the software architect role, with many organisations dismissing it because of their negative experiences of architects that dictate from "ivory towers" and aren't engaged with the actual task of building working software. This reputation is damaging the IT industry and inhibiting project success. Things need to change. This essay looks at the gap between software developers and software architects, offering some suggestions on how to reduce this gap and ensure projects are driven to a successful conclusion.

Read the full essay in our book.

What is architecture?

Fri, 02 May 2008 10:53:54 GMT

Architecture is a widely-used term within software development yet is very hard to define rigorously. Indeed, it changes meaning from domain to domain, company to company, project to project and even from employee to employee.

Read the full essay in our book.

Software Architecture Document Guidelines

Tue, 18 Mar 2008 15:36:00 GMT

Update, 27th October 2009: Please see Software architecture document guidelines for an updated version of the guidelines.

Regardless of the development process that you use, a description of the software architecture can be essential for any project, big or small. If software architecture is about the structure of a system and is the vehicle for satisfying the requirements, then the software architecture document is a written description of this. My simplified view of the content included in a software architecture document is :

An outline description of the software architecture, including major software components and their interactions.
A common understanding of the architectural principles used during design and implementation.
A description of the hardware and software platforms on which the system is built and deployed.
Explicit justification of how the architecture meets the non-functional requirements.

During our tutorial last week at QCon, we asked attendees to define the software architecture for a small software system and provided a handout containing some guidelines. Since this may prove useful for other people, we're making Software Architecture Document Guidelines v0.1 available for download.

It's worth remembering that the software architecture doesn't have to be a huge weighty tome and it doesn't even need to be a traditional Word document. What's important is that you capture the important architectural decisions and principles. This set of guidelines includes suggestions for what you might want to include. Just as a final note, this set of guidelines is a work in progress and we'll be iterating it over the coming months. Any feedback is welcome.

London User Group - March 2008

Thu, 21 Feb 2008 20:20:00 GMT

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

Title : An architecture case study
Summary : This session will present a case study of a small tactical software system, which was deployed into production in just two months from the initial requirements capture. We'll be looking at various aspects of the project including; the business problem, the possible solutions, the chosen architecture, how that architecture was implemented and how the system was transitioned into production.

As usual, the format will be part presentation and part discussion. This is an opportunity to look at the architecture behind a software system that was successfully delivered into production, and to gain insight into the architecture and design decisions that were made along the way.
Speakers : Simon Brown and Sergio Annecchiarico
Date : Tuesday, 4th March 2008
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 register on the Skills Matter website.

Architectural Assumptions

Mon, 24 Dec 2007 12:44:59 GMT

Most of the systems I've worked on in the recent past have been latency rather than throughput orientated. However my current project is definitely throughput focused and scales horizontally rather than vertically (this is a simplification but basically correct).

This has lead to me making a few errors based on my incorrect assumptions. As you may have read I've been retrofitting performance metrics, we're trying to discover the level of overhead compared to 'real' work, so I've been running a single node on my machine to determine the outputs required for statistics. I wanted to write the results to a database and the DBA asked me to produce an estimate of the load in production before he would create my table structures. Cursing the formality of DBAs, I made some calculations based on the number of tasks and the metrics for each. The number I came up with was huge and the DBA almost coughed up his breakfast.

I was surprised by the number because I had failed to realise that my local test was NOT representative of the real system. If the application was vertically scaled then the quantity of metrics in production would be (roughly) the same as on my desktop PC but this application runs across hundreds of grid machines and each one would output these metrics.

I had just designed a distributed denial of service attack on our own database server. The solution was quite simple - I got the machines that aggregate the outputs to also aggregate the performance metrics. This reduced the load by a couple of orders of magnitude.

I think this is a good example of what happens when you fail to take into account the architecture of a system when writing code. All developers need to be aware of the architecure and how it effects the code they are writing. Does anyone else have similar experiences?

What about the application tier?!

Mon, 24 Sep 2007 15:05:32 GMT

I've recently become involved in a project with a very clear idea of its functional and data requirements - so much so that the presentation technology has been selected and the database vendor and schema determined. The suppliers of these have also been chosen and brought in. So, you've got your data, you've got your user interface, all you've got to do is connect the two.

At first glance the omission of an application tier is just an oversight; the majority of functions can be delegated to the database: little more than a bit of remoting and a bit of transformation. On closer inspection it becomes evident that the hole between the presentation and the data is more than just technical. In fact, it's a dumping ground for all the requirements that didn't fit neatly into either of the other two. It's the region in which misaligned assumptions are going to be magically ironed out. For example, the presentation tier assumes (or at least prefers) synchronous calls whereas the database would be better addressed asynchronously. Sure the app tier could hide the asynchronous nature of the database call from the presentation tier but that's simply patching over the hole.

In reality, the omission of the application tier is a clear sign that the exciting technology choices have led to a project starting without a clear system architecture. It sounds to me like another case of trying to introduce architecture during implementation.

I'm not sure you can architect and implement at the same time - there are always some aspects of the architecture such as technology, team and methodology selection that need prior thought.

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.

Is Enterprise Architecture the next step?

Fri, 18 May 2007 10:28:13 GMT

Following on from Role titles across the world, I wanted to present a diagram that I've had in my head for a little while but never got around to putting on paper. I think architecture at the application and system level is pretty well defined, with an easily identifiable progression path from the former to the latter. Enterprise architecture, on the other hand, is different and I was always under the impression that this was the next logical step for somebody performing a system architecture role. I've recently changed my mind on this and my new view of the world is as follows.

I now see enterprise architecture as a mix of technology and business consulting that is performed at quite a high level of abstraction, across organisations or organisational units. Previously, I hadn't really made the connection that the business and process side of enterprise erchitecture was as important (perhaps more so?) than the technology side. As usual, Wikipedia has a nice entry on Enterprise Architecture if you want to read more about this as a discipline.

So is enterprise architecture the next logical step for somebody doing a system architecture role? Possibly, but it depends on what you want to do. When you include the business consulting aspects in the enterprise architecture mix, you start to see that the skillset required for enterprise architecture differs from both the individual streams that feed it. While I'm unsure whether enterprise architecture is more business consulting or more technical architecture, I *am* sure that it might not be the logical progression for technical architects who (like myself at the moment) want to remain technical. Less of a direct upwards career progression and more of an upwards and over movement with which you might have to give up coding. This, of course, raises an interesting question of what *is* next for System Architects that want to remain technical. What are your thoughts?