Semantic Software Design: A New Theory and Practical Guide for Modern Architects

Origins of Software Architecture

“The core challenge for computing science is hence a conceptual one; namely, what (abstract) mechanisms we can conceive without getting lost in the complexities of our own making.”

“Software belongs to the world of ideas, like music and mathematics, and should be treated accordingly.”

• The concept of structure within a field, such as we might call “architecture” within the field of technology, is thereby first an object of language.
• Processes exist to create copies
  • Do we ever create copies of the software itself? Of course, we create copies of software for distribution purposes.
  • That is a process facilitating distribution, however, and has little relation to the act of creating that single software application in the first place. In fact, we never do that.
  • Processes exist, too, in order to repeat the act of doing the same kind of thing, if not making the same exact thing. A software development methodology catalogs the work to be done, and software development departments have divisions and (typically vague) notions of the processes we undergo in the act of creating any software product or system. So, to produce software of some kind, we define roles that participate in some aspect of the process, which might or might not be formally represented, communicated, and executed accordingly.
• We must innovate, make something new and compelling, in order to compete and win in the market. As such, we squarely and specifically aim not to produce something again that has already been produced before.
• The design of software is no science. Our processes should not pretend to be a factory model that we do not have and do not desire. Such category mistakes silently cripple our work.
• It’s the CTO’s software projects that run the greatest risk and that fail most spectacularly. That’s because they require the most creative, conceptual work. They demand making a representation of the world. When you do this, you become involved in signs, in language, in the meaning of things, and how things relate. You’re stating a philosophical point of view based in your epistemology.
• Creative work need not always fail. Plenty of movies, shows, theatrical productions, music performances, and records all get produced on time and on budget. The difference is that we recognize that those are creative endeavors and manage them as such.
• We think we’re doing “knife science” or “computer science” or “architecture”: we’re not. We’re doing semantics: creating a complex conceptual structure of signs, whose meaning, value, and very existence is purely logical and linguistic.
• When we focus on the semantic relations, on the concept of what we are designing, and shift our focus to set-theorizing the idea of the world that our software represents, our systems do better.

The Production of Concepts

Semantics and the Software Factory

• The process of making a system for anything itself requires a system. This is a meta-model: a way of making models.

The Myth of Requirements

• In system design, we speak of the “requirements.” This word creates a false center, a supposed constant, which creates problems for our field. These problems come in the form of a binary opposition set up between the product management team and the development team. It supposes, in the extreme form, that the product management team knows what to build and that the development team are passive receptacles into whom we insert this list of what they are required to build.
• The requirements, however, do not exist. But the requirements, like everything else of value, are just made up by someone. They are not first known and then told. They are invented.
• When you make stuff up as a software designer, that world, like the world of the movie into which you posit a character with a conflict, is your context. It’s the place where you posit signs that have meaning in relation to one another. It’s your semantic field.

Semantics and Software Architecture

• Semantics, as a field, is concerned with the production of meaning, and how logic and language are used. It is “the linguistic and philosophical study of meaning, in language, programming languages, formal logic, and semiotics. It is concerned with the relationship between signifiers — like words, phrases, signs, and symbols — and what they stand for in reality.”
• This precisely describes the role that architects designers should be playing, the kind of work they should be doing. The logic demanded by the compiler and the business requirements remain logical problems, set theoretical problems.
• Everything the developer does is expressed in language: semantics = logic + language
• That sounds exactly like the work we do when we are allowed to do our best work as software developers.
• The problem with software — a chief reason our projects fail — is a failure of our language.
• Our only material is that of language and ideas, names and meanings, signifiers and signifieds. Our only material is semantics. When we design software we are designing the semantics of a demarcated field of signifiers and signifieds.
• The semantic field comprises the set of sets of interplaying linguistic terms that form the idea our software represents from a comprehensive systems view. It’s the nouns and verbs in your domain, how they relate, and how in your software system design that complete set of ideas acts as an overlay representing the “real” world.
• To perform semantic software design, you perform these steps:
  1. Define its semantic field.
  2. Produce your concept within it.
  3. Deconstruct the concept to improve it.
  4. Design the system according to the deconstructed concept and its semantic field.
  5. Write the software and realize the attendant systems and processes.

