It’s easy to get caught up in unrealistic notions that you can re-write a legacy system or gradually decompose it. There are other, more pragmatic approaches that can help to modernise architectures and enable new development.

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.

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.

REST is sometimes described as the next “evolutionary step” in service integration. The problem is that REST provides too much of a “dumb pipe” to support genuinely decoupled, fault-tolerant service integration.

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.

When developers first start using messaging they can be tempted to use it as a brand new hammer for every nail. Messaging brings a lot to the party, but it isn’t necessarily a suitable transport for fast, synchronous query processing.

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.

Developers who have been brought up on the certainties of ACID transactions often have a problem trusting eventual consistency. Once you start exploring the requirements in more depth this really so much of a handicap.

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.

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.

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.

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.

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.

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.

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?

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.

About me

I am a London-based technical architect who has spent more than twenty years leading development across start-ups, digital agencies, software houses and corporates.
Over the years I have built a lot of stuff including web sites and services, multi-screen applications, systems integrations and middleware.

My current focus is on enabling scalable SaaS delivery and providing architectural leadership in agile environments.
I currently work as Chief Architect for Wolters Kluwer UK leading them to cloud heaven, one service at a time. Opinions are my own and not the views of my employer, etc.

Recent

There does seem to be growing confusion over what Service Fabric is really for. Is it an orchestrator for microservices? A means of lifting and shifting legacy applications into the cloud? An application development framework?

Azure Functions only provides direct support for a narrow range of authentication providers. If you want to use an external token provider or custom solution, you’ll have to create the plumbing yourself.

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.

There is a growing sense of unease around how larger organisations have implemented agile. In particular, there is a tendency towards centralised control that can be at odds with the agile preference for individuals over process.