There are so many myths about software architecture ... that it's done once and there's no further cost associatedthat if you do it properly, it will serve foreverthat there's "the correct way to do it" & you measure correctness with "software architecture" aestheticsThere's one more I find especially irritating: that architectural change can happen as a side effect (of feature work). That it's "free" - meaning that an architectural improvement is an "upgrade" over the original idea that doesn't require specific skills or additional effort. Ain't no "free-ride"Frankly, all the professional experience has taught me to avoid definitive statements, but…
All posts in Software Architecture
This blog post is all about: cognitive bias (one particular one), how quickly we get used to "the new normal", how being insatiable when it comes to knowledge can make us ashamed, why we get annoyed when some junior pops up with "microservices now!" idea, why leader in the trenches may help (& what does it really mean).Habit of fooling ourselvesYou've heard/read about cognitive bias, didn't you? If not, you should definitely read up - there's zillion of resources on them available on-line, e.g.: http://www.visualcapitalist.com/every-single-cognitive-bias/https://betterhumans.coach.me/cognitive-bias-cheat-sheet-55a472476b18https://rationalwiki.org/wiki/…
TL;DR Software Development technology adoption lifecycle is susceptible to the same rules that apply to any other high-tech. Market success is not guaranteed by sheer innovation, technical excellence or even product capabilities - it does require certain qualities, but also favorable market situation & adaptable product marketing (adjusted to cycle stage). In fact, vast majority of technology novelties we so adore (and already consider "The Next Big Thing") will never go beyond geek inner circles. I've recently finished one of the absolute classics among product development books: "Crossing the Chasm, 3rd Ed." by Geoffrey A.…
The idea of decomposing application into layers (logical vertical split) or tiers (physical vertical split) isn't new - it's bread'n'butter of systems architecture. Reasons for such a split are still the same (as they were in 90s, 80s & beyond): to reduce complexity & separate concerns to scale tiers independently to enable / simplify usage of different tech suited for each layer / tier etc. No-brainer, right? Good. Problem appears when you consider the boundary between layers / tiers as a boundary between separate systems / applications. Developed & maintained: by separate teams with separate backlogs, ... ... separate priorities, ... ... separate product (service) owners, etc. What…
People tend to like the shortcuts. There’s nothing really surprising about that - actually modern corporate standards favor people who are goal-oriented and "know what they want". I’m not gonna condemn this path (as I find myself a pretty ambitious and impatient individual as well …), but if as long as we’re talking about the path of technical excellence - leave all hope: there’s no easy short-cut. What do I refer to specifically? Every now and then I meet people who ask me what should they do to become a software architect.…