Helm is a framework for addressing core-edge tensions

How do you build a strong and coherent through-line across multiple products & services, without stifling autonomy and innovation?

We wrestle with the same dilemma whether deciding to re-use a component in a digital product, base a vehicle design off a multi-brand platform or arrange vehicle registrations nationally or by state.

It's not as simple as equating the core with conformity and the edge with innovation. Consistency and disorder aren't always accurate either.

Leaning into this tension can help strengthen our ability to find the right balance.

The power of a strong core

The benefits of a strong core are easy to understand - we have decades of experience with shared services, common capabilities and product platforms. These are too often efficiency plays though, underfunded costs instead of advantages. Centralised capabilities can become constrained bottlenecks across a large portfolio. The positive advantages of the core can be far more compelling. Think of Amazon turning their infrastructure into AWS. Pooled investment that builds once with five times the quality can yield better outcomes than different teams building the same thing five different ways. Science and technology compound by stabilising achievements into "black boxes", solid foundations that enable new possibilities by closing others.

The romance of a diverse edge

The edges, by contrast, are where we encounter living reality in all it’s strangeness. Diversity feeds creativity. This is how we explore and evolve, finding new approaches instigated by unique situations. There’s a romance to working on the edge. It makes innovation exciting for us and authentic to our customers. There's inherent value in the messy, unique multiplicity of the edge that we can be sanitised if we force the edge to echo the core.

The tension

Change isn’t neutral and the edge can generate entropy as well as energy. The pride of “I built this” becomes “not built here” all too easily. We’re left with a dilemma. The core and the edge have both light and dark sides.

It’s hard to tell what’s most valuable in a specific situation. A strong core can help (regulating the chemicals causing ozone depletion) or hinder (rigid Soviet five-year plans). The edge can give us both Galileo and sprawling cities.

Often the best examples use a well-designed core element to enable Cambrian energy at the edge. Think of the shipping container, internet protocols like TCP/IP or the opposable thumb. In each of these, a measure of standardisation at the core opened possibilities to flourish at the edge.

There's power in a name

One way of dealing with this tension is to name the elements of the issue so we can work with about them more easily. Helm is the first version of our naming framework for core-edge tensions. We use Helm to steer conversations that grapple with these issues.

Surfaces

The first layer of the framework names the surfaces we're work on.

• On the core side of the ledger are things we will call “hubs” - elements that occur once and are used directly rather than copied. Think APIs or libraries that serve the whole system.

• At the far edge are “satellites” that occur once and are completely and validly unique - a standalone product or a one-off prototype for a unique market.

Everything between is a mix to be negotiated.

• “Primitives” are core building blocks. Think of a transaction list for a finance app. Primitives give a product a coherent through-line that benefits from core investment
• “Components” are commonly used surfaces that can be standardised in most cases.
• They come in ”variants”, or standardised versions that address different, but common, needs. In theory, we fold the edge into the core by standardising more variants.
• In practice this quickly creates a bottleneck, and so we also manage many, many “instances” composed from a mixture of primitives, components (and variants) and the truly unique.

Responses

If naming things (a core approach) solved the issue, we could close things there. However we need approaches to help us deal with the tension, not select a side. One candidate is what the architect Christopher Alexander called patterns - specific ways of resolving common tensions with what Alexander called the “quality without a name” - an elusive essence that distinguishes an inherently pleasing solution from the basic building blocks it’s composed of.

Patterns are often a great way to empirically investigate and respond to the edge. They can be collected and refined, and used selectively. Thinking in patterns gives us a way to talk about the tensions without forcing core or edge - they live in the tension.

We can also design in layers - multiple ways of using the same things. Think of a product that lets a person use it how they want whilst offering a guided path for those that want it. Onboarding flows often use this approach with a guide on first-use that falls away on re-use.

It also helps view our products and services as ephemeral rather than immutable objects, acting on the world through events. Orienting to events makes it easier to work with diversity, multiplicity and change by removing the assumption that things will work the same way each time.

Modern architectures (and AI) are event-friendly and building up from events helps make a portfolio more composable.

Tensions

The final layer of the framework are ways of acting to resolve tensions.

• Reflexivity is the process of reflecting on your own position when considering balances. Do you have an embedded perspective that is influencing your point of view?
• Ethics are important in core-edge tensions because there can be power imbalances that should be considered. Are we increasing power at the core for it's own sake or does it play an important role in making the whole eco-system better?
• Dialogue is critical to understand other perspectives and ensure that decisions balance the needs of all