Before building anything, we must collaborate on modeling your organization’s activities. In doing so we develop a vocabulary for your system (one of the two hard things in computer science, as the saying goes, is naming things), aiming for it to be maximally thorough and unambiguous. As Eric Evans explains in his 2003 book Domain-Driven Design:

It is vital that we play around with words and phrases, harnessing our linguistic abilities to the modeling effort, just as it is vital to engage our visual/spatial reasoning by sketching diagrams.

Our method is what we call BOND (Business Operations Notation & Development). Within BOND we practice what we call Role & Port Modeling, as roles and ports represent the twin aspects of a system: Roles for who can do what, and Ports for where they do it.

We capture ideas for the blueprints by entering them into the Engaging OS platform itself, fulfilling one of the holy grails of software: being an executable model.

Our basic unit is the business operation. In Role & Port Modeling, as we think through your organization’s work, we jump around the constituent aspects of your business operations, namely:

• Positions capture everybody’s various job titles within the organization or part thereof that the system is intended to handle (ie, the subjects).
• Entity Attributes outline the characteristics of the widgets that the organization handles, mainly its products and services (ie, the objects).
• Actions & Statuses list the various verbs that people holding positions do to entities as part of their work, and what are the possible states of these entities.
• Conditions are the situations that determine whether the operation can actually take place. This is one of the places where functional complexity can grow.

As operations develop, we start seeing the necessary contours of the canvases where they are to be performed:   

• Screen Attributes & Wireframes sketch out the canvases where each user will perform these steps, and the ways to navigate to them.

We also start seeing how collections of business operations coalesce into processes, which are how the organization produces its work (or, if processes are already well-defined, we may discuss top-down rather than bottom up, ie from processes down to operations). Once Engaging OS has a collection of business operations defined as a process, it can generate on-the-fly process maps using the industry-standard BPMN notation, which serve as graphic documentation available to all stakeholders, ensuring that the system is focused on delivering the required functionality.

Note that the entity attributes and actions and statuses, in demanding that every facet of the system be labeled, help us communicate about the system.

Any and all issues uncovered later during implementation are treated as continuations of the discussion of the model and may modify it and the resulting system. As Evans writes:

These models are never perfect; they evolve. They must be practical and useful in making sense of the domain. They must be rigorous enough to make the application simple to implement and understand.

Modifying the model — and its notation within Engaging OS, which also serves as configuration — is just about as easy as is imaginable; this is soft software.