The New Architectural Primitive: Declarative Layers That Preserve Change Locality

Change is getting more expensive in many orgs, not because engineers forgot how to ship, but because business logic, access policy, and data shape are drifting across boundaries. CTOs are responding by investing in architectural “shock absorbers”: declarative layers that let teams evolve rules, policies, and execution targets without rewriting core services every quarter.

HubSpot’s redesign of its Just-In-Time Access authorization system shows the pattern in a concrete way. The JITA flow moved to a rule engine architecture where independent rules evaluate access requests and can be composed (InfoQ, “HubSpot Redesigns JITA Authorization with Rule Engine Architecture”). That design choice turns authorization from scattered conditional logic into a product surface: versionable, testable, and safer to change under audit pressure. The technical win is only part of the story. The organizational win is reducing the number of teams that must coordinate every time access requirements shift.

The same underlying goal appears in guidance on evolutionary architecture. The InfoQ article on preserving change locality frames boundary drift as the silent killer: features that once fit inside a team’s scope start requiring cross-team negotiation, increasing cognitive load and slowing delivery (InfoQ, “Enabling Evolutionary Architecture Through the Preservation of Change Locality”). Rule engines are one tactic, but the broader message is architectural hygiene: keep seams sharp, keep ownership clear, and treat locality as a first-class metric.

Runtime portability is joining the toolkit. The InfoQ podcast on WebAssembly on the JVM describes Wasm moving beyond the browser, with performance improvements and a transition from interpreter-heavy approaches toward more efficient runtimes (InfoQ, “WebAssembly on the JVM…”). For CTOs, Wasm is less about novelty and more about decoupling. A portable execution layer can isolate “plugin-like” business capabilities, partner extensions, or customer customizations from the host platform’s language and release cadence.

Data platforms are converging on the same idea: make the messy parts first-class. Databricks’ general availability of Variant targets semi-structured ingestion by giving JSON/XML-like data a native representation and optimized processing path (Databricks, “Variant, Now Generally Available”). The strategic parallel to rule engines is strong: instead of forcing every producer and pipeline to normalize upfront, the platform absorbs variability, then teams refine and govern incrementally. Fewer brittle ETL rewrites. More room to evolve.

Actionable CTO takeaways:

• Treat “change locality” as an architectural KPI. Track how often a typical feature crosses repo, service, or team boundaries, then design to push that number down.
• Externalize fast-changing logic. Authorization policies, routing rules, pricing/eligibility rules, and partner-specific behavior are prime candidates for a rules or policy layer with strong testing and audit trails.
• Use portable runtimes selectively. WebAssembly can be a pragmatic isolation boundary for extensions and untrusted or customer-supplied logic, but only with clear sandboxing, observability, and a defined upgrade path.
• Make variability a platform concern. First-class semi-structured types (like Variant) can reduce pipeline churn, but governance (schema evolution, access controls, lineage) must be designed in from day one.

Sources

1. https://www.infoq.com/news/2026/08/hubspot-jita-rule-engine/
2. https://www.infoq.com/articles/evolutionary-architecture-change-locality/
3. https://www.infoq.com/podcasts/feature-evolution-performance-transition-endive/
4. https://www.databricks.com/blog/ingest-semi-structured-data-faster-and-more-efficiently-variant-now-generally-available