Building large scale systems requires strong architectural philosophy to guide the millions of small decisions made along the way. A primary principal governs the top level abstractions of the system: are we implementing a technology, building a platform, or organizing by domain?
This decision comes to life as the system presents itself to the world.
Defining the Perspectives
At ThoughtWorks, and we love talking about Domain Driven Design, a concept most thoroughly described by Eric Evans in his book of the same name. I also spend a lot of my time working with cloud technology and often hear the case for adopting particular cloud products, arguments supported with diagrams showing how these cloud products work together. Box, arrow, box, arrow.
And then there’s this platform idea.
We need a simple construct to think about these perspectives.
Technology First
Tech first means putting domain and platform concerns inside the technology. These systems present to users the technology’s internal model: workspaces, folders, databases, etc. Technology specialist teams focus on getting the most from the technology, and architects focus on how technologies interact.
Platform First
Platforms exist to create scale: by streamlining value creation (PaaS platforms) or by creating value connecting producers and consumers (multi-sided platforms). In both cases, platforms invert the relationship with technology, deploying technology within the framework of the platform. Platforms present users with a unit of the platform designed around its value creation goals; technology is subordinate to this unit.
Platform ecosystems extend this model by dividing the problem space, interacting in prescribed ways to solve internal B2Bish problems or crossing the firewall into B2C. Platform boundaries create conceptual alignment challenges (opportunities?) as a tradeoff against organizational independence.
Domain First
Putting the organization of the business and its problem spaces at the top of the stack rotates our perspective even farther. Platforms and the technology deployed within them are now subordinate to the bigger domain concern. Platforms and platform ecosystems are leveraged to deliver domain value in the same way that the platforms leverage technology to deliver platform constructs.
Implications
Practically, these perspectives govern how people interact with the systems. What mental model will be presented?
Technology
Technology orientation is the most common, most direct model, encouraging thinking in terms of the tech. We organize teams around technology skills and deep expertise, creating processes for accessing the tech and people.
For example, if we’re using a database, we think about schemas, tables, and columns. We spend a lot of time thinking about data types and (de)normalization. We build deep skills in performance optimization and data modeling. And we consider how the database interacts with Java or .NET, or with an API framework or BI tool.
Domain concepts don’t disappear with technology oriented thinking. Since few business problems can be addressed entirely within a single technology, we consider how to move the problem from tech to tech, re-framing the problem to fit the technology.
No matter which approach we take, we have to do this. Technology is where the rubber meets the road. The decision is:
Do we strive to fully adopt each technology’s point of view, shaping the problem accordingly? Or do we focus on retaining the domain or platform concepts intact, bending the technology to fit?
Platform
Platforms move the problem “up” a level in abstraction. Platform builders (PaaS and multi-sided) decide on the units of their platform, i.e. the platform’s abstractions. For example in Azure, it’s an “Azure Product” composing compute, storage, networking, etc. into a higher order capability. For Uber, it’s a ride (or a meal for Eats), connecting a rider and a driver.
Platform builders must consider how these units act and interact, bringing technology to this view. Platform users are presented these units, not the technology. Technologies that can’t be molded to support the platform unit must be discarded or replaced: value is created by the platform unit, not the tech.
For example, a Data Mesh platform’s unit is the data product (DP). DPs interact with one another via “ports” for data and controls. Users of a mesh create, update, and discard these DPs, expecting the DPs to provide some capabilities and abstract away complexities in provisioning, costing, access control, and data management. They expect not to deal with fragmented experiences in these, hiding technologies and options that are irrelevant to the data product platform unit.
They expect to interact with the unit of the platform; the technology is subordinate.
This doesn’t mean they don’t see the technology (they may or may not). It means that what they see of the tech makes sense in the platform unit context.
Because of this abstraction model, platforms may bring value directly to people, or they may become technology in the next platform or domain first system. Cloud platforms, complex compositions of infrastructure, are simply technology to the next layer. And the next layer must decide whether they can be molded adequately.
Domain
Domain thinking takes one more step. Domain first might promote a process or experience based model, building consistency across platforms and technology. A customer loyalty domain might look to align its use of digital, data, and analytics platforms to its ubiquitous language concepts like customer, touchpoint, and sentiment.
Domain thinkers will see a platform that has predefined “customer” as friction, forcing them to adopt a mismatch to use the platform. Likewise, having to redefine these concepts repeatedly in individual technologies is friction, creating up-front work to configure and long term maintenance to keep in sync.
Successful domain facilitation focuses on end to end experience across platforms and technology. Longitudinal definition of concepts; not “common” or “enterprise”, but according to the domain’s language across all components.
In a real way, all successful platforms lean towards a domain first point of view, even when the domain orients towards enabling technology. For instance, Kubernetes’s interface optimization towards the domain concern of jobs-to-be-done. A platform that ignores domain flails about aimlessly.
Domain first means cross technology, cross platform domain orientation, building domain constructs that span an ecosystem (tech and platforms subordinate to domain concerns).
Principles First
Making the decision to prioritize tech, platform, or domain concerns will determine how users think about and interact with a system, pushing a local optimization mindset in technology to a more end to end mindset as you move towards domain prioritization. Choosing the unit of the system allows you to frame how users move pieces on their mental canvas, a powerful influence on your relationship. It’s often easy to simply implement technology as is, pushing rapidly to market. But let’s carefully consider how we want our customers to think about us when we get there.