Software architecture is failing

I guess you could attribute this to cargo-culting &#x2F; resume building. It sounds like the problem is with inexperienced people wanting to (and not being stopped from) using patterns&#x2F;technologies for their own sake instead of from a business-value perspective.<p>Part of this is a fault in business, for rewarding this type of behavior (better to have Kafka on my resume [even if the business justification was nonexistant] to get myself past the no-nothing recruiter), not to mention the &quot;internal resume&quot; factor of rebuilding something.

I agree with the gist of the article in the sense that these patterns (and software architecture patterns in general) are often misapplied.<p>The first two items in the list at the start of the article have come up where I work recently, in fact, with no good technical justification behind them.<p>This in particular is something I wish developers (I&#x27;ve stopped calling these folks &quot;engineers&quot;--they aren&#x27;t, and likely never will be) would read and internalize:<p>&gt; It’s important to understand why Google take decisions in the way they do. However, most of their problems don’t apply to anyone else, and therefore many of the solutions may or may not be appropriate.<p>Substitute Netflix, Amazon, Twitter, LinkedIn, or any other &quot;big name&quot; company that operates at very large scale in for &quot;Google&quot;.<p>The importance of the &quot;why&quot; resides in the ability to compare the business needs to the reasons Google (et al) did what they did: if the business need isn&#x27;t similar, it almost certainly isn&#x27;t necessary to do it &quot;the Google way&quot;.<p>The author is also right about the cause: it&#x27;s developers always chasing the newest toys. There is a reinforcement effect at work, because these same developers conduct interviews, so there&#x27;s this seemingly never ending treadmill or &quot;keeping up with the Joneses&quot; effect.

&quot;Here are three examples of people driving cars off the road into a tree&quot; → &quot;Transportation is failing&quot;<p>This isn&#x27;t software architecture, this is potential&#x2F;alleged mis-application of three very specific patterns (I am not sure I&#x27;d even call them architectural styles).

I do not understand the addiction to using the &quot;framework of the month&quot;.<p>It&#x27;s also hard to keep a straight face when someone calls themselves an engineer, but makes absurd claims like &quot;x is more productive&quot; without ever presenting proof or measuring such a quantifiable claim.<p>I probably also yell at the kids on my lawn.

You know what you can do with an immutable log? You can rewrite it. Then ditch the old version. It’s like git. You can rebase. This blog seems to confuse people being dumb or in the process of learning with bad architectural choices. Just because the person this blogger spoke to couldn’t come up with an answer, doesn’t mean ES is bad or wrong. ES is liberating.<p>Posts like this advocate a mentality that leads to people using Django or Rails for apps where these tools are not long-term good fits. It’s better, I think, if people spent a bit of their lives learning how to build architectures beyond tools like Django and Rails, because these tools are actually really limiting, not just in terms of theoretical things like scaling but practically in terms of what they can express. There’s a very common ethos that if people just focused on shipping they would somehow magically ship but that’s not how software works. You can’t just will shipping. You need to know what you’re doing. And we advocate every job be a rush job, for the sake of what? Shipping something that likely has no chance anyway?<p>This blog also talks about CQRS and ES like they’re more complicated than “traditional” approaches. But that’s only true if you don’t know how to work them. Once you learn how to have a database that’s inside out, you never want to go back. Once you use kubernetes, you never want to go back. CQRS&#x2F;ES&#x2F;kubernetes are the things I intuitively wanted since I was a kid learning how to build things. I couldn’t have explained then what made it hard, but it was the absense of these tools and approaches which make managing complexity much easier.

Sophomore developers love to use every single tool and pattern as much as possible. I am not excluding myself as I clearly remember doing this and still catch myself over engineering.<p>This is so true:<p><a href="http:&#x2F;&#x2F;www.ariel.com.au&#x2F;jokes&#x2F;The_Evolution_of_a_Programmer.html" rel="nofollow">http:&#x2F;&#x2F;www.ariel.com.au&#x2F;jokes&#x2F;The_Evolution_of_a_Programmer....</a><p>My favorite is what such devs will do with C++. I once simplified a C++ boost code base using binding, functional patterns, etc. down from dozens of files and thousands of lines to one class with less than 1000 lines of straightforward code. I am not exaggerating. Java design patterns cruft is hilarious too.<p>I think it comes from a not entirely bad drive to explore. Problem is when it goes so haywire that it causes unmaintainable bloatware that consumes hundreds of times more resources than it needs.<p>Edit: three other observations.<p>I think Golang is deliberately engineered to limit this by offering fewer language features and discouraging towers of Babel.<p>Overengineering is death in dynamic languages since without strong typing your tower of Babel becomes a bug minefield.<p>Finally wow has Amazon ever hit gold by monetising this. They offer compostable patterns as a service and market them like Java patterns were marketed.

Color me &quot;pernicious&quot;, but who has ever had a heartwarming experience with ORMs? (I&#x27;m not talking about the new breed of micro-ORMs that work very well with CQRS, but the big old monolithic frameworks).<p>CQRS is a breath of fresh air after years of dealing with ORM overreach and inflexibility.

I thought this was a really insightful portion of the article:<p>This is the problem being ahead of the curve – the definition of “success” (it works great, it’s reliable, it’s performant, we don’t need to think about it) looks a hell of a lot like the definition of “legacy”.<p>If you&#x27;re able to make the app and do it well, it&#x27;s boring.

This is so true:<p>--- start quote ---<p>I place the blame on technical leaders like myself. For those in tech who are not working at Facebook&#x2F;Google&#x2F;Amazon, we’re simply not talking enough about what systems at smaller enterprises look like. We’re not talking about what is successful, what works well, and what patterns others might like to copy.<p>A lot of technical write-ups focus on scaling, performance and large-scale systems. It’s definitely interesting to see what problems Netflix have, and how they respond to them. It’s important to understand why Google take decisions in the way they do. However, most of their problems don’t apply to anyone else, and therefore many of the solutions may or may not be appropriate.<p>--- end quote ---<p>Too many devs, and startups, and companies rush to every new thing the moment it appears on Facebook&#x27;s&#x2F;Google&#x27;s&#x2F;Netflix&#x27;s blog

I think when architechture fails, its a failure to understand the problem you&#x27;re trying to solve and the value an architecture gives you.<p>Some problems are such you don&#x27;t need audit, you don&#x27;t need to roll-back time and you don&#x27;t need multi-database coordination. Then you don&#x27;t need event sourcing.<p>CQRS is a more generic concept, but you also often don&#x27;t need it. That&#x27;s because RDBMS do CQRS for you. You can design tables in a normalized way, to maximise writes, updates and deletes guarantees and consistencies. And then you can do whatever query projection you need. All view aggregation is magically handled by the RDBMS for you. You need to manually implement CQRS when that RDBMS limits your scale or performance.

Mediocre software pervades the industry because mediocre developers are the ones writing the blog posts that get shared around. Mediocre developers are the ones who are so loud in defending their choices (and criticizing others for not making the same choices) because when you don&#x27;t completely understand something, the way to win is to be the loudest. Mediocre developers do RDD, Resume Driven Development. And businesses don&#x27;t help the matter because they don&#x27;t know that a talented developer can come up to speed on any tech that they&#x27;re using reasonably quickly so they often hire the RDD developers to &quot;fill a need&quot;.

I’ve never liked the term over-engineering. People seem to use it as an excuse for pre-mature pessimization.<p>The cost of not forward thinking about architecture is that companies and teams can wallow in a land of low productivity while they try to evolve an architecture that wasn’t thought through.<p>Obviously you need to be aware of your market - for example, an app for local real estate doesn’t have to scale to billions of users per city - but there are common patterns that will scale up well for almost all companies.

The description of the legacy == successful application sounds like that J2EE app that every company has that isn&#x27;t being patched and just may end up getting you on the front page of the WSJ once it gets breached.

I’ve been talking about the problems with tech-driven architecture for years.<p>I would simplify this entire discussion by saying…<p>“When you create distance from code to business processes, the less effective and maintainable your architecture and software development becomes.”<p>I have always argued that your stakeholders should be able read your code, understand your architecture as an automated view of their world.<p>Any abstraction away from that perspective is self-serving, tech-driven, and bad for the business.<p>Agile project management isn’t about unit tests and CICD. It’s about removing the gap between the business and its software development.<p>I appreciate SOLID principals and use various patterns, but my number one rule is we should never build something that does directly equate to a business process.<p>ORM’s hide business processes. Complex abstract frameworks hide business processes.<p>We need to stop doing that.

&gt; I haven’t yet had the “we tried both approaches and this one works better because &lt;business reason&gt;” response<p>it&#x27;s hard enough to build one production system right, now we&#x27;re supposed to build two and ditch the least-performing one?

Redux is another one of those software patterns that most ppl dont need but use anyway.

&gt; “How are you planning to handle GDPR requirements and removal of data?” – turns out the answer is often “Er – we haven’t thought about that.” Cue a sad face when I tell them that if they don’t modify their immutable log they’re automatically out of compliance.<p>Can&#x27;t you remove data by iterating through the log in a separate process, and remove data as you go? It will be slower, for sure, but is speed a requirement when removing data?

There are some real great gains being made ATM. Functional as-an-idiom, applied in more than just languages... Docker, Nix, Stateless application server, servers as cattle, Redux, event sourcing, micro architecture, serverless. I think great strides are in motion, and there is up heaval and mis steps, but I think the overall trajectory is genuine improvement.

Very happy to read this article which materializes the elephant in my mind. My tldr; for it is:<p><pre><code> * technical vision (and therefore core tech decisions) should match business vision and be justifiable, manifested by making architecture choices driven by thinking about constraints and working at high level as best as one can to get around them, rather than jumping straight to eager- architecturing to solving the non-existent problems only the likes of massive tech companies face. </code></pre> Some suggestions that made were include:<p><pre><code> * Try to re-use for speed, rather than roll-out-your-own, * Design for adaptability </code></pre> I think I agree. It sounds like the right thing to do. I hope the author follows up with multiple case studies of varying degrees of how this is happening in industry, and what he thinks could have been the right approach.<p>I also think that this might be just one side of the coin. I am really interested in hearing opinions that constrast his.

What does framework of the month mean? As far as I know, big JS frameworks aren&#x27;t popping up all the time. Ok, so a company switches to React. What do they switch to after? Vue? CycleJS? I don&#x27;t think companies do this.<p>I&#x27;m pretty sure most of the churn in the front-end world is about switching to React or Angular, with more overseas firms using Vue.

A lot of it has to do with the &quot;hype&quot; cycle going on. If NY and some CIO magazine says &quot;blockchain is the next best thing&quot;, everyone dives head first into it.<p>Then there are a lot online courses which promise to make you an &quot;expert&quot; with couple of hours in training. What people actually get is a very basic level of understanding. This step plays a particularly large role.<p>The next step is to build something using the just acquired knowledge. And once someone reaches this stage, it becomes a case of hammer and nail - To someone with a hammer everything looks like a nail. Solutions which barely meet the problem criteria are taken up because &quot;blockchain&quot; (or AI&#x2F;ML)<p>Anecdote - We had someone after completing the famous Andrew Ng&#x27;s coursera course ie novice in AI&#x2F;ML proposed to build an ML library for data cleaning. The management was very happy with the revolutionary idea - at least he is thinking was what they said.

There are some interesting conflicts that architects must resolve. Technology driven design is not great, but I feel things like CQRS fundamentally alter business expectations. Think about read-after-write usecases that customers are accustomed to because we used an RDBMS. If now we are forced to rearchitect because of scale and complexity, we have to change the product behavior. Try sell that to PMs and customers.<p>I believe the systems should be built ground up for scalability, but does not necessarily mean it has to be a complex implementation.<p>Ultimately, more commoditization of building blocks will make a lot of such decisions a moot point

Also a whole load of numpties in higher management who dont see the value of proper architecture and how it will prevent bad things happening in the future. Because the architecture is invisible to them, they fail to see value.

I think he might be being a bit too hard on himself and the profession. The challenge is that fundamental problems aren’t always universally solved even though it seems they should be. “Hey this is a database backed order entry system - should be a solved problem right!” Except then you dig in and see the nuance. And it’s solvable ... but it is ugly.<p>So, perhaps we should buy a order&#x2F;demand management system rather than build it. This too has its tradeoffs. SAP is in business for this very reason. There is a massive complexity and capital trade off when buying a system, it is never “buy”, it is buy, install, configure and integrate, and don’t customize so much you can’t upgrade.... I’ve seen many cases where that game is 10x the cost of “build with a small team using open source and&#x2F;or simple cloud services”.<p>So we eventually solve the problems somewhat messily with newer architectures and eventually hone our learnings into patterns that Martin Fowler inevitably publishes. These eventually become popular techniques with every new generation of developers and they become fads ... and may be misapplied.<p>I think it’s the way it’s always been. Today CQRS&#x2F;ES or microservices are the fad. 10 years ago it was web services and ESBs and 15 years ago it was transactions and distributed objects and 20 years ago it was CGI scripts and Perl . All of these solved lots of issues and caused lots of issues. The question is whether they solved more problems than they caused. The record varies.<p>Personally I have seen CQRS&#x2F;ES in lots of places lately for legacy modernization. It’s been around under various guises for a long time (10 years at least) - cache your legacy data, expose it with an API (you absolutely can do CQRS with REST btw, the commands themselves are resources), force the use of messages&#x2F;events to update the legacy only and use that to keep the cache coherent, and you can strangle the legacy gradually without a ton of huge changes in theory. Eric Evans indirectly talks about this as the 4th strategy in his great talk on “four ways to use domain driven design with a legacy”. One absolutely should consider the other three ways first (a bubble context &#x2F; repository, anti corruption layer, etc)<p>The other context I saw CQRS without ES is when you have a rich data display and your simple three tier JS to Java to ORM is starting to creak. I had a project that required a near real-time spreadsheet like view with security role filtering of data, custom column sorting, transforms, and consistent query across 10 tables that also allowed full text autocomplete search across the grid. Materialized views &#x2F; denormalization wouldn’t work too well in this case because the updates come in to the various tables from business events and other team members and the grid needed to be up to the second valid and quickly refreshed. The queries on the SQL database with Hibernate HQL wound up being massive 10 way outer joins , a bunch of nested scalar subqueries, lots of dynamic WHERE clauses and GROUP&#x2F;HAVING clauses plus full text indexing (this all ran in under 200ms mind you, so not terrible performance wise :). The problem was these were unwieldy to maintain as new data and indexing requirements came up and required deep understanding of SQL voodoo and performance tuning. This was not a big project either - high value (several hundred million ), high impact (multi billion dollar revenue stream), but a small team (8 people) and modest budget ($1m). Migrating our ORM to write commands on SQL and using Solr for query was the right move for the health of the system and long term performance. Btw, this was a project that was going to go on SAP for the low price of $30m and shipping in 9 months vs shipping in 3 months and evolving it after...<p>My point is that... - new architects always want to design-by-resume to some degree, and tackle the big bad hairy stuff with new techniques. this is why we see people throwing out proven components for terrible replacements on day 1 and then going back to the old 3 years later... looking at you , Mongo and Postgres! But sometimes the new technique is actually better (Looking at you, Kafka)<p>- Most people only learn through failure, they don’t read the warning labels ... Applying patterns tastelessly is a rite of passage<p>- even in smaller projects these patterns have applicability<p>- I’ve rarely bought software that I loved, they’re all 10x more complicated than they need to be and didn’t do necessarily a better job ... that said there’s also no guarantee that you and your team won’t build something that also is 10x more complicated than it needs to be... “all regrets are decisions made in the first day” as they say... it really depends on your luck and circumstances.<p>Perhaps one of the lessons of architecture that is missing is to teach people how to evaluate tradeoffs, or in other words, “taste”. I don’t think we’ve ever really had good taste as an industry. Buzzword bingo has always ruled, with some exceptions. One of the things I loved about Roy Fielding’s REST thesis was a way to analyze capabilities , constraints and tradeoffs on an architecture structure that consisted of components, connectors and data elements. That was the most important take away of that work IMO, we seem to have never learned how to critically look at these in favour of buzzword bandwagon jumps.

The numbers of developers working at an inappropriately low level is frightening.<p>this very true but unfortunately the packaged solutions available are vendor lock in or extremely opinionated frameworks. too much fetishism about frameworks.<p>why not just use react? cause i already had to learn js and framework of the month has a short shelf life.<p>theres an unsolveable problem here. the trade off between flexibility and the pre packaged abstractions called frameworks

There is a Chinese translation for this article <a href="http:&#x2F;&#x2F;www.infoq.com&#x2F;cn&#x2F;news&#x2F;2017&#x2F;11&#x2F;Software-architecture-decline" rel="nofollow">http:&#x2F;&#x2F;www.infoq.com&#x2F;cn&#x2F;news&#x2F;2017&#x2F;11&#x2F;Software-architecture-d...</a>

I&#x27;m working at a startup and we&#x27;re starting to use event sourcing and CQRS a lot more in the replatforming of core components of the application with kafka for an event log.<p>Personally, I find these patterns and approaches coupled with sound domain modelling to be perfectly fine. There is some technical overhead for event sourcing so some places we do not use a journal but instead persist current state but we still emit events and do interesting things with those events. CQRS is pretty safe if you&#x27;re investing into event driven architecture across your organization. You don&#x27;t need to use both - one or the other is okay too.<p>I wouldn&#x27;t have designed this system any other way - there are so many opportunities to do interesting things with the event stream that we discover almost daily.<p>Event sourcing is more dangerous and you need to have some really sharp people around to fix issues that come up and make it hum. We have multi-million line logs and I&#x27;ve had to spend some time going through open source libraries and changing implementations for projections from the log that were creating contention and performance issues, as well as modifying how the open source libraries recover to paginate through the events. All in, we can now recover from json in postgres at a rate of 20k events&#x2F;s (although usually we recover from snapshot!) and we can tear through thousands of commands a second in the running system. After these hurdles, everything is contant time or logarithmic so we can handle orders of magnitude growth without any issue. One day we&#x27;ll have to flip our aggregates to have a clean journal. It&#x27;s just life in engineering though - software isn&#x27;t an event, it&#x27;s a process so if you want to get the gains sometimes there are some costs. As long as you are smart about your choices and have a good team, you can make anything work.<p>I&#x27;ll add that the existing stack uses ORMs&#x2F;active record and the performance overhead of all those damn queries is now too expensive so we&#x27;re building some screaming fast Eventsourced and commandsourced apps SPECIFICALLY TO GET AWAY FROM THOSE TRIED AND TESTED CLASSICAL PATTERNS. Mind you, we could make the existing application hum too with some careful analysis - I&#x27;m not saying one is better or worse, just that they are both equally viable with some smart minds around and good decisions being made. DDD is never a bad thing and ES&#x2F;CQRS happen to be a reallly incredible fit in spaces where the domain is central as you end up very easily discovering you can have pure and beautiful domain models when you think in commands and events.<p>I&#x27;ll just leave a caveat that, while I think we&#x27;re having good success with the decisions, we also work in a domain with enough complexity that we get a lot of benefit in how ES acts as a heuristic in our modelling. Doing the same with a shopping cart may be overkill.

Fundamentally its about a lack of qualified professionals that are willing to think through their application in detail. As a by product people slavishly follow concepts and ideologies as opposed to thinking through which concepts actually apply to their current use case. People can&#x27;t be fucked to do that. In their minds a simple &quot;this good, that bad&quot; construct pops into their heads. &quot;Waterfall bad, agile good&quot; without asking themselves what the trade-offs of either pattern provide.<p>I&#x27;m currently living on the flip side of this article. A company that decided to give their clients the ability to have a completely free schema for their data backed by a real-time CRUD architecture which follows an EAV pattern so every column value is represented by a database row. Its inherently flexible but it doesn&#x27;t scale. What would be a single row select in any &quot;sane&quot; database retrieval routine is a multi-row and multi-table join on ridiculously tall tables.<p>Nobody thought through the implications of providing the customer with that free schema and nobody ever closed the loop on that problem set. Ideas like CQRS (who the fuck named that pattern so awfully btw?) or even things like NoSql would be preferable to the architecture but they&#x27;re somewhat slaves to the notion of ORMs and RDBMS. As a product, we try to spin on a dime and an optimisation for client A&#x27;s infrastructure will result in a detriment to client B.<p>Staff remain convinced that its an issue with the transport protocol chosen or ORM used but really its a problem with the feature set we chose to offer and failing to architect the solution to that problem created by our feature into the project.