You focus on the concept: what is the world you are making that creates a context for the design that becomes the production factory?

How do you invite, not reject constraints, to find grounding? How specific can you be while still saying only true things in all the names throughout the design?

How can you invite nonbuilding metaphors to help you as a bricolage?

You are engaging and alighting the curiosity and intellect and cross-pollinating vectors of thought in your team. You are encouraging and nurturing their thinking processes. That is the first element. Not to dictate and prescribe, but to inspire and alight according to the principles of X.

Use Design Thinking when thinking about what to make.

Use lateral thinking when thinking about how to implement it. This is about solving problems using an indirect and creative approach via reasoning that is not immediately obvious. It involves ideas that may not be obtainable using only traditional step-by-step logic. Lateral thinking is more concerned with the “movement value” of statements and ideas. Edward de Bono defines four types of thinking tools: 1) idea-generating tools intended to break current thinking patterns—routine patterns, the status quo; 2) focus tools intended to broaden where to search for new ideas; 3) harvest tools intended to ensure more value is received from idea generating output; and 4) treatment tools that promote consideration of real-world constraints, resources, and support.

Use Strategic ideas, as in Technology Strategy Patterns, to ensure your concept aligns with the business vision: raise your visor and innovate at this level of the idea. We’re not interested in arguing over frameworks. They don’t matter.

Use Oblique Strategies to challenge your own conventional or default view. Pick one in the standup each day, or send them to the team. You’re activating critical and lateral thinking and imagination.

Use deconstruction: look at the multiplicity of structures that start to arise in the system, find the binary oppositions that support those structures (Master/Slave, Center/Margin, Speech/Writing, Production/Development—development is production to the developers, Functional/nonfunctional Requirements), determine which of the terms is the privileged one, and show how the traces undermine that privileging. Then design something without marginalizing one of the terms.

We do DevOps, as it is a deconstruction of that historical binary opposition.

The system has many small pieces, with high cohesion following the Single Responsibility Principle.

Keep a design scrapbook or lookbook as they are called in fashion houses. You will need a multiplicity of views and perspectives represented in different formats for varying time horizons, executives, customers, and developers.

We do not freeze in time, which has perpetually frustrated software designers. Instead we admit that this never works, and instead foreground Becoming. What we design is not the system as is, but a process of change, flight, or movement within an assemblage. As Deleuze and Guattari explain:

The process of “becoming-” is not one of imitation or analogy, it is generative of a new way of being that is a function of influences rather than resemblances. The process is one of removing the element from its original functions and bringing about new ones. Hans is also taken up in an assemblage: his mother’s bed, the paternal element, the house, the cafe across the street, the nearby warehouse, the street, the right to go out onto the street, the winning of this right, the pride of winning it, but also the dangers of winning it, the fall, shame.... These are not phantasies or subjective reveries: it is not a question of imitating a horse, “playing” horse, identifying with one, or even experiencing feelings of pity or sympathy. Neither does it have to do with an objective analogy between assemblages. The question is whether Little Hans can endow his own elements with the relations of movement and rest.”

For architects, this means we resist the demands to freeze things in time. Things are not themselves: they are only ever becoming-things. So we design for movement, design for becoming, not now-ness, not false decideability and stasis. We know that we don’t know the most important things, how it will be used, and we design an empty center to hold that not-knowing up front, on purpose, with care: this makes us foreground pluggability throughout the system.

There is only one substance. Therefore everything which exists must be considered on the same plane, the same level, and analyzed by way of their relations, rather than by the “essence” of the “entity”, as if it exists in a vacuum: that false assumption damages our designs. Despite its name, Relational Data Models privilege the essence, and relegate the relation to a second-class citizen. Deconstruction loves the relation, and see things not in an special essence, but in their relations of differences. We find ways in the design to foreground the relations and the differences.

Graph databases are therefore an excellent tool, as are pub/sub, eventing streams that turn the database inside out, and modeling services as contextual agents, not essences. That is, we don’t design the One True “Profile” service to rule them all. We instead abstract up and design the Persona service, wherein the single person with one tax ID has many different relevant modes of being in the world, and designing for that multiplicity aggregates nuances that improve the richness of the system.

The elements of the architecture (business, application, data, infrastructure, as well as their representations) are not viewed as separate but in a unity, altogether, and their impact and forcefulness and intensities on each other are examined and considered and designed for.

Make design decisions in empathetic thought of customer personas in different extremes, both valid.

Design with the entire picture in mind: business, application, data, and infrastructure as systems. When designing, think of the monitoring as you implement an algorithm; consider the business implications of infrastructure choices; and consider the changing requirements when locking down a data modeling.

We recognize our duty and responsibility and joy to design all the things, not just focus on the software: when subsystems are in harmony with each other and the broader concept, the product will be optimal across many concerns (-ilities, project concerns). Design the software together with the business design and the infrastructure and data design.

The making of the software is one small piece of the puzzle; overindexing on software and thinking it will run separately when magical fairies whisk it away to the cloud is a recipe for failure.

In considering infrastructure, we design pipelines.

We radically automate the testing: we never manually test, but have test automation engineers. The tests are not ancillary to code: they are code, and are first-class citizens.

Write automation tests against the infrastructure, too.

Design in extremes such that if you are plotting out this event type, get two different points of view and put one stake in the ground and then a second one on a different extreme (how does ecommerce work for a sleep room, how does it work for a coffee mug).

Code reviews are not about today’s code and policing programming but about encouraging the concept and broadening its understanding and application. It is about mentoring, sharing, mapping to the principles and not scrutinizing junior developers but more like pair programming so others learn it and make less SPOKs and learn the principles and refactor the design.

