Coding the Architecture

Ikke så smidig prosjektmetode, likevel?

While with Bouvet, in addition to the digi.no interview, Simen Sommerfeldt and I were interviewed by Teknisk Ukeblad about how agile isn't a substitute for basic software engineering, architecture and craftsmanship.

Read Ikke så smidig prosjektmetode, likevel?...

Smidig må kombineres med arkitektur

I spent a fantastic few days with Bouvet in Oslo towards the end of last year where talked about software architecture with some of the team, customers and press. For the Norwegian speakers that haven't seen it, Simen Sommerfeldt and I were interviewed by digi.no about software architecture, agile and "just enough".

Read Smidig må kombineres med arkitektur...

Contextualising just enough up front design

In our move away from the waterfall way of building software, it's common for software teams to ask how much up front design they should be doing. Just enough is a good starting point but what exactly does that mean?

Features vs Behaviour

I've recently had a bug I raised with a third party software supplier downgraded from high to low importance. No one likes having their bugs downgraded (it probably shows you what a nerd I am by taking this personally) but what surprised me was the reason. The bug was causing lots of misleading errors to be reported but the bug was deemed to not affect core 'functionality' as the feature worked from an end user's perspective. However it has a negative effect on our ability to operate the software system.

This seems to be one of the big differences between software developers and software architects. Software developers/programmers think in terms of features and a feature tends to be defined in terms of cause and effect e.g. a user clicks on a button and the system responds. A defect or bug is simply when the system does not give the response as defined by the specification.

An architect should consider the holistic behaviour. Not only thinking about a resultant action but the complete behaviour and life-cycle of the action. From simple (and measurable) items like timings (latency, response etc) to more complex system behaviour such as auditing, logging, replication etc.

Most software development processes revolve around features. Therefore when a bug is raised it HAS to be registered against a feature. This is then passed to a developer who either rejects it as 'working' or downgrades it as not being core or having a 'work around'. However the work around might be unacceptable such as waiting longer, bad logging/auditing or a side effect on a completely different part of the system.

In my experience it is rare for a development process to consider system or architecture issues.

Does your software development process allow you to raise and track non-functional issues and how do you do this? Do tools (such a JIRA) help or hinder with this? These issues will cut across many features - should they be raised against a set of features or have a single bucket that they get put in? Most importantly, how can I get my bug upgraded when they have a feature based bug reporting process?!

As a side note it appears to me that Simon Brown's and Robert Martin's debate is partially about the differential between product features and system behaviour.

RE: Clean Architecture

Clean Architecture is a follow-up post by Uncle Bob to much of the recent commentary on Clean Code Episode VII - Architecture, Use Cases, and High Level Design, including my own post called The delivery mechanism is an annoying detail. I'll keep this short because I only want to pick up on a couple of points. Uncle Bob says...

In the weeks since I started talking about the need to clean up our architecture, I’ve noticed a surprising resistance to the idea. Apparently the notion that it’s a good idea to hide the framework, UI, or database from the application code is not universally accepted.

I'm 100% behind the idea of keeping architectures clean and (as far as possible) decoupling the application code from the technology choices. I even mention "Boundary, Controller, Entity" in my The Frustrated Architect talk (video available) as a good way to decouple. I mean, why would you want to start a web server or database just to run some unit tests? That's crazy.

One somewhat dissenting view, written by The Frustrated Architect in his coding {the} architecture blog is here. He shows a picture, which I’ll repeat:

... see picture below ...

The point he’s trying to make is that if the UI and Database are a much larger part of the system than the business rules, then the architecture of the system should be more oriented around those larger elements. Of course I disagree. No matter how large any one part of the system is, the other parts should be decoupled from it.

No, that's not the point I'm trying to make. I'm saying the delivery mechanism is NOT an annoying detail that can be deferred or ignored "right off the end of the world". I'm going to quote myself here from The delivery mechanism is an annoying detail...

That's right, the annoying detail is actually a large chunk of the system and, for me, architecture is about more than just what's contained within "the application". Structure is very important, but what about that tricky stuff like non-functional requirements, the actual delivery mechanism (technologies, frameworks, tools, APIs, etc), infrastructure services (e.g. logging, exception handling, configuration, etc), integration services (internal and external), satisfying any environmental constraints (e.g. operations and support), etc. For me, this is what "architecture" is all about and *that's* "the whole enchilada".

