Semantic Software Design
by Eben Hewitt
Copyright 2020 Eben Hewitt. All rights reserved.
Printed in the United States of America.
Published by OReilly Media, Inc. , 1005 Gravenstein Highway North, Sebastopol, CA 95472.
OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com .
- Acquisitions Editors: Ryan Shaw and Chris Guzikowski
- Development Editor: Alicia Young
- Production Editor: Kristen Brown
- Copyeditor: Octal Publishing, LLC
- Proofreader: Charles Roumeliotis
- Indexer: Ellen Troutman-Zaig
- Interior Designer: David Futato
- Cover Designer: Karen Montgomery
- Illustrator: Rebecca Demarest
- October 2019: First Edition
Revision History for the First Edition
- 2019-09-25: First Release
See http://oreilly.com/catalog/errata.csp?isbn=9781492045953 for release details.
The OReilly logo is a registered trademark of OReilly Media, Inc. Semantic Software Design, the cover image, and related trade dress are trademarks of OReilly Media, Inc.
The views expressed in this work are those of the author, and do not represent the publishers views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility ...
Preface
Thank you kindly for picking up Semantic Software Design. Welcome.
This book introduces a new method of software design. It proposes a new way of thinking about how we construct our software. It is primarily focused on large projects, with particular benefit for greenfield software projects or large-scale legacy modernization projects.
A software project is said to fail if it does not meet its budget or timeline or deliver the features promised in a usable way. It is incontrovertible, and well documented, that software projects fail at alarming rates. Over the past 20 years, this situation has grown worse, not better. We must do something different to make our software designs more successful. But what?
My assumption here is that youre making business application software and services to be sold as products for customers or youre working at an in-house IT department. This book is not about missile guidance systems or telephony or firmware. Its not interested in debates about object-oriented versus functional programming, though it could apply for either realm. Its certainly not interested in some popular framework or another. And for the sake of clarity, my use of semantic here traces back to my philosophical training, and as such, it concerns the matter of signs. Semantic here refers more to semiology. It is not related or confined to some notion of Tim Berners-Lees concept of the Semantic Web, honorable as that work is.
The primary audience is CTOs, CIOs, vice presidents of engineering, architects of all stripes (whether enterprise, application, solution, or otherwise), software development managers, and senior developers who want to become architects. Anyone in technology, including testers, analysts, and executives, can benefit from this book.
But there is precious little code in the book. It is written to be understood, and hopefully embraced, by managers, leaders, intellectually curious executives, and anyone working on software projects. That is not quite to say that its easy.
The ideas in this book might appear shocking at times. They are likely to irritate some and perhaps even infuriate others. The ideas will appear as novel, perhaps even foreign and strange in some cases; the ideas will surface as borrowed and recast in other cases, such as in the introduction to Design Thinking. Taken in sum, its my bespoke method, cobbled together over many years from a wide array of disparate sources. Most of these ideas stem from my studies in philosophy in graduate school. This book represents a tested version of the ideas, processes, practices, templates, and practical methods that together I call semantic design.
This approach to software design is proven and it works. Over the past 20 years, I have been privileged to work as CTO, CIO, chief architect, and so on at large, global, public companies and have designed and led the creation of a number of large, mission-critical software projects, winning multiple awards for innovation, and, more important, creating successful software. The ideas presented here in a sense form a catalog of how I approach and perform software design. Ive employed this approach for well more than a decade, leading the design of software projects for $1 million, $10 million, $35 million, and $50 million. Although this might seem a radical departure from traditional ways of thinking about software design, its not conjecture or theory: again, its proven and it works. It is not, however, obvious.
We are forced to use the language we inherit. We know our own name only because someone else told us thats what it was. For reasons that will become clear, in this book I sometimes use the terms architect or architecture under erasure, meaning it will appear with a strike, like this: architect . That means that I am forced to use the word for clarity or historical purposes to be communicative, but that it is not presented as the intended meaning in the current context.
The first part of the book presents a philosophical framing of the method. We highlight what problem were solving and why. This part is conceptual and provides the theoretical ground.
The second part of the book is ruthlessly pragmatic. It offers an array of document templates and repeatable practices that you can use out of the box to employ the elements of this method in your own daily work.
The third part provides an overview of some ways you manage and govern your software portfolio to help contain the general entropy. The book ends with a manifesto that summarizes concisely the set of principles and practices that comprise this method.
Taken altogether, the book represents a combined theoretical frame and a gesture toward its practice. It is not closed, however, and is intended to be taken up as a starting point, elaborated, and improved upon.
This book was written very much as a labor of love. I truly hope you enjoy it and find it useful as you apply the method in your own work. Moreover, I invite you to contribute to and advance these ideas. Id be honored to hear from you at eben@aletheastudio.com or AletheaStudio.com.
Conventions Used in This Book
The following typographical conventions are used in this book:
ItalicIndicates new terms, URLs, email addresses, filenames, and file extensions.
Constant width
Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.
Constant width bold
Shows commands or other text that should be typed literally by the user.
Constant width italic
Shows text that should be replaced with user-supplied values or by values determined by context.
Tip
This element signifies a tip or suggestion.
Note
This element signifies a general note.