I arrived in San Francisco the day before the conference began. Sometime in the early evening I was contacted by Susanne Kaiser. She had just arrived on a long flight from her home in Hamburg, Germany. It would have been early morning to her bio-clock, but she offered to meet in the lobby. I was surprised but accepted. We met there and spoke for a while, as I got acquainted with one of the kindest and most empathetic techies I can think of. I was speaking in her conference track about microservices with Domain-Driven Design. What I soon discovered was the previously unknown privilege I had to be invited by Susanne to work with her, and to be invited by her to speak at other conferences that she organized. Relatively early in the year 2020 when I accepted the offer for this signature series, I contacted Susanne about authoring. I knew she had considerable experience with Domain-Driven Design along with serverless architecture and programming, and I was certain she’d have a lot to offer the industry. I wasn’t wrong, and I’ll tell you why after I introduce the purpose of my series.

My Signature Series is designed and curated to guide readers toward advances in software development maturity and greater success with business-centric practices. The series emphasizes organic refinement with a variety of approaches—reactive, object, as well as functional architecture and programming; domain modeling; right-sized services; patterns; and APIs—and covers best uses of the associated underlying technologies.

From here I am focusing now on only two words: organic refinement.

The first word, organic, stood out to me recently when a friend and colleague used it to describe software architecture. I have heard and used the word organic in connection with software development, but I didn’t think about that word as carefully as I did then when I personally consumed the two used together: organic architecture.

Think about the word organic, and even the word organism. For the most part these are used when referring to living things, but are also used to describe inanimate things that feature some characteristics that resemble life forms. Organic originates in Greek. Its etymology is with reference to a functioning organ of the body. If you read the etymology of organ, it has a broader use, and in fact organic followed suit: body organs; to implement; describes a tool for making or doing; a musical instrument.

We can readily think of numerous organic objects—living organisms—from the very large to the microscopic single-celled life forms. With the second use of organism, though, examples may not as readily pop into our mind. One example is an organization, which includes the prefix of both organic and organism. In this use of organism, I’m describing something that is structured with bidirectional dependencies. An organization is an organism because it has organized parts. This kind of organism cannot survive without the parts, and the parts cannot survive without the organism.

Taking that perspective, we can continue applying this thinking to nonliving things because they exhibit characteristics of living organisms. Consider the atom. Every single atom is a system unto itself, and all living things are composed of atoms. Yet, atoms are inorganic and do not reproduce. Even so, it’s not difficult to think of atoms as living things in the sense that they are endlessly moving, functioning. Atoms even bond with other atoms. When this occurs, each atom is not only a single system unto itself, but becomes a subsystem along with other atoms as subsystems, with their combined behaviors yielding a greater whole system.

So then, all kinds of concepts regarding software are quite organic in that nonliving things are still “characterized” by aspects of living organisms. When we discuss software model concepts using concrete scenarios, or draw an architecture diagram, or write a unit test and its corresponding domain model unit, software starts to come alive. It isn’t static, because we continue to discuss how to make it better, subjecting it to refinement, where one scenario leads to another, and that has an impact on the architecture and the domain model. As we continue to iterate, the increasing value in refinements leads to incremental growth of the organism. As time progresses so does the software. We wrangle with and tackle complexity through useful abstractions, and the software grows and changes shapes, all with the explicit purpose of making work better for real living organisms at global scales.

Sadly, software organics tend to grow poorly more often than they grow well. Even if they start out life in good health they tend to get diseases, become deformed, grow unnatural appendages, atrophy, and deteriorate. Worse still is that these symptoms are caused by efforts to refine the software, that go wrong instead of making things better. The worst part is that with every failed refinement, everything that goes wrong with these complexly ill bodies doesn’t cause their death. Oh, if they could just die! Instead, we have to kill them and killing them requires nerves, skills, and the intestinal fortitude of a dragon slayer. No, not one, but dozens of vigorous dragon slayers. Actually, make that dozens of dragon slayers who have really big brains.

That’s where this series comes into play. I am curating a series designed to help you mature and reach greater success with a variety of approaches—reactive, object, and functional architecture and programming; domain modeling; right-sized services; patterns; and APIs. And along with that, the series covers best uses of the associated underlying technologies. It’s not accomplished at one fell swoop. It requires organic refinement with purpose and skill. I and the other authors are here to help. To that end, we’ve delivered our very best to achieve our goal.

The book you are about to read is not merely a techie book. It’s an amazingly elegant mesh of Domain-Driven Design, Wardley Mapping, and Team Topologies, all orchestrated within an architecture for continuous software value flow. That was easy for me to type. Yet, delivering that as a helpful book is a challenge beyond most authors’ scope, especially when rendering those topics with top-shelf quality and economy of words. I’ll describe it by quoting Mark Twain: “I didn’t have time to write a short letter, so I wrote a long one instead.” You’d probably think that for an author to write a book spanning such a large subject, they would have to produce 700 to 800 pages. Not if Susanne is the author. What you hold in your hands is one of the most concise and approachable books on these topics, but one that doesn’t compromise detail. As the series editor, I found her book a page-turner. It was such a pleasure to review and learn from. And her hand-drawn illustrations are the dessert with a fine five-course dinner.

I feel like anything more that I write would only take time away from you enjoying this excellent treatment of strategic planning, architecture, design, and team organization, and a great learning experience, delivered with heart by a kind and empathetic software leader.

Vaughn Vernon, series editor