Software is becoming easier to write than to understand
Coding tools can make software a lot cheaper to produce, but software engineering has never been constrained by typing code. The bottleneck is understanding, ownership, and design.
Recent content on Ben Morris. Agile enterprise architecture.
Coding tools can make software a lot cheaper to produce, but software engineering has never been constrained by typing code. The bottleneck is understanding, ownership, and design.
Large language models have become conflated with their delivery platforms - and this is setting some unreasonable expectations for what AI can do.
Engineers often implement OAuth 2.0 in the mistaken belief that they can identify their users from access tokens.
Far from being a ‘SaaS killer’, AI has the potential to breathe new life into established SaaS platforms and transform the way users engage with them.
LLMs are great for automating technical tasks, though using them to generate content may undermine authentic communication and knowledge sharing.
Agents are among the most IO bound applications you are likely to build, while conversational, ‘chat’-style interfaces bring extra constraints into play.
‘Architecture’ is such a wide term that it can be difficult to nail down exactly what architects should focus on…
Change in your API contracts is inevitable, but trying to manage this change through versioning usually creates more problems than it solves.
Every organisation tends to organise technology decision making differently, but some of the problems associated with architecture can be remarkably consistent…
Knowing what decisions to make and when to make them can be something of a fine art
Despite growing excitement about the potential for AI-driven agents, there are a lot of problems to solve before we can build agent-based architectures on any scale…
There is a spectrum of different styles of architecture governance, from the tightly structured and framework-driven, through to the deliberate absence of formal architecture.
The demise of software engineers is one of those tired old tropes that refuses to die. Perhaps the programming revolution has already happened…?
Evolutionary design and iterative development only get you so far - you still need some level of up-front thinking and forward planning.
How should you go about building an architecture practice in organisations where people are allowed to say “no”? Ultimately, this becomes an exercise in persuasion, pragmatism, and patience.
Most internal shared libraries are based on the fallacy that code sharing always makes development more efficient.
We need a more nuanced understanding of how to get the best out of monoliths, microservices, and serverless architectures.
We all agree that engineering enablement is important, but “platform teams” can often be a fig leaf for organisational anti-patterns and overly complex Kubernetes implementations.
Agile practices on their own are no guarantee of fast flow. You also need a planned architecture that enables team autonomy and supports rapid, iterative delivery.
The potential benefits of an architecture based on serverless functions are nuanced, making it a good fit only for some very specific use cases.