Software Architecture Decisions – how to do it wrong the hard and the easy way

When it comes to software architecture, stuff gets funny. 

First we learn everything about it at university. We learn to use it as a part of our main project plan. We learn how to do risk evaluation. And, as a matter of fact, we learn how to create a lot of different UML diagrams: 

• component diagrams
• data flow diagrams 
• package diagrams
• deployment diagrams
• sequence diagrams
• state charts 
• etc … 

Ok, there are a lot of difference between a software architecture consultant of a mayor consulting company and a computer science nine-semester, like a suite, a proper haircut, an accenture assessment center, an increased income and no spare time at all. 

The experience about real life evolving software architecture is the same, nevertheless. That results in a lot of architecture meetings and several hundreds of pages of architecture documentation. As we all know, software documentation that does not fit on a whiteboard is tl;dr . So it’s rather a handful of former trees now serving CYA purposes instead of providing an actual guideline how the software is structured.  If you don’t trust me just leave a note "The finder of this line get’s a free pizza" with your mobile phone number in the footnotes of page 173 of the next architecture documentation you will create.

There is a reason why the developers don’t care about this documentation: because they are expected to provide working software. And they know that working software is something that has been proven to work by experiment, and can’t be planned in advance. 

So they deal with the architecture documentation just as long they need to prove it wrong, and can count on management support for their architecture afterwards. 

Their architecture is not going to be written down before the software is actually implemented. It’s documented when the software already works for maintenance reasons. And that’s fine, since it’s after the release when they have the time to invent good sounding reasons why they have chosen this very special architecture. The actual reasons are a different story which never will been told to you, e.g.: 

Architecture i read about in a blog

Every good software developer wants to stay up to date with the current trends in his technology domain. And what better to do than to read a blog – or literally read 10 to 20 blogs – in that area. The blog articles have, mostly, been written for marketing purposes, to sell somebody’s competence, technology or tool. Like with every other marketing the solutions provided it sounds really great, but there is a slight chance that not everything is perfectly true. Nevertheless, if the cool people say it’s cool technology there is a simple way to be cool: use it and blog about how great it is, too. Do a talk about it as long it’s fresh. 

Architectures that worked for me once

If software developers work in an environment that is unfriendly and/or CFO-driven, innovation comes second to reliable solutions, no matter how much cheaper the resulting software might be. So they start to write software that can’t go wrong. Or better. Using an architecture that has been working for the last few years. It always worked. Just like Cobol. 

Architectures that didn’t work for me once

If an architecture has the guts to prove a developer wrong by not working at all once, software developers tend to behave like an ex girlfriend. The solution is not only dumped, everybody is told how bad it was and how wrong it were. Anger and disappointment still comes up even years later when the name is mentioned. There is no chance that another try might be given, or that anybody else should work with it. 

Not invented here

"Well, there is this solution that pretty much does everything we want, probably. I am not sure, since I did not take a close look at it. It seems a bit complicated. And it actually does a lot more things than i actually think i need. I would probably spend less time just writing just the code we need. It would fit better in hour environment, for sure. And since we wrote it on our own, we already know how it works. We could write documentation like the other solution already has later, anyway. And i don’t think the original author of the first solution has had any good reason to create all the other features we currently don’t need."

Golden Hammer

The company has got a standard architecture, and it’s so good, that it’s used for everything. The development team is committed to this technology, and they know it well. They are afraid of other technology. So they established their company-wide One technology to rule them all, One technology to find them, One technology to bring them all and in the darkness bind them. 

These antipatterns sound familiar to you? Next post deals with architecture problems you don’t know yet.