Preamble
The aim of enterprise architectures is to weave together organization and systems in support of business objectives. To that end enterprise architects must balance changes in competitive environments with the sustainability of organization and systems.
That pivot can be best achieved through principled hinges joining actual business environments and processes (territories) to serviceable symbolic representations (maps). Such hinges are can be defined with regard to three core issues:
- The nature of the footprint of objects and activities: business, symbolic, physical
- EA behavior with regard to environment: passive, reactive, proactive
- The nature of communication and collaboration between environment, organization, and systems: digital, symbolic, natural
To maintain a degree of ecumenism stereotyped issues are described with the OWL kernel (as presented in EA in bOwls), with a clear distinction between OWL’s native hierarchies and kernel’s specific connectors:
- OWL hierarchies (yellow color) are deemed as purely conceptual, bearing solely on the meaning of terms independently of the nature of abstraction or inheritance between artifacts. They will be typically used to describe issues and illustrate taxonomies.
- Kernel connectors (blue color) come with explicit semantics about the nature of generalization and specialization between abstraction levels as well as associations between representations. They will be used to describe patterns.
Footprints: Business, Symbolic, Physical
Enterprises operate in physical or symbolic environments that can be perceived and acted upon. A primary concern for enterprise architects should therefore to define and manage capabilities according to the nature and identity principle of objects and processes.
Objects, Agents, Locations
From an EA perspective, objects should be characterized by their identification footprint:
- Business: instances identified in business environment
- Symbolic: instances identified within organizations
- Physical: instances directly identified in physical environments through system interfaces
That taxonomy can be used to characterize typical configurations with regard to identification (#) and associated management (+) :
- Physical objects identified at the business level, e.g., Cask (a)
- Physical objects identified at the enterprise level, e.g., Printer (b)
- Symbolic objects identified at the business level, e.g., Reservation (c)
- Symbolic objects identified at the enterprise level, e.g., Inventory Item (d)
- Symbolic objects identified in environment, e.g., Product Reference (e)
- Physical objects identified at the platform level, e.g., Oven (f)
Besides typical issues, that taxonomy makes room for specific ones, e.g.:
- Non-sortal (or non-countable) physical objects, e.g., rice or poultry, which cannot be directly identified at the physical level (Inventory Item)
- Objects identified and managed simultaneously as physical and symbolic entities (Cask)
- Social agents, for active objects defined independently of their physical or symbolic actuality
Locations, besides their identification as objects, can be defined as containers, with the footprint taxonomy applied to corresponding address spaces and time frames:
- Physical and digital: geographic coordinates and time zones
- Symbolic: calendars and logical address spaces, e.g., directories in systems
- Business: statutory calendars and organizational charts
As already noted for objects (Cask), the conceptual neutrality of OWL hierarchies enables twofold descriptions of locations, e.g., OperationalUnit≈ described in terms of both organizational and physical location.
Activities & Roles
From an ontological perspective activities are symbolic descriptions whose execution is represented by processes. With regard to the nature of activities, and to avoid confusion, the distinction can be put in terms of actual vs symbolic, the former involving the physical/digital environment, the latter limited to the symbolic/business one. Along that reasoning the taxonomy defined for objects can also be used to characterize the footprint of activities:
- Symbolic activities carried out in business environment and mirrored in systems e.g., BillCustomer (a)
- Symbolic activities, typically computations, usually but not necessarily performed by systems e.g., PrepareBill (b)
- Actual activities carried out independently of the business environment, e.g., PrintBill (c)
- Actual activities carried out across business and physical environments, independently of symbolic representations, e.g., PresentBill (d)
Circumscribing the footprint of activities can help enterprise architects to draw a line between activities that can be automated (no business footprint) and the ones involving business accountability, and thus to define roles.
Despite being symbolic descriptions, roles can be fulfilled by any kind of agent, symbolic or otherwise. So, in order to ensure the versatility and plasticity of enterprise architectures, roles should be defined independently of specific agents and/or activities. Yet, to enable consistency checks, a taxonomy of roles should be congruent with the one applied to activities and objects:
- Business: statutory or contractual roles defined in environment, e.g., Social Security Administration.
- Organization: subset of business roles defined at the enterprise level, e.g., Employee≈, Cook
- Symbolic: roles managed at the system level, e.g., ePayment System
- Actual: roles managed at the platform level, e.g., OvenPort
Connectors are used to tie roles to agents (connectRef#) and activities (connectExec#).
That taxonomy can help to refine EA assignments, in particular with regard to:
- Cloud services at the system level, physical ports at the platform level
- Statutory roles defined in environments, discretionary ones within the enterprise
Processes & Events
Since they are defined as the execution of activities, the taxonomy of processes should be defined by the taxonomy of carried out activities.
Conversely, to enable consistency checks with activities and roles, events should be explicitly characterized by their origin:
- Business: events generated by changes in statutory or contractual environment, e.g., EndOf Month≈
- Enterprise: events generated by changes in the state of business objects or agents’ expectations, e.g., CustomerRequest
- Processes: events generated by enterprises’ processes, e.g., PaymentAccepted
- Physical: events generated by changes in the state of physical environment, e.g., DataBreach
The nature and origin of event are especially relevant when events serve as roots (aka epochs) of time frames:
- Business: intervals set by statutory (external) calendars
- Enterprise: intervals set by organizational (internal) calendars, e.g., InventoriesPlanningTF
- Processes: intervals set by local (process internal) timer, e.g., ManageOrderTF
- Physical: intervals set by system clock, e.g., CookingTF
In order to enable the polymorphism of services the nature and origin of events should be defined independently of their meaning, and consequently of associated behaviors.
Behavior: Passive, Reactive, Proactive
EA relevant behaviors can be classified as passive, reactive, and proactive, depending on the tie-ups induced between enterprises and their environment. That taxonomy can be applied to objects and extended to activities, roles, processes, and events.
Objects & Locations
For enterprise architects behavior is best understood in terms of capability, and consequently a matter of design for:
- Passive objects, which can only report on queries (?) about their state, e.g., InventoryItem (a)
- Reactive objects, which can perform activities when requested (!), e.g., Order (b)
- Proactive objects, which can initiate activities without being requested, e.g., MotionDetector (c)
That taxonomy enables consistency checks when crossed with the corresponding ones for activities, roles, processes and events.
Activities & Roles
Besides the nature of the targeted environment (business, symbolic, or physical), a key architectural criterion for activities is the induced tie-ups with environment:
Designs along that taxonomy should lead to homogeneous activities matching Aristotle rule of three unities: action, place, time (APTUnit_).
- Passive (no tie-up): activities that don’t affect the relationship between enterprises and environment, e.g., PrepareBill (a)
- Reactive (logical tie-ups): activities that change the representation of environment without affecting the environment itself, e.g., InitOrder (b)
- Proactive (operational tie-ups): activities that induce synchronous changes in environment and enterprise, actual (PrepareDishes) or business (BillTable) (c)
The same taxonomy should be applied to roles in order to enable consistency checks with objects and activities:
- Passive: sources of information, for roles reporting on states (Employee≈)
- Reactive: contributing (or secondary) roles (connectRefer#), to be performed by agents when requested to do something (ePaymentSystem)
- Proactive: primary roles (connectExec#), to be performed by agents capable of requesting (triggering) activities (Cook, Waiter)
It must be noted that these characteristics can overlap.
Processes & Events
When applied to activities the behavior taxonomy considers functional contents, when applied to processes it considers execution control:
- Passive, for discretionary execution (passive activities)
- Reactive (observation), for execution triggered by changes in environments (passive or reactive activities)
- Proactive (action), for execution triggered by changes in representations (at least one proactive activity)
In contrast to their origin, the consequences of events cannot be defined unequivocally. Yet, constraints pertaining to architectural tie-ups should be clarified upfront:
- Passive, for atemporal events with no impact on architectural tie-ups
- Reactive, for asynchronous events (connectRefer#) which remain relevant until notified otherwise
- Proactive, for synchronous events (connectExec#) with direct and explicit time-dependant relevancy ()
Using connectors to characterize events’ capabilities makes room for business and system analysts to decide about meanings and implementations.
Communication: Natural, Symbolic, Digital
Organizations being at the nexus between systems and environments, enterprise architectures should be transparent about what can be done by systems alone, and what necessarily involves some accountable organizational unit. That is conditioned by the capabilities of communication channels.
Channels
EA communication channels determine what kind of messages can be exchanged between enterprises and their environment. Assuming that exchanges can involve humans, systems, or devices, the proposed taxonomy is distinguish between natural, symbolic, and digital communication capabilities:
- Natural communication is the default option at the enterprise level where no assumption is made about supporting systems. It supports the pragmatics of natural languages as well as the syntactic and semantic capabilities of symbolic ones; e.g., interviews (a)
- Symbolic communication is the default option at the system level. It can deal with any kind of representations built with well defined syntax and semantics: texts, documents, or models; e.g., collaborations in Service oriented architectures (b)
- Digital communication is the default option at the platform level. It can deal with the exchange of any kind of binary objects: media, executable files, or full applications; e.g., IoT (c)
That taxonomy enables consistency checks between communication channels and activities, e.g.,:
- Digital communication channels for Data and Process mining
- Symbolic communication channels for business processes and reasoning
- Natural communication channels for Knowledge management and Decision-making
On a broader perspective, patterns based on that taxonomy should facilitate the integration of systems and organization.
Organization
In fine, enterprise architectures should ensure the effectiveness and transparency of human and systems functions and responsibilities. That can be achieved by applying the communication taxonomy to associations between organizations and systems:
- Natural associations, for activities involving collaboration, authority and/or accountability
- Symbolic associations, for activities that could be carried out at the systems system and provide transparency and traceability
- Digital associations, for activities that could be carried out more effectively at the platform level
The benefits of that approach can be illustrated by applying it to the OODA pattern for decision-making:
- Observation, for the analysis of environments and operations: symbolic and digital associations
- Orientation, for the modeling of business objectives, processes, and supporting systems: natural and symbolic associations
- Decision, for activities involving authority and/or accountability: natural associations
- Actions, for direct enactments in business and/or physical environments: symbolic and digital associations