Scaling down my problems

Recently someone said something like the following somewhere (on Twitter? A link would be much appreciated):

Instead of scaling up your team, try scaling down your problems.

How would scaling down large problems work? Wouldn’t we have to solve large problems by composing the solutions to small ones? Wouldn’t we need another small team for doing this composition? Wouldn’t this bring us full circle to some sort of large-scale agile approach? Wouldn’t this be exactly what we set out to avoid?

How do two-pizza teams collaborate? What about coordination? Direction? Guidance? Funding?

In brief, how do I actually, concretely, practically scale down my problems in enterprisey e-commerce environments? I don’t have the faintest clue, but I’m bloody well going to find out. I’m done with scaling up!

 

6 thoughts on “Scaling down my problems

  1. tetradian

    The only viable way I know to scale down (or scale up, or scale sideways, even?) is to find some fractal pattern that fits well and works well within the context-space. Classic decomposition won’t work well enough for much of this any more: it tends to leave too many ‘unexpected’ gaps when we try to bring it all back together for the larger scale.

    Reply
  2. Gene Hughson

    Shearing layers is another concept to consider – some aspects are foundational and long-lived, others plug into that foundation and may have a shorter lifespan.

    Reply
    1. Oliver Baier Post author

      As in teams supporting long-lived platforms (even if that’s a big word) and more teams providing applications or services on top of that platform?

      Reply
      1. Gene Hughson

        Exactly…for example in my experience data centers and network infrastructure tends to be very slow-changing, server hardware less so (very much less so in a cloud-deployed scenario), and software tending towards the fastest. Using the Microsoft stack as an example, the Server OS gets a new version every 4-5 years, SQL Server roughly every 2 years, and the .Net Framework about once a year. Applications and services running on the platform might change anywhere from once a year to almost continually depending on their process model. Understanding the lifecycles of those components and how the affect each other is extremely important.

        Another aspect is that frequently large systems are actually systems of systems with a master application and supporting services (which may well be shared services). Dependency management and evolving without breaking dependent application is extremely important in those scenarios.

  3. Pingback: Whole-of-system architecture | Oliver's Blog

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.