I consider the role of the software architect to be about looking after the big picture and the type of decoupling that Uncle Bob talks about is exactly the sort of architectural principle that I would adopt on my projects. However, in this role as a software architect, I'd be foolish to ignore the other major factors that may cause my project to fail. This includes, but is not limited to, all of the stuff that I quote above (tricky non-functional requirements, etc). A good software architecture is not just about clean code.

The executive summary

Again, to recap in case I'm not being clear...

Decoupling application code from technology is good and certainly something we should all strive for. The result is code that is easy to unit test, easy to substitute, easy to maintain, easy to change, etc.
Software architecture is about the big picture and application code is only one part of that big picture.
You run the risk of your software project failing if you continually defer significant decisions about the "delivery mechanism" and don't consider how to address your significant non-functional requirements and/or constraints.

To summarise points 2 and 3 ... the delivery mechanism is not an annoying detail. Now, please go back and read Clean Architecture from the "Not Rocket Science" section because there's some really good advice in there. :-)

The Frustrated Architect - video and slides

A really short note to say that the video and slides from my "The Frustrated Architect" talk at Skills Matter yesterday evening are now all available online. Here are the links...

Abstract and slides (online view and downloadable PDF)

Video

I really enjoyed presenting this session but the discussion afterwards in the pub was fantastic. Seems like others are running into similar problems on some of their projects, so maybe the advice I give in the talk will be of use to you too. :-)

The delivery mechanism is an annoying detail

In my The Frustrated Architect presentation at GOTO Aarhus in October^*, I talked about how there are a number of "classic" software design techniques from the pre-agile era that are being used less and less. For example, things like UML, class-responsibility-collaboration cards and component-based design. This is a shame because some of these techniques can complement an agile way of working and would perhaps prevent some wheels from being reinvented. If people don't know about these techniques though, how will they adopt them? I'll come back to this shortly but, first, I was intrigued by this tweet from Uncle Bob a few weeks back.

I don't necessarily disagree with this statement, although I like to see a software architecture grounded in reality, and that includes technology choices. Another tweet from Uncle Bob...

Again ... maybe, maybe not. Surely if there are some key technology choices that need to be made, then they should be made, right? Finally, another tweet...

Hmmm, if I don't or can't defer decisions, does this mean that I have a bad architecture? Shouldn't deferral be a conscious decision rather than a rule? All of this and the discussion that followed on Twitter intrigued me enough to stump up the cash for Clean Code Episode VII - Architecture, Use Cases, and High Level Design to see what Uncle Bob's perspective on architecture is.

Clean Code Episode VII - Architecture, Use Cases, and High Level Design

Now that I've watched it, what do I think? Well I'm really pleased to see coverage of a couple of things. The first is describing functionality through delivery mechanism independent use cases, where there is no discussion of web pages, screens, buttons, technology, etc. And the second is the follow-up technique where you decompose a use case down into a number of different classes, each of which has a distinct responsibility. These are entities (e.g. business objects), controllers (also known as interactors, which represent the actual flow of control described in the use cases) and boundaries (which represent an interaction with an actor through the "delivery mechanism"). What these techniques basically do is allow you to describe and implement a use case in a way that is completely independent from the way that the use case will be delivered. In effect, you can bolt-on a number of different delivery mechanisms (e.g. a web or console app) without changing the actual core of "the application", which is ultimately the functionality that is being described by the use cases. As I said at the start of this post, these are the sort of techniques that many people don't know about, so I'm really pleased to see them being communicated here.

I'm in agreement then?

Coming back to Uncle Bob's tweets, I can now see his perspective. Adopting this approach does allow you to defer technology decisions and from the perspective of the use cases, this technology stuff is really just an "annoying detail".

I agree that the boundary-controller-entity technique is a great way to design software because the result is a really nice separation of concerns, which ultimately leads to something that can be easily unit tested and extended in the future. This is all about partitioning and isolation. OK, so I'm agreeing with Uncle Bob then? Hmm, not quite.

"Architecture"

