A skeptic’s guide to software architecture decisions
infoq.com
infoq.com
Skepticism is a valuable counter to an unreasonably rosy picture of the world that only looks at the best cases for outcomes. While a positive attitude is essential, it’s often best to "hope for the best and plan for the worst."
In practical terms, applying skepticism often means making space for team members to question assumptions and assertions by looking for ways to prove (or disprove) the team’s assumptions. Skepticism means more than simply cataloging assumptions; it means actively investigating whether those assumptions are valid.
Teams need to recognize that every requirement, including Quality Attribute Requirements (QARs) that drive the architectural design, represents a hypothesis about value. One of our goals when taking a skeptical approach is to make these hypotheses explicit and to consciously design experiments that specifically test the value of the requirements.
Being skeptical is not a sign of disrespect; it’s actually a sign of sincere respect for the complexity of delivering excellent outcomes to customers in a chaotic world. It means taking seriously the team’s commitment to seek desirable outcomes expressed in product goals and QARs. Skepticism helps teams to question assumptions and hidden biases in a positive way.
Thoughtfully employing skepticism can be essential to every software development team’s tool kit. It can help them make better decisions earlier in the development cycle and at a much lower cost.
The architect who is planning all of this has so far pretended on-prem doesn't exist and hasn't thought about how the data, or the systems, are going to change _DURING_ the transition.
He's now in hyper-negativitiy mode because when I got here I realized no one was discussing or planning for it and started talking about it. As a result, many people (all the way up to the VP level) started reacting to my discussions and the arch diagrams I was using to better communicate so now he's started being super picky about everything on the non-cloud side (when previously he had no interest in it).
This person is a bit of a conundrum for me, I honestly don't know what to think of him. On the one hand he's a fellow architect and is old enough to have 20+ years under his belt. On the other hand, I find him _incredibly naive_ about how these types of projects go. I mean, almost unfathomably naive, the way you would expect a junior developer to be naive because their "width of perspective" just isn't there (and it can't be, they must grow first, as we all did).
What makes it worse is that when I got here they were actually attempting to do three things at once.
1. move to the cloud
2. rebuild the data model
3. rewrite the legacy systems
This company has over 20 years of legacy, including multiple platforms that do the same thing because they bought competitors.
It almost felt like the business side was being taken advantage of. Business was convinced to move to the cloud and the technical side threw in a laundry list of wants and claimed it was required for the cloud, which put the entire thing at risk. So much so that it became a revolving door for people on the technical side (who were not involved in that decision) as everyone realized this project would not be successful.
---
Anyways, your rosy picture comment got me to thinking about that guy. These kinds of projects are messy for a lot of reasons, I've legitimately had conversations with people about their marital problems when these types of projects go sideways so I may be more sensitive to the negative possibilities than most, but I certainly don't feel as if most people on this project are truly respectful of those possibilities.