The Software Product
Software can be classified in many ways, and is helpful to do so because it can hide uninteresting or unimportant details about them. This is called abstraction, and classification is one type of it. It is sometimes helpful to think of abstraction as an amplifier of attributes rather than a concealer. Intuitively, we recognize this because as unimportant attributes are hidden, it retains those properties that otherwise would've been lost in the noise.
Stakeholder Groups
Every software has at least one stakeholder, arguably the developer that wrote it. But of course, the number and types of stakeholders that software has can vary. A program may just have one compared to the many that a banking app may have.
Additionally, we can classify stakeholders into groups based on their orthogonal interests or concerns. In other words, we can establish stakeholder groups based on their (mostly) non-overlapping interests in the software. And, it is this very perspective on software that makes stakeholder groups an important attribute about software.
Triviality
Software can be bi-classified as being trivial or non-trivial according to its attributes such as utility and complexity. But, those attributes can be loosely aggregated into a single one: the number of stakeholder groups. Consider, that as the software becomes more useful, the number of people interested in it will rise because there will be more that want to use, monetize or buy it. Likewise, as the software becomes more complex, perhaps correlated with its utility, the number of people required to construct, support or maintain it will also grow. So, software becomes less trivial as the number of stakeholder groups grow.
Software Product
The Software Product is a type of non-trivial software that has exactly three (direct) stakeholder groups. The "product" moniker implies that this type of software has sufficient utility or complexity to warrant the expenditure of time, money or other resources. It is also a tribute to Fred Brooks who calls it "programming product" in his book Mythical Man-Month. Perhaps, when you reflect at the software that you yourself work with, you can also appreciate the product label.
The software product has exactly three stakeholder groups which are the owners, architects and engineers. This is very much a tribute to John Zachman who refers to them as owners, designers and builders. There is full parity between these labels but I find architect and engineer apropos to the activities required to map models. Mapping models is a topic covered in another edition.
Recommended by LinkedIn
It should be noted that there is a dependency between these stakeholder groups: the architect depends on the owner, and the engineer depends on the architect. Of course, teams and organizations will staff their 'products differently. It is very much possible that these stakeholder groups are played by overlapping people.
Lastly, software can indeed have other stakeholders albeit with indirect concerns. Their interests are aimed at the final software product, such as its delivery. These may include stakeholders interested in its implementation, governance or planning. In the formation and classification of the software product, the direct stakeholder groups are sufficient.
Models
A model organizes, structures or aggregates information to better rationalize the subject. And, in this rationalized form, allow for others to share in its knowledge. Considering that a software product has three stakeholder groups, owners, architects and engineers, we can conclude that there are also three models, one assigned to each stakeholder group. As Zachman frames it, these are the conceptual, logical and physical models, respectively. And just as there are dependencies between stakeholder groups, there is also an implied dependency between these models. That, the logical model depends on the conceptual model and the physical model depends on the logical model.
In a future edition, I will cover the ontology behind the software product. You would guess correctly that it would surely include the conceptual, logical and physical models.
This edition is a part of a white paper. You can read it in its entirety here: