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.
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.
Still milking the OS analogy, a primary goal of an enterprise kernel is to support a seamless integration of services:
- Business driven: the definition of services must be directly and unambiguously associated to business ends and means across enterprise layers.
- Traceability: they must ensure the transparency of the tie-ups between organization and processes on one hand, information systems on the other hand.
- 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.
- Modeling Paradigm
- Building a bridge
- Caminao Charter
- 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
3 thoughts on “Enterprise Systems & the OS Kernel Paradigm”
I agree with Remy. The most massive duplication of effort in our industry is every development team designing a user interface and an application framework to support it. As a result, every user interface is different, security systems are getting created to different standards and we keep reinventing the wheel over and over.
The extended affect of this is no ability to create functionality once and apply it in every system that uses the same framework because it is almost a one to one ratio between unique application frameworks and systems.
The basic objective of the Caminao framework is to demonstrate how a small and consistent set of concepts can help to understand and deal with the whole of systems engineering issues. So, while being adequately descriptive helps, the endgame is about being functionally effective all over the board.
Interesting idea – Lord knows enterprise architecture is serious need of a good shave.
I think the way you are using the big concepts (platform, system, enterprise) needs a little work.
Remember Einstein’s ‘corollary’ to Occam’s razor > Things should be a simple as they can be, but not simpler.
Re-theorising enterprise architecture requires resolving some issues between ontological, mereological and social function.
We can’t trade fidelity for formality. A functionally closed and deterministic system model (the OS), is attractive for its ultimate simplicity – but is it adequately descriptive?
I niggle – this is some nice thinking on how to draft a simpler and more elegant model of an enterprise.