One of my earliest posts on Form Follows Function, “There is no right way (though there are plenty of wrong ones)”, dealt with the subject of trade-offs. Whether dealing with the architecture of a solution or the architecture of an enterprise, there will be competing forces at work. Resolving these conflicts in an optimal manner involves finding the balance between individual forces and the system as whole (consistent with the priorities of the stakeholders).
At the scale of an individual solution, concerns such as performance, scalability, simplicity, and technical elegance (to mention only a few) can all serve as conflicting forces. Gold-plating, whether in the form of piling on features or technical excess affects both budget and schedule. Squeezing the last drop of performance out of a system will most likely increase complexity, making the system more difficult to change in the future and possibly impacting reliability in the present. As noted by Jimmy Bogard, “performance optimization without a clear definition of success just leads down the path of obfuscation and unmaintainability”.
At the scale of an enterprise’s IT operations, the same principles apply. Here the competing forces are the various business units as well as the enterprise as a whole. Governance is needed to insure that some units are not over-served while others are under-served. Likewise, enterprise-level needs (e.g. network security, compliance, business continuity, etc.) must be accommodated. Too little governance could lead to security breaches, legal liability, and/or runaway costs while too much can stifle innovation or encourage shadow IT initiatives.
A fundamental role of an architect is to identify and understand the forces in play. In doing so, the architect is then positioned to present available options and the consequences of those options. Additionally, this allows for contingency planning for when priorities shift, requiring a re-balance. In a highly variable environment, having fragile balance is almost as bad as no balance at all.
Form Follows Function 
Good insight. I’ve thought about balance a lot, and I nodded my head a lot as I read. I particularly like your statement that “A fundamental role of an architect is to identify and understand the forces in play.” This takes balancing from an intuitive action to a deliberate choice.
LikeLike
Thanks, Dan. “Deliberate choice” is a good description, because the balance is very much determined by context and priorities. The needs of young systems/organizations are very different from those of more mature systems/organizations.
LikeLike
One way to measure whether our balance is right is by asking: Are we accumulating debt? Neglect technical elegance, and you will be accumulating technical debt; neglect performance, and you will be accumulating resilience debt.
There are many ‘smells’ that can indicate that you’re accumulating debt: increase in number of defects (differentiating internal or escaping ones), number of support calls, and so on.
One such smell that sometimes gets ignored is quite simple: if the teams tell the managers “we need to stop and make the code decent” is a good indication that you are pushing too many requirements to make a good balance.
LikeLike
My two biggest concerns re: technical debt are “is it intentional” and “am I gaining something in return”? Sometimes you accumulate debt, but it should be in order to enable some benefit and you should have specific plans for handling it in the future (either pay it down or ditch the feature if it doesn’t pan out). This is what makes unintentional debt worse (IMHO) in that it represents risk that was undertaken without that due diligence.
LikeLike
Technical debt is often compared to cleaning the house. There could be a time that we decide that we don’t clean the house for a month. Or don’t clean a specific room for a month. This is a legitimate decision – knowing that the recovery cost gets exponentially higher the longer we wait.
Technical debt is the same. Not renaming that method, not dividing the class, not making it multithreaded when needed – is going to punch you back sooner or later. It is legitimate to intentionally postpone these activities – but you need to know your organisation very well.
If the culture is to add another feature rather than repay the debt – you know that the only time to handle it is now (as in Red Green Refactor).
If, OTOH, you know that in the organisational culture you will have dedicated time to handle that pay-or-ditch feature, then you may postpone it some.
The only truth in this game is to face the empirical data with honesty. Because if the former is true, you know that in one, two or three years time your code is going to become so dirty that you will have to have yet another we-must-do-a-major-rewrite moment.
Not that there aren’t organisations that make such decisions only intentionally. In my humble experience, most organisations are not.
LikeLike
Agreed – at some point you have to pay. One of my responsibilities is to keep those issues in front of the business owner. As a rule, when I’ve made my case (explaining the risks in terms they can understand), they’ve been reasonable. This is also a reason why I push the product vs project perspective. Too many organizations think in terms of projects, when the reality is that once something has been developed, it will need to be supported. If no one is looking out for the technical aspect over the long term, then it is much more likely to devolve into a hopeless mess. Having someone with a sense of ownership to maintain that continuity of vision is extremely important to avoid it.
LikeLike
I very much agree. The project vs. product notion is so true.
LikeLike
Pingback: Technical Debt & Quality – Binary Thinking in an Analog World | Form Follows Function
Pingback: Carving it up – Microservices, Monoliths, & Conway’s Law | Form Follows Function
Pingback: Finding the Balance | Iasa Global
Pingback: Finding the Balance | IasaGlobal
Pingback: Are Microservices the Next Big Thing? | Form Follows Function