Enterprise Systems & the OS Kernel Paradigm

Preamble

Given the ubiquity of information and communication technologies on one hand, the falling apart of technical fences between systems, enterprises, and business environments on the other hand, applying the operating system (OS) paradigm to enterprise architectures seems a logical move.

Borrowing the blueprint of computers operating systems, enterprise operating systems (EOS) would  be organized around a kernel managing shared resources (people, hardware and software) and providing services to business, engineering or operational processes.

Gerrymandering & Layers

When IT was neatly fenced behind computer screens managers could keep a clear view on organization, roles, and responsibilities. But with physical hedges replaced by clouded walls, the risk is that IT may appear as the primary constituent of enterprise architecture. Given the lack of formal arguments against what may be a misguided understanding, enterprise architects have to rely on pragmatic answers. Yet, they could prop their arguments by upending the very principles of IT operating systems and restore the right governance footprint.

To begin with, turfs must be reclaimed, and that can be done if the whole of assets and services are layered according to the nature of problems and solutions: business processes (enterprise), supporting functionalities (systems), and technologies (platforms).

Then, reclaiming must also include governance, and for that purpose EOS are to rely on a comprehensive and consistent understanding of assets, people and mechanisms across layers:

• Physical assets, including hardware.
• Non physical assets, including software.
• Agents (identified people with organizational responsibilities) and roles.
• Events (changes in the state of objects, processes, or expectations) and activities.

Mimicking traditional OS, that could be achieved with a small and compact conceptual kernel of formal concepts bearing out the definitions of primitives and services for the whole of enterprise processes.

EOS’s Kernel: 12 concepts

A wealth of definitions may be the main barrier to enterprise architecture as a discipline because such profusion necessarily comes with overlaps, ambiguities, and inconsistencies. Hence the benefit of relying on a small set of concepts covering the whole of enterprise systems:

• Six for individuals actual (objects, events, processes) and symbolic (surrogates objects, activities, roles) elements.
• One for actual (locations) or symbolic (package) containers.
• One for the partitioning of behaviors (branch) or surrogates (power type).
• Four for actual (channels and synchronization) and symbolic (references and flows) connectors.

Considering that nowadays business entities (enterprise), services (systems), and software components (technology) share the same distributed world, these concepts have to keep some semantic consistency across layers whatever their lexical avatars. To mention two critical examples, actors (aka roles) and events must be consistently understood by business and system analysts.

Those concepts are used to describe enterprise systems building blocks which can be combined with a small set of well known syntactic operators:

• Two types of connectors depending on target: instances (associations) or types (inheritance).
• Three types connections for nondescript, aggregation, and composition.

Again, Occam’s razor should be the rule: just like semantics are consistently defined across architecture layers, the same syntactic operators are to be uniformly applied to artifacts independently of their semantics.

Kernel’s Functions

Continuing with the kernel analogy, based on a comprehensive and consistent description of resources, the traditional OS functions can be reinterpreted with regard to architecture capabilities implemented across layers:

• What: memory of business objects and operations (enterprise), data base logical entities (systems), data base physical records (platforms).
• Who: roles (enterprise), logical interfaces (systems), and physical entry points (platforms).
• When: business events and processes (enterprise), transaction management (systems), and middleware (platforms).
• Where: sites (enterprise), logical processing units (systems), network architecture (platforms).
• How: business processes (enterprise), applications (systems), and programs (platforms).

That fits with the raison d’être of a kernel which is to combine core functions in order to support the services called by processes.

Services

Still milking the OS analogy, a primary goal of an enterprise kernel is to support a seamless integration of services:

1. Business driven: the definition of services must be directly and unambiguously associated to business ends and means across enterprise layers.
2. Traceability: they must ensure the transparency of the tie-ups between organization and processes on one hand, information systems on the other hand.
3. Plasticity: they must facilitate the alignment of changes in business objectives, organization and supporting systems.

A reasoned way to achieve these objectives is to classify services with regard to the purpose of calling processes:

• Business processes deal with the transactions between the enterprise and its environment.
• Engineering processes deal with the development of enterprise resources independently of their use.
• Operational processes deal with the management of enterprise resources when directly or indirectly used by business processes.

That classification can then be crossed with architecture levels:

• At enterprise level services are bound to assets to be used by business, engineering, or operational processes.
• At systems level services are bound to functions supporting business, engineering, or operational processes.
• At platform level services are bound to resources used by business, engineering, or operational processes.

As services will usually rely on different functions across layers, the complexity will be dealt with by kernel primitives and masked behind interfaces.

Finally, that organization of services along architecture layers may be aligned with governance levels: strategic for enterprise assets, tactical for systems functionalities, and operational for platforms and resources.

Further Reading

• Modeling Paradigm
• Building a bridge
• Caminao Charter
• UML#
• Objects & Aspects
• Caminao & Archimate
• Modeling languages: differences matter
• Architecture Capabilities
• Capabilities vs Processes
• From Processes to Services
• Alignment for Dummies
• Alignment: from Entropy to Abstraction
• Knowledge Architectures
• Enterprise Architectures & Separation of Concerns
• Enterprise Governance & Knowledge
• EA Documentation: Taking Words for Systems
• Abstractions & Emerging Architectures
• Events & Decision-making