In evolving from web sites to systems (and corroborated with some good ol’ book learning) we developed a foundational architecture to express the workings of organizations per se as data and interface. These interfaces provide elegant intermediation between people and the items they work on or use. Realized on the powerful shoulders of open-source software, Engaging OS is an enterprise engine that powers modular, layered work systems. 

Small- to medium-sized organizations tend to operate and manage their various domains using a mix of bespoke, off-the-shelf and SaaS software products. There are clear attractions to this à la carte approach: 1) reduced investment, together with 2) the possibility of getting best-of-breed software for each domain. The disparate systems can be orchestrated, which may arguably be the main task for in-house teams today. But even in the best case this cobbled-together aggregate will be disjointed and awkward. More likely, the systems will be siloed, hindering communications and planning, degrading both operations and management, and ultimately the organization’s effectiveness.

Yet there is no reason that an entire organization’s activities cannot be mapped to a data architecture implemented on a single database and handled by an overarching, integrated system. Historically, such systems have been the purview of large organizations and supplied by hefty vendors such as SAP — and more recently by Oracle and Microsoft after some corporate acquisitions — under the term Enterprise Resource Planning (ERP).

One disadvantage of these incumbent ERP systems is their price tags. In his book Enterprise Ontology, Jan Dietz writes:

The implementation of an ERP package in an enterprise, even of only a few modules, may easily take several years and cost the enterprise a huge amount of money. This money is partly spent in having the supplier of the package (or some intermediary company) explain how to use it but mostly to have the enterprise adapt its current way of working such that it fits the straitjacket of the ERP package. Is this social progress? Do we need to suffer this?

Coming up behind these top-tier vendors are a number of less expensive products, among them Odoo, Zoho and Hubspot. Founded in 2005, Odoo balances open source and enterprise. Unlike the ERM giants, it’s inherently extensible, with a large community of developers, so that with some work the organization need not bend to the software.

Engaging OS is a more modern take on this approach. By leveraging a layered architecture, Engaging OS provides the efficiency and economy of an underlying enterprise engine as layer #1; the ease of extant modules to immediately provide most of the functionality needed as layer #2; and the benefits of bespoke development from modeling your organization as layer #3.

Engaging OS is open-source, as are all the proven yet cutting-edge components of its software stack: Directus on the backend for data management with a PostgreSQL database (Directus's software license requires payment by organizations with over $5m total annual income), and Nuxt on the front accessing the backend via GraphQL using Apollo.

Both Engaging OS and the components of its software stack are deliberately thin layers; Directus is a thin layer over the underlying database; Nuxt is a thin layer over Vue, which is a modern reactive library for JavaScript, the language of the browser (and more recently, also of the server); and Engaging OS can be extended by a Nuxt developer. It adds a relatively small number of database tables (SAP, according to Paul Byrne of Dragon ERP, has some 120,000) and two types of web pages in order to provide its power. A competent developer should be able to understand it top to bottom, from HTML selectors to database fieldnames.

To build your system on Engaging OS, we seed it with your data based on consulting with you on your personnel structure and operational processes. We configure and develop instances of the two types of Engaging OS screens for your various users to interface with the system; screens are styled to express your brand and values. The result is a supple, integrated, extensible digital solution — hopefully with some personality — that can power just some or all of what you do — even including your public-facing website.

We need roles (and policies and attributes)

A work processing system maps the organization it serves, and all organizations are inherently role-based, wherein people are assigned to positions, each position having a number of responsibilities. To configure your system we recast these responsibilities into access policies that define how the system presents itself to people and how they interact with it.

Or, as Jan Dietz puts it in his book Enterprise Ontology:

The operation of an enterprise is constituted by the activities of actor roles, which are elementary chunks of authority of responsibility, fulfilled by subjects ... By performing production acts, the subjects contribute to bringing about the goods and/or services that are delivered to the environment of the enterprise.

In 1992 at the 15th National Computer Security Conference, David Ferraiolo and Richard Kuhn submitted a paper entitled “Role-Based Access Controls”. In 2004 this concept became a US standard, the NIST RBAC model. Providing people with access to a system based on their role within that system rationalizes and simplifies the reasoning about and management of that access. Nothing happens unless through a role.

Since then, role-based access control (RBAC) has grown to become attribute- and policy-based (ABAC and PBAC) in order to more powerfully (via attributes) and easily (via policies) express the privileges that a role-holder possesses. 

In Engaging OS, a role is a time-based holding of a position within an organization by an individual. A position is comprised of three types of rights:

• consoles to navigate among ports
• ports to interface with items as set by policies
• the abovementioned policies to act within ports on items according to various attributes such as conditions

A person can hold any number of roles. Organizations can encompass other organizations; ditto for both positions and policies. Tasks are composed of whichever actions can be performed on each type of item depending on various conditions, most importantly its status, though also depending on environmental variables such as dates.

Positions need not be limited to employees of the organization; they may well be for customers or other external people.

No process, no profession

A business process is a repeatable series of tasks that various people in an organization perform in order to transform an item from its initial to its completed state; processes are how enterprises work. Whereas roles are about who does what in an organization, processes are what they are collaborating on to accomplish (indeed, one term for our type of system is Collaborative Work Management).

Business process management (BPM) has its own language, a standard called BPMN (Business Process Model and Notation), along with its companion DMN (Decision Model and Notation). These standards are intended to provide a common frame of reference regarding processes for both businesspeople and software developers.

While BPMN is designed to be executable, Engaging OS is not a BPMN-executing workflow engine such as Camunda. Instead, we only use BPMN as a spec, preferring to handle processes using a simpler method: by setting position privileges to enable people to play their roles, and by changing the status of an item undergoing processing in order to move it along from its initial through its interim states to its final state.

Ironically, one benefit of this method over executable BPMN is that it forces the unique labeling of each action and status, potentially enabling a better common frame of reference for businesspeople and software developers. Each of these labels contributes to what Eric Evans refers to in his seminal book Domain-Driven Design as the project’s Ubiquitous Language.

Why management?

The question is not whether but how to have a work management system. WiIl it be jiggered together from various parts? Or bent to the notions of a vendor larger and more powerful than the organization itself? Perhaps it is merely an implicit system based on whatever some staffers maintain in their heads or have devised themselves.

In Clean Architecture: A Craftsman's Guide to Software Structure and Design, Robert C. Martin writes that architectures should be as shape-agnostic as is practical. This is so with Engaging OS, where a constellation of organizational primitives — positions, roles, consoles, policies, ports and collections — is cast into a dynamic model of the organization’s activities. And this dynamic model in turn casts a software stack into a system used by everyone in the community, each according to their role.

Why Engaging?

Eric Evans writes:

To have a project accelerate as development proceeds — rather than get weighed down by its own legacy — demands a design that is a pleasure to work with, inviting to change. A supple design.

When you hire Engaging to build an Engaging OS work processing system, you are gaining the insight, experience, and instinct for supple architecture that identified and orchestrated the organizational primitives into a generalized, adaptable system.

With the advents of web reactivity, componentization, and the remarkable assistance of generative AI — not to mention the insights that coalesced into Engaging OS — it has become easier and less expensive than ever to design, develop and maintain fully-fledged extensible systems.