Small to medium-sized organizations today tend to utilize a mix of bespoke, off-the-shelf and SaaS software products to handle various aspects of their operations. There are of course important benefits to this piecemeal approach, such as the possibility of getting best-of-breed software within each area and reducing the need for in-house software expertise. But the inescapable drawback is that each employed system is a silo. Siloed systems are not a system, merely an aggregate. They hinder communications and planning, degrading both operations and management, and ultimately the organization's effectiveness.
Yet there is no technical reason why 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?
Chasing these top-tier vendors are a number of less well known similar systems, chief among them Odoo. But just like their betters, they’re designed to be used as-is rather than being inherently extensible; the organization must bend to the software rather than vice versa, the focus tending towards the functions common among all large businesses — finance and accounting, procurement, manufacturing, sales, customer relationship management, human resources management — rather than towards an organization's particular activities.
In contrast, from experience gained producing web sites and web-based systems (and corroborated with some book reading) we have developed — or perhaps more accurately discovered — a foundational data and interface architecture that reflects the workings of organizations per se. These are not the functions but the primitives of an organizational system — the foundational building blocks of any organization as mapped to data architecture and to the onscreen means of accessing and transforming that information.
We’ve applied this paradigm to create the Engaging OS enterprise engine — an extensible, flexible, powerful foundation for work processing systems that power organizations.
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 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.
While Engaging OS does have modules like other systems, starting with EngagingEvents, these are jumping-off points for your system, rather than what you must learn to live with. These too are thin; our programming environment is not a proprietary system; it is Vue and the huge open ecosystem of JavaScript libraries, which can be added to the system with merely an NPM install and a line of import code.
To build your system on Engaging OS, we seed a fresh install with data to model your organization, consulting with you on your personnel structure and operational processes. We configure and develop instances of our two types of screens for your various users to interface with the system; screens are styled to express your brand and values. The result is an integrated, extensible digital solution with personality that can power just some or all of what you do — even including your public-facing website.
Such a work processing system modeled on your particular operations can be expected to be both leaner and cheaper than an Enterprise Resource Planning setup, and more powerful and flexible than the outcome of a low-code or no-code platform.
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. These responsibilities are what defines 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, from RBAC have grown ABAC and PBAC, attribute- and policy-based access controls, because in order to most easily manage the privileges that a role-holder possesses, as well as to articulate those privileges more granularly, they are best defined via policies comprised of various attributes.
In Engaging OS, roles are time-based holdings of positions within an organization by individuals. A position is comprised of three types of rights:
- consoles to navigate among ports
- ports to interface with items as set by privileges
- the abovementioned policies to act within ports on items according to various 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 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.
It is through this role-&-attribute-based architecture that Engaging OS models the organization's activities.
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 outcomes (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 all actions and statuses, potentially enabling a better common frame of reference for businesspeople and software developers.
Why management?
Digital management systems now encompass not only supervision and planning but also implementation and operations; they are about managing not only the organization but handling each activity that the organization performs.
The question is therefore 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.
With Engaging OS, organizational primitives are applied to cast a dynamic model of your organizational activities into a system that everyone in the organization uses according to their role.
Why Engaging?
When you hire Engaging to build an Engaging OS work processing system, you are leveraging the insight and experience 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, it has become easier and less expensive than ever to build fully-fledged extensible systems.