Why…oh…why??
Updated: Apr 11, 2020
A good way to kick start this blog is with the reasons for its existence. Why do we need a new blog about software architecture? And what do I mean with “Not Just Boxes and Lines”.
So…why do we need yet another website/blog?
I wanted to share my approach on architecture, that is, the view that it should be as “hands-on” as possible and that it must go beyond boxes and lines.
The reason why this is necessary is the following:
Being agile doesn’t mean don’t design… (here, check the Agile Manifesto…). Actually it implies almost the opposite! If you read the principles it clearly emphasises design and architecture:
Agile Principle 9: “Continuous attention to technical excellence and good design enhances agility.”
Agile Principle 11: “The best architectures, requirements, and designs emerge from self-organizing teams.”
I’ve worked with agile methodologies long enough to recognize the huge value they bring. However, all too often I see design being ignored for the sake of some sort of pseudo-agility. All systems/software should be designed, i.e. we need to think about what we need to build, and then build it. I’m not saying we need to design everything upfront, but we need to design. And by design, I’m not referring to create a big document of what a system should going to look like, I mean to actually design it: that is, think, reason, analyze trade-offs, … And usually, a whiteboard/piece of paper is a great way to get started.
Governance isn’t design: On the flip side of the coin, I see too often architecture being done solely as a governance exercise, a box to be “ticked”! This is as bad as the first issue. Worst than not doing something, is doing it “just because”. Not that governance doesn’t have value, but there’s value if it’s an actual design activity, otherwise mostly just a waste of time.
The Ivory Tower architects: Basically the view that the architect is just a guy that used to code, and can’t do it anymore. This is deeply wrong for me: an architect doesn’t have to code every day, doesn’t have to know every technical detail of the solution, but must have the technical skills to be able to reason about the solution. And he can’t do it in isolation, he needs to get involved with the delivery/development team.
Yada yada yada… so what is it really about?
It’s about designing and building solutions that meet the functional requirements AND the non-functional requirements AND that are actually “buildable”. It’s about the trade-offs that lead to the solution, and you’ll see examples of designs from my past or my pet projects. In a way, it’s also about software engineering, in the sense that without actually being built, it’s just nice boxes and lines…
It’s about choosing and applying design patterns (all flavours: enterprise integration patterns, architecture patterns, object-oriented design-patterns, …) AND actually building something with them. At the same time, it’s about ignoring patterns that, despite being really cool, and not actually practical or applicable. and it’s about spotting those nasty anti-patterns.
It’s against “Ivory Tower” architecture, done from “high-above” with no connection to the development. This posture ultimately results in nothing (other than a pretty diagram), or it results in a big mess which never goes “live” or when it does it’s crazy expensive. It’s against the posture of the architect who isn’t part of the team that actually delivers.
Humm…ok…so what isn’t this blog about?
Well…hopefully obvious by now, it’s not about architecture of buildings/cities or any kind of physical structures. That’s an interesting discipline, but not exactly my thing.
It’s also not about a specific technology, framework or programming language.
Also, this is not about Enterprise Architecture, that’s an interesting and important area in big companies, but not the scope of this.
Who’s it for
Plain and simple: for anyone who cares about designing good software.