Throughout the video, Uncle Bob says the following (which I've paraphrased).

The architecture of an accounting app should scream accounting. A web and console version of the same accounting app should have identical architectures. The web delivery mechanism is a detail.

This is repeated a number of times through the video and it's based upon all of the good stuff that I've talked about above. However, I find myself in strong disagreement with the message as a whole. And here's why ... because the word "architecture" is being used. At face value this might sound pedantic but let's consider for a moment what Uncle Bob is actually talking about by redrawing the above diagram. Let's imagine that you're building an accounting app that you want to deliver over the web. Security is important so let's break it into multiple physical tiers. And we need to store all of the accounting data somewhere, so let's use a database. How does that annoying detail look now then...

That's right, the annoying detail is actually a large chunk of the system and, for me, architecture is about more than just what's contained within "the application". Structure is very important, but what about that tricky stuff like non-functional requirements, the actual delivery mechanism (technologies, frameworks, tools, APIs, etc), infrastructure services (e.g. logging, exception handling, configuration, etc), integration services (internal and external), satisfying any environmental constraints (e.g. operations and support), etc. For me, this is what "architecture" is all about and *that's* "the whole enchilada".

^*I'll be presenting The Frustrated Architect at Skills Matter in London on the 15th of November and you can sign-up for free

Update

If you don't have the video but want to get a feel for Uncle Bob's approach to architecture, take a look at the following links...

Architecture Deference (<2 minute video)
Screaming Architecture

GOTO Aarhus 2011 and Software Architect 2011

Conference season is again upon us and I'm speaking at two events over the next couple of weeks.

GOTO Aarhus 2011

I'm presenting a session at the GOTO conference in Aarhus, Denmark called The Frustrated Architect that will look at the role of the software architect in today's world of modern software development. I'll be focussing on perceptions of the role, how agile has positively and negatively affected software architecture, some of my pet peeves with people that call themselves "software architects" as well as my own frustrations with the role. To end on a high note, we'll finish off by looking at how you can undertake the role in a lightweight and effective way. There's some other stuff in there too but you'll have to wait for that. ;-)

Software Architect 2011

The week after I'll be in London for the Software Architect conference where I'll be presenting two one-day workshops ("Software architecture in a day" and "Just enough up front design") and three 90 minute breakout sessions ("Effective sketches", "Software Project SOS" and "How much is just enough?"). All of these follow the same theme in looking at how software architecture fits into the new shiny agile world that we now live in.

Evernote slide packs will be available for all of these sessions and I'll post the URLs (here and on Twitter) 1-2 days before each session. Should be an excellent couple of weeks.

Is caching an 'Architectural Smell'?

Kent Beck introduced the concept of "Code Smells" while working on Martin Fowler's famous Refactoring book and I think that most people would agree with many of the stinks he identified. Many of us probably also use tools such as checkstyle to automatically identify such things as excessively long methods, dead code etc. To those not familiar with the concept please have a quick read from the link above but the basic premise is that

A code smell is a surface indication that usually corresponds to a deeper problem in the system.

Though we have to remember that just because some code has a 'smell' doesn't mean it's bad, just that it's worth investigation and justification.

We can take the concept to the next layer of abstraction and identify a number of "Architectural Smells". A recent blog article touched upon one of mine - the (over) use of Caches.

I've had terrible trouble with caches in the past. They can introduce bugs which are difficult to reproduce as they rely upon operation timing to be visible. They are similar to bugs you find in concurrent systems, where the issue only occurs every few thousand operations and aren't present when you attach a debugger or logging. Like all performance tuning a cache should be introduced AFTER you have determined that there is an problem. However they can be added so easily that developers throw them in whenever they can. Of course if your cache hit is low then your performance can actually degrade after adding a cache.

