Favourite posts

March 23rd, 2019

Why SAFe can be agile kryptonite

The problem with SAFe is that you can implement it without writing a single unit test or automating a single build…”scaled agile” may be an oxymoron.

February 24th, 2019

Should teams choose their own languages and tools?

Standardisation does have a place, but it should be reserved for infrastructure and collaboration rather than languages and tools.

January 6th, 2019

Finding service boundaries: more than just the bounded context

When you are identifying service boundaries, it’s not enough to consider the domain model alone. There are other, more pragmatic concerns to bear in mind.

November 27th, 2018

Writing ArchUnit style tests for .Net and C# to enforce architecture rules

ArchUnit is a java library that provides a fluent API for creating self-testing architectures via unit tests. A similar library can be written for .Net Standard that acts on compiled assemblies rather than raw code.

October 12th, 2018

Messaging anti-patterns in event-driven architecture

Event-driven integration can improve the scalability, resilience and scalability of distributed applications… but this does depend on the design of your event messages…

August 12th, 2018

Building Twelve Factor Apps with .Net Core

Twelve factor apps provide a methodology for building apps that are optimised for modern cloud environments. It’s only been achievable in the Microsoft world since the advent of .Net Core.

February 16th, 2018

Relax. There’s no conflict between architecture and agile.

Agile teams still need to make architecture decisions, but in supporting them architects should seek “just enough” architecture over “big design up front” and practical solutions over large-scale abstract thinking.

November 18th, 2017

Technical debt is an overused and lazy metaphor

Technical debt may be a useful metaphor for describing how bad code design undermines productivity to non-technical audiences, but it does not help in understanding the longer term problems that affect code bases.

January 28th, 2017

Why agile software architects should write code

No architect will ever admit to being out of touch with software development. However, unless you are writing code then it’s difficult to avoid becoming an “ivory tower” or “PowerPoint” architect that can only discuss systems in the abstract.

January 7th, 2017

Event stores and event sourcing: some practical disadvantages and problems

Event stores and event sourcing are a powerful idea, but they can be vulnerable to a number of technical and operational challenges when faced with real world complexity.

July 29th, 2016

Designing an event store for scalable event sourcing

Event sourcing can scale very nicely, though this does depend on a number of key design decisions for the underlying event store.

March 9th, 2015

How big is a microservice?

We know that micro services are small and focused by design – just how small is this in practice?

November 22nd, 2014

The RESTafarian flame wars – common disagreements over REST API design

Debates on the finer points of REST can bring out the worst in people as they seek to define what is and is not “RESTful”. In most cases the debate is unlikely to make the difference between success and failure for an API.

July 9th, 2014

The problem with tiered or layered architecture

An architecture based on tiers or layers is too inflexible to deal with the more flexible demands of modern systems, particularly when you working with high-volume systems that require distributed processing.

April 21st, 2014

Hackable URIs may look nice, but they don’t have much to do with REST and HATEOAS

Structured and “Hackable” URIs are a staple part of SEO-friendly websites. Although developers generically expect to see them in HTTP-based APIs, they should be irrelevant to consumers of a fully RESTful API that leverages HATEOAS.

March 12th, 2014

What role do architects have in agile development?

Agile principals encourage self-organising teams to take ownership of solutions. This doesn’t leave architects out in the cold, but it does require a more engaged role based on influence rather than governance.

February 21st, 2014

Lean development’s “last responsible moment” should address uncertainty, not justify procrastination

Deferring decisions to the “last responsible moment” can help you to adapt to the inevitable uncertainty that comes with agile development. The risk is that it can become an excuse for uncertainty that undermines development velocity.

January 13th, 2014

Identifying the sources of system coupling in service orientated architectures

Every system has some level of coupling. After all, systems need to collaborate and in doing so they will inevitably share some characteristics of language and behaviour. It’s important to recognise where coupling occurs and the impact it has on stability and flexibility.

February 22nd, 2013

A shared database is still an anti-pattern, no matter what the justification

Shared databases risk turning into performance bottlenecks that encourage close-coupling and create a single point of failure. There’s no justification for using them to integrate processes and applications.

July 2nd, 2012

How not to use dependency injection: service locators and injection mania.

Development teams can struggle with dependency injection, often because they don’t have a clear understanding of how best to use it.

April 30th, 2012

Why refactoring code is almost always better than rewriting it

Developers and architects like to build things, so their initial impulse is often to flatten the place, lay some stronger foundations and build something impressive. It can be difficult to get them excited about incremental innovation, even when this is generally the most sensible approach from both a technical and commercial perspective.

April 11th, 2012

The code reuse myth: why internal software reuse initiatives tend to fail

Despite all the best intentions, software reuse tends to be confined to third party frameworks and tools rather than being an integral part of the development process. Are we expecting too much from software reuse and should we learn to set our sights a little lower?

December 29th, 2011

10 myths about Quality Assurance in software development

Everybody would agree that quality is an important part of the software development process. However, the complexity involved in delivering quality is often poorly understood and the amount of effort it requires tends to be underestimated.