The Semantic Field

• A proposition is a declaration about what is the case. It represents the set of possible worlds or states of affairs in which it obtains truth-value, in which it is true.
• Representing some aspect of the actual world in its true propositions is the work of the software designer.
• We carve out a space from that infinite conjunct of propositions representing the world. We create a boundary separating the scope of our software, its domain, from the rest of the universe.
• The main thesis of this book is that software fails because of improper understanding of the world, because of an improper understanding of our role — we have thought we were engineers and architects instead of philosophers and semanticists — and this results in unclear objectives, undue complexity, incorrect and changing requirements, lack of alignment, lack of focus, wasted effort, churn, and disarray — many of the top reasons the McKinsey report states that software projects fail.
• Software is a linguistic and logical endeavor. If we think we are the semanticists or philosophers of our systems, we will make better language and use better logic. And because those are the only tools of software design, our software will be better.
• Thinking only from our own perspective as computing practitioners leaves our design tepid, derivative, inefficient, incomplete, untrustworthy, unstable, and costly to expand and maintain. We must begin with the concept. The concept must support integrity and harmony. It must provide for, as Vitruvius asserts, the three critical components: stability, utility, and beauty.

What Is a Concept?

A concept is a complex idea consisting of compounded abstractions over a variety of related ideas. A concept is an interpreted representation of some aspect of the world. Concepts are not facts. They are attempts to explain something.

• A concept is non-obvious. It’s a complex of ideas and abstractions mixed with judgments. It is the product of thinking. A simple and direct referent is not a concept.
• A concept can be argued against. A reasonable person could argue that your concept is incorrect, that your representation is incomplete, shoddy, or misguided. This is an easy test to see whether your concept is forming. If no one would argue the opposite of your statement, you haven’t done anything but cheer a marketing slogan.
• Accomplish, Avoid, Fix: to be useful in a typical software project, your concept will generally be about one of three things: accomplishing something, avoiding something, or fixing something.
• In summary, a rough guiding outline for how to work with your concept at this early stage is as follows:
  1. Concept statement: A single sentence or phrase. This is like the melody of a tune you can hum. It’s not the whole song; it’s a memorable image that helps you communicate the basic subject.
  2. Statement of need: Captures who wants what by when for what reason. This ensures that you are striking the right balance between being creative and curious and not going off on a tangent that has no business value. Who are the customers, end users, business partners, and internal executives who stand to benefit — or could stand in the way?
  3. Alignment with strategy: You will have a greater chance of relevance, impact, and support if it is very clear that your concept relates and advances at least one element of the business and technology strategies. You should identify this explicitly.
  4. Idea components: These are the highly cohesive idea components that work together to form the concept. Consider them each through the lenses of People, Process, and Technology.
• Our work is to produce a concept. That concept produces a system design. That system design is comprehensive to create the best context for writing valid and sound requirements, both functional and nonfunctional, and for allowing them to be viewed together.

Understanding Ideas

• Our software projects are filled with the words of the requirements, the words of the design, and the words of the code. We must be crystal clear (as much as possible) that we are saying what we mean.
• Metacognition: one of the most important skills you can have as a designer is to cultivate your metacognitive ability. You notice yourself thinking about how you think, as you do it. You see not only your concepts, but you form more complex concepts and notice the manner in which you constructed them.
• Being in a dialog with yourself as if you were two people, perhaps arguing, will help you to quickly shape nothing into something. And that “something” will be better, more interesting, higher performing because you are considering it more carefully, more richly, with fewer assumptions and biases.
• Criticize your own mental processes: Stand back and observe how you intake data, from where, and why.
• We cannot conceive of all the things. We cannot include all that we can conceive of. At some point, we must stop and make a compromise. Make these moments of compromise conscious, and this will mitigate the blow of the lie we’re telling our system about its origins and context.

Context

• There are only two kinds of problems in the world: trivial and nontrivial. A trivial problem is straightforward. Its cause is direct, simple, and obvious. Its span of influence is small.
• These are simple systems and the behavior of the constituent elements of simple systems is predictable.
• A nontrivial problem is almost always more complex than at first it seems.

Deconstruction and Design

• We create accidental complexity when we focus improperly on simplicity.