Maybe you agree or not with the above (and I know I'll be flamed for saying it) but why do I consider caches to be an Architectural Smell?

In a perfect system the business logic will always have access to the data it needs. The access (local or remote) will fit comfortably into the non-functional requirements and the data it uses will be from the primary source/system of record and not be stale.

Back in the real world the system is not used in the way it was originally designed for, by many more users than anticipated and they can't wait for anything.

The temptation is to introduce a cache at each layer there is an issue. They can be very easy to introduce (Spring will allow you to do this with a couple of lines of configuration for your data access components) and the user's perception of response can increase dramatically. Is it a free lunch? If you look closely at the options available with caching systems you'll see all sorts that you might associate with databases - which is not surprising as they are really a mini database. Have you considered data staleness, dirty reads, dirty writes, update schedules? Will all clients of the data see the same data at the same time? Can updates be missed? Does it listen for updates or poll? Is data coalesced, grouped or skipped? Depending on the use of the data you might answer these questions and decide that caching is an effective and accurate solution - great! If it's not then the cache will introduce the kind of bugs I described.

Either way it is still an Architectural Smell. Perhaps the best solution is to re-examine how data is distributed and accessed throughout the system. For example:

Maybe a monolithic database sitting at the center of the system isn't the best solution and perhaps you need multiple database with different responsibilities? (Issues with monolithic, remote databases are a common reason for needing caches).
Maybe an asynchronous messaging system with multiple messages being processed would work better than a single request/response system?
Perhaps data associated with a request should be sent through the system with the request itself (enriched request).
Should some data (e.g. static) be explicitly kept locally rather than requested and cached?
Should some data have its encoding changed? Moving from/to xml is very time consuming.
Can data be request in larger or smaller blocks to reduce overheads? Calling a database in a loop is a common problem.

I appreciate that this will involve a lot more work than a few lines of configuration but may help architectures to evolve logically rather than become a series of hacks and bolt ons. Introducing a cache is an architectural decision and not a coding one.

What are your favourite Architectural Smells we should all look for? I've already mentioned another of mine - "XML everywhere".

Jitter

On CTA we often talk about non-functional requirements and how this can drive the architecture of a system. Most of these cover issues of desired response time and capacity (latency, throughput, storage etc) but I believe that Jitter is a metric which is either forgotten or unknown to some software engineers – even though it's essential for hardware engineers.

The most basic definition would be “variation in response”. In other words, the response, transmission or latency in a system will not be a constant. In many systems this variation goes unnoticed as it is small compared to the response itself. However I believe that as the systems we deal with become more performant and demanding, software engineers will need to understand, measure and tune this.

A quick web-search of jitter shows the term being used to cover performance degradations due to activities such as garbage collection or unexpected user actions. This seems to greatly annoy telecommunications and hardware engineers who would argue that these are predictable, system and user events which could just be turned off – although ignoring your users and asking for a machine with infinite memory may get you fired. They would argue that true Jitter is an unpredictable variation in response whose occurrence frequency follows a normal distribution. Like most effects that are normally distributed it is caused by cumulative random events, most of which are due to the switching actions. Personally, I think you should measure whatever makes sense in your system.

Jitter means that hard limits for latency can be statistically likely but not guaranteed. Specifications such as:

“The system should respond to action X within 200ms”.

Should be challenged and replaced with statements like:

“The systems should response to action X within 200ms for 95% of requests”

Of course we are making the implicit assumption that this is normally distributed and the system WILL, eventually, respond. You might want to explicitly state that all actions will be executed but stating a hard limit for all responses means that if you measure for long enough, you'll break your specification.

Jitter can be quite obvious on messaging based systems that contain many hops. This will also tend to have a nice, Gaussian distribution due to the cumulative random delays.

The best way to measure Jitter is to set up a standard test where you can sequentially fire a large number of requests into your system and measure the response time. However, rather than simply add these up and find an average we need to count how many responses are in a set of timing windows e.g. how many responses fall between 5ms-10ms, 10ms-15ms, 15ms-20ms etc. If we plot the number in each section we should see our expected Normal distribution.

Reducing Jitter is subtly different from reducing latency itself. You are trying to reduce the variation in the response times or 'squeeze' the response profile.

Often when you reduce latency you will reduce the Jitter proportionally however this is not always the case. For example, network hops are a common cause of latency but each hop will increase the Jitter as well – you are accumulating more random delays with each hop. If you change the physical architecture of your system to have more but quicker hops you will almost certainly increase the jitter (remember this is the variation in response and not the actual response) even if the average latency is lower. It IS important to measure it and monitor as the system evolves.

Simon is covering a number of related issues in his Skills Matter tutorial Load Testing for Developers.