February 16th, 2018
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.
December 13th, 2017
Finely-grained, entity-based services seem to be advocated by some pretty authoritative sources. This is unfortunate as they are something of an anti-pattern that can undermine many of the benefits of decomposing an monolith into micoservices.
November 18th, 2017
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.
August 14th, 2017
Swagger enables the same kind of automated discovery and integration that WSDL was invented to support. In doing so it undermines the design of REST APIs and doesn’t even provide adequate documentation.
June 19th, 2017
Refactoring describes a very specific and controlled technique for improving code. The problem is that it is often used to describe wholesale changes to code bases that should be treated as a rewrite.
May 16th, 2017
No self-respecting integration platform is complete without an API management story these days. Is this just a RESTful return of the enterprise service bus?
January 28th, 2017
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.
December 19th, 2016
Test coverage statistics are much loved by management teams and code quality tools. They tend to associate a high level of coverage with robust, well-managed code bases. Wrongly, as it turns out.
October 27th, 2016
Maturity models are a management tool. When applied to technology solutions they often provide a weak analysis that describes a false progression.
September 20th, 2016
Three-lettered acronyms can be a useful tool for providing brevity, but they can also give rise to a coded language that contributes to a cold and impersonal development culture.
April 14th, 2016
In most cases “business logic” just refers to the poorly-defined “gloop” that sits between user interfaces and databases in layered architectures.
September 27th, 2015
Change in an API is inevitable. Attempting to manage this change through version numbering usually creates more problems than it solves.
August 11th, 2015
The best architecture diagrams act as a map – if an architect can’t express a system clearly and concisely then they probably don’t understand it properly.
July 25th, 2015
You might be able to identify cross-cutting concerns in a monolith, but in a service-orientated world they should melt away into specific implementations.
November 22nd, 2014
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.