The Problem with Software Architecture
My thoughts on what's wrong with software architecture
Alex Hudson wrote a good blog post about the problems he sees with software architecture yesterday, and although I frowned a bit when he described CQRS and Event Sourcing as problems (they are very useful/powerful patterns, but like any pattern, don’t apply everywhere), I agree with the core of what he’s saying. In fact, I’ve been thinking about writing a similar blog post for months now, so let’s take this opportunity to share what I think is the problem with software architecture.
There are too many architects
In many enterprises, especially the larger ones, it’s often baffling to see how many architects, and how many types of architects there are. You have enterprise architects, business architects, solution architects, functional architects, technical architects, application architects, information architects, security architects, even front-end architects, and so on. With all these different roles, it’s impossible and indeed encouraged that no one has a clear view of what’s happening. There is no ownership of the architecture. In my opinion, there should be only one type of architect.
Architects are involved too late in the process
When you’re thinking about building a house, who’s the first person you talk to? An architect. When an enterprise thinks about building software, the architect is often one of the last people to be involved, right before the development team. The solution is often already there, and all the 'solution' architect has to do is take care of the technical details. This rarely ends well. A software architect should be involved from the very beginning of a project, and at every step. When this is the case, the first thing a solution architect should do is look at the problem, and try to find the root of the problem. Only then can the architect help determine if building software is the way to go, and what exactly should be built.
There aren’t enough architects
Like I mentioned in the previous paragraph, a real architect looks at the requirements first, together with the constraints. Then she should investigate the non-functional requirements (or quality attributes), and only then think about a solution. This solution should be based on the technical expertise the architect has, and the design of the solution should already involve the development team, especially if the architect’s technical knowledge is insufficient.
Many architects you find in enterprises are really developers at heart, who only care about the impressiveness of the technological solution they can come up with, and don’t want to be bothered with requirements or constraints. I have a rule that if you’re proud of your technical design, there’s a good chance you’ve over-engineered it. Why do developers like that even want to be architects? Because of the paycheck of course. Development roles are usually underrated and underpaid, forcing a good developer to become an architect, even if he doesn’t want to. An architect like that comes with a solution, and if he’s lucky, it will fit the problem.
I saw a product some time ago that had taken a team of almost 20 developers 6 months to build. Every modern technology imaginable was used. It was cloud-based, multi-cloud deployable, fully scalable, split up in microservices, it had a fancy Single Page Application, a mobile app, etc. And there were 2 architects involved. The first question I asked was what problem it was supposed to solve. Apparently I was the first person to ever ask that question, and the answer was that maybe 20 people would use it, in 2 or 3 locations, and it was supposed to replace an Excel sheet. That’s the best example of the value of a good software architect I have ever seen. Avoiding 10 man-years of development work by asking the right question.
So what should we do? We should appreciate the value of a good architect, and involve that person from the very beginning of the project. They are quite hard to find, because they must be very good developers to begin with but they should look at the business and quality attribute requirements and the constraints before diving into the technical details. The best solutions are usually the technically most boring ones.