Imagine this: You are an architect sitting in your ADR / ARB. A team lead is presenting their design for you and your team’s review:
“Due to a tight timeline; we are going to bypass our standard service layer and just return the data from the database directly to the UI. We feel that this is an acceptable tradeoff as the UI only needs to read data, and we don’t need the overhead of all the CRUD operations that are mandated for the service layer”
All of a sudden, the temperature in the room changes. Your team-mates (who have been “following along” while answering emails and slack messages), sit up. Their Spidey senses are tingling.
Joe from your team speaks up, “That violates our architectural requirement of the UI must talk to the service layer to prevent tight coupling.”
Suzy, the team lead that is presenting the design, agrees. And then she says the magic words . . . “This saves us 2 weeks of work, and the business has already begun marketing this new feature, we can’t slip the delivery date”
What. Do. You. Do?
Do you want to be the one that pisses off the business due to “principals”. Or do you want to appease the business, and just make a note and put the refactor on the architectural backlog (before the code is even written).
This is a Faustian choice that is played out every day, in confrence rooms around the world.
This is an economic choice that is always the lesser of two evils:
- Maintain architecture purity, spend the money now, and know that “tomorrows” work will be easier
- Save the cost now, and pay it back (with interest) later
This is NOT architecture. This is economics; pure and simple.
To allow the tight coupling allows the business to meet its goals. To protect the monies already spent on marketing; to drive increased profits. The team that delivered the code are seen as “heros” and you and your fellow architects are “not the bad guys”.
To prevent the tight coupling means that the business won’t meet their goals, they will have to recreate marketing materials, reshoot advertisements, and various other “external costs that will have to be absorbed”. But you have protected the business tomorrow, you have made sure that you keep your future feature costs down. You should be celebrated.
What about refactoring? How does the business begin to understand that you have to “spend a penny to save a dollar” when next years budgets aren’t even defined yet. That “tripping over a dollar to pick up a dime” is short sighted.
I’m not going to get into the usual challenge of “getting the business to understand IT”, you are better off being Sisyphus and just get used to pushing boulders around.
The number 1 problem is that both sides are right. Both sides are looking at the same ledger, just with a different lens. But the business ONLY sees the times savings (and thus cost); they don’t understand the law-of-unintended-consequences that these shortcuts cause.
They don’t see that they are cutting off their nose to spite their face. They don’t see the increased costs tomorrow, when they are only looking at this year’s budget. This year’s IRR and ROI calculation.
In my opinion it is time to stop talking about “architectural purity” in terms of “best practices” and start talking about the impact of not doing it “right”.
We should be saying: “I agree that it will save us two weeks of time. However the DATA shows that this new coupling will increase the blast radius of any change in the service layer by 40%, and will impact the delivery of three other team’s deliverables. The cost of THEIR delays, due to the need to perform work arounds, and increased testing will cause an additional 6 weeks of work for THEM.”
We need to quantify the impact; we need to elocute that this “short cut” is really the bad idea that me and my architectural peers see it as. We have to support this with data.
So the question for your CTO/CIO is not “How can we better enforce best practices?” But “Are we making the right financial decisions with our architecture, so that we can maximize business value?"
Now go back to your emails and Slack messages.