We do Pair Architecting: share a screen and review the design together, in a plain text file to get the words right. You’re agreeing on metaphors that carve our semantic space and it should be MECE.

Radical immutability in the architecture whereas the artifact that is built and deployed is totally immutable. Focusing on making things immutable everywhere possible is the key to allowing movement and change and mutability, which is the hallmark of a manageable, monitorable, extensible, cost-effective system

Write a Design Definition Document that compiles the views across business, application, software, and infrastructure stakes. This might be called a Petits Recits.

Why wait for a week to demo code? When code is done, invite the team to demo it immediately, or in a very short amount of time, in an event-driven way, when your story is done—don’t wait until the end of the sprint if you use those (though Kanban is more consistent). Make a party of it.

Defer the implementation: do not write precisely the requirements as given. First create a context in which those imagined requirements could come to life; then implement them as merely what happens to be the first known requirements (not even the “default”—that’s always a false privileging). See what you’re doing now, abstract up to the category, and make that first as the context, then implement whatever the stated requirement is, knowing it will change. Give names that recognize this.

Design machine learning capabilities throughout the system. This is generative architecture, active design: embrace that. Yes, make your machine learning for customer product recommendations, but also for data clean up and rogue monitoring. Design learning into the system to make it truly organic. This suggests making feedback loops and machine learning pipelines. You don’t decide the implementation up front even necessarily: let the system pick based on what it learns. You’re recommending products to your customers without being asked: your system can, in an adversarial manner, learn, pick a champion, and deploy it in an ultra-dynamic manner. The radical pluggability supports this idea. You are designing the system that can do better, move, grow. We don’t make frozen pictures of software or frozen software.

Do not design with hierarchies or enums in the data model. These will almost always be proven to be false deconstructed in the world, so your software must reflect more fluidity.

Assume your component will eventually be Decorated or have a Strategy injected. Instead of directly implementing any business logic, write it as the presumed first Strategy implementation.

Prefer peer-to-peer protocols and systems without Master/Slave, such as Cassandra.

Interfaces over inheritance.

Do multivariate testing, canary deploys, multivariate deploys.

Do not privilege production over staging: have a multiplicity of stagings, and automate learning which ones work best. Why have one production? Have many running at once. Use multi-armed bandits to explore and exploit. The world of X production is richly multidimensional.

Do automation at the beginning of the project, not at the end.

Define metrics at the beginning of the project, not at the end. Code toward success metrics.

Break production on purpose: run Chaos Monkey to ensure you’re breaking production. This makes your services more resilient.

Design and use pipelines for Continuous Integration and Continuous Deployment. Design them up front, when your software is just Hello World, not at the end. This way you test them throughout the project. They are software, too. Make pipelines for your database (FlywayDB). Make a machine learning Pipeline for Continuous Learning.

We know that we don’t know, so we design for change, not fake frozen pictures, we design it to be pluggable.

Design the configuration first, not last as we typically do, when things are most rigid: consider how this will be changed and design it for that change, not for fixing on arbitrary and changing requirements.

Don’t treat exceptions as exceptions (ancillaries, losers in the binary opposition) but rather as one of the valid paths requests will take through the system in its cyclomatic complexity. This will make your services more robust and resilient. You’ll design Dead Letter Offices, consider retries and compensations and useful messages to quickly improve, and narrow your design appropriately. Accept exceptions, and invite them. If you don’t give them power, they will take yours.

Do not assume the single data tool: model your associations for change and becoming, with extensibility as the feature. This will mean there are many data models: the different database implementations, in which one may be suited for reads and one for writes under different services with different scalability needs and usage patterns. There are also different views of the same data: yes, use materialized views but also caches and denormalized patterns, which may differ.

Use the Specification pattern (see “Specifications”) for decoupling external search criteria from the entity.

Design for the team, the first user of the software, to maximize flow. You as a designer are making space for the rest of the team so they can do their work in parallel to maximize velocity and ownership. Design for the team too and then Conway’s Law will work well, and the software will be well organized and developers can be accountable and have pride of ownership.

Outcomes over activity.

Value creation over process obedience.

Employ use cases with an outside-in approach.

Commit to the Value Chain and make it efficient towards outcomes. Do not focus on policing developers or preventative architecture review boards to ensure compliance with an arbitrary and academic committee that does not own an P&L.

Your internal colleagues are your customers too: developers are the first users of the system; the Network Operations Center monitoring crew are users of the system; testers are users of the system. Everything you do in the design to support this diverse customer set will pay off.

There are nearly 200 countries on earth, with thousands of languages. Externalize user strings and design for internationalization and localization from the beginning.

If this is a web system, design it for a watch. If this is a phone app, design it for a game console, or for voice. Foreground varying UIs by creating a separate UI Package service. There is no “The UI.”

Use eventing liberally. We default to synchronous request/response models, as if we know the meaning, we know what should always happen. Instead, foreground asynchronous. This improves scalability and description of the system. But it also does something for you where you don’t have to decide the meaning: you allow the “import” of the event to be deferred. This is powerful because the business changes their mind frequently, the system evolves, different customers need different things, things means something different to diverse audiences. Any reaction in your application should not be hardcoded. Use event handlers.

Allow for a multiplicity of voices using polyglot persistence and polyglot programming: make them right for the job and there will be different kinds for different jobs in your application. This is the majesty of AND, not the tyranny of OR. This dramatically improves performance and prevents lock-in of contracts, licensing, and thinking.