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 Architect
Quite recently I've shared my personal interpretation of "seniority" in tech (based on the concept of "leverage" - shamelessly stolen from Andy Grove ...). This term ("seniority") is frequently closely associated (as an enabler) to the role of an "architect" - which is another topic I use to share my thoughts about from time to time. So far I've been depicting an architect as: a navigatora technical product ownera person accountable for 1 of 3 pillars in the concept of "triumvirate of power"But there's one more personal lesson about what does it mean to be an architect that I find…
I tend to observe interesting trend, appearing one and then here and there - people overuse the words "architect" and "architecture" when they speak about software: every diagram is "an architecture blueprint" every design document is "an architecture overview" every analyst who creates a high-level design document is a "solution architect" It looks like every word that starts with "arch-" makes the entity named more serious and professional ;) Noblesse oblige ;> So, what does make an architect? When can someone call him an architect? What’s the difference between a design and system architecture, between a developer and an architect?…