Finding the Balance

Evening it out

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.

Advertisements

12 thoughts on “Finding the Balance

  1. 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.

    Like

    • 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.

      Like

  2. 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.

    Like

    • 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.

      Like

      • 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.

        Like

      • 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.

        Like

  3. Pingback: Technical Debt & Quality – Binary Thinking in an Analog World | Form Follows Function

  4. Pingback: Carving it up – Microservices, Monoliths, & Conway’s Law | Form Follows Function

  5. Pingback: Finding the Balance | Iasa Global

  6. Pingback: Finding the Balance | IasaGlobal

  7. Pingback: Are Microservices the Next Big Thing? | Form Follows Function

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s