Stakeholders are persons or a group of people who have an interest or concern on the software product. Their interests can vary and they may have more than one interest.

In general, your stakeholders will fall under 3 groups: owners, architects and builders.

Loosely, we can think of Owners as those paying for the software, one way or another, directly or indirectly. In an enterprise, this may be your business organization or the product organization chartered to deliver business value. In a retail setting, this may be the users of your application.

Architects or software engineers are those that design the software. No, not just the user interface but the full stack. Architects come in many different roles such as business, enterprise, solution or application. At ArchMind, we think of software architects and engineers being the same type of role.

Builders are those that build, configure, integrate or otherwise implement the design. Generally, this is your technology team comprised of software developers, integrators, configurators or those that manage them.

Today, in some form, delivering software has a general flow from owners to architects, and architects to builders. Once requirements are gathered, in theory, architects design the required changes to satisfy them. From here, it's generally a one way 'street.' The architects' design flows down to the builders but not naturally back up to the owners.

It does flow back up to the owners, from time to time, but when it does, it is usually a practice of taking logical designs (system and flow diagrams) to create a document that makes sense to owners.

Moreover, during requirements gathering, it is seldom and hardly ever practiced where architects present options to the owners. Options are varying degrees of design that are driven by factors such as time, cost and resources. The architects' job should be to provide options to the owners.

Unfortunately, stakeholders rarely get a glimpse of the design or its options nor are they presented with options to choose from. This effectively disables them from being decision makers beyond the requirements that they provide.

To empower stakeholders, we must provide them a way to "see" the architecture and the design options.

Having a view into the architecture is not trivial. While its easier to just present them with some diagram, it is harder to make sure what they see, the Conceptual Model, is consistent with the architects' view, the Logical Model. Model consistency and precision is a required property of an architecture practice that wants to empower stakeholders.

Both precision and consistency is achieved by creating architectures centered around capabilities. Owners speak in terms of capabilities. And capabilities themselves can be composed with other capabilities. Capabilities describe some task that provides value to its consumer. This is the Conceptual Model.

Capabilities are intangible. To make them tangible, systems have to be designed to enable them. Additionally, each capability must provide one, and exactly one, system that enables it. Capabilities are therefore contained by logical elements such as Components that enable those capabilities. To create an effective logical model is to design a system of components that compose the same set of capabilities described by the conceptual model.

In other words, if looking at a logical model and you strip away all the containers (of capabilities away), what you should be left with is the conceptual model.