As it’s safe to assume that a primary objective of process analysis is to align business concerns (by nature specific and changing) with enterprise architectures (meant to be shared and stable), events could provide a good starting point.
Business Analysis & Application Design
Taking example from the convincing track record of object oriented approaches for systems architectures and software design, the same principles have been tried for business requirements analysis. While that approach can be credited with significant realizations, success usually depends on some prior alignment of business domains with their system counterpart, in particular on the possibility to uniformly and consistently identify and define business entities as objects independently of operating processes.
Alternatively, when business entities cannot not be readily identified upfront as system objects, analysis may start with organization, entitled agents, activities, and be carried out with the definition of business flows and associated entities.
So, and whatever the approach, the question is how to ensure that the applications under consideration are designed in accordance with architecture capabilities.
System Architecture & Software Design
Words are worth the difference they make: as long as systems were not much more than an assortment of software modules, architecture and design could be understood as one and the same. But nowadays a distinction may be overdue between, on one hand the design of software components run within a single system’s address space and time-frame and, on the other hand, architectures of systems set across different spaces and time-frames.
Object oriented solutions (e.g Domain Driven Design) are arguably the option of choice for the former, but services oriented approaches may be a better fit for the latter. Not by chance, events provide a sound conceptual hinge between the two approaches.
Event Oriented Analysis vs Object Oriented Design
Object oriented principles can be streamlined around three core topics: (a) information hiding and coupling between structures and methods; (b) inheritance between types; (c) communication through interfaces and polymorphism.
Of these, encapsulation and inheritance are specific to software design, but communication mechanisms are also at the core of services oriented architectures. Considering messages as the logical system counterparts of business events, event-oriented analysis should help to align business processes with systems capabilities.
From a business processes perspective, events are signaling changes in the states of activities, objects, or expectations. Given that supporting systems are meant to deal with those changes, the analysis of business requirements could proceed from corresponding events:
- Business events are defined with regard to time-frames (a) and sources to be authenticated and authorized (b).
- Triggering changes must be described by messages with regard to their functional (c) and operational (d) scope.
- Business logic (e) and entities (f) are often shared across applications and therefore better defined independently.
- Internal changes (same space and time-frame) are hidden.
- Triggered (external) changes are defined with regard to time-frames (h), processes (d), and devices (g).
As it happens, those facets can be aligned with OO design ones, with (c) and (d) for communication, (e) and (f) for encapsulation. On a broader perspective they also fit with the growing focus on event-driven applications and service oriented architectures.
From Event Oriented Process Analysis to Service Oriented Architectures
By moving business logic to the background, event-driven analysis fosters polymorphism at enterprise level with corresponding benefits:
- With regard to business processes, events come with functional and operational requirements set independently of the business logic that will be carried out: trigger (what has changed), role (who is requesting), and message communication semantics (when the system is supposed to deal with the event).
- With regard to system capabilities messages can be used to align business (aka external) events with system (aka internal) ones independently of the business entities and logic (what is to be done and how).
- With regard to architecture and design, that approach is to uphold OO principles by dealing separately with polymorphic requests (interfaces) and business logic (methods).
Those benefits appear clearly when capabilities are realized by services defined with regard to business processes (customers), business objects (messages), business logic (contract), and business operations (policy).
It must be reminded that services are part of functional architectures and as a consequence cannot be directly addressed by users or devices.
Events & Action Semantics
With events set as modeling anchors, use cases may provide the modeling glue between processes and functional capabilities:
- Triggering events (a) map changes in business environments (aka external events) to changes in systems objects (aka internal events).
- Actors (b) map roles in organization to system users.
- Messages (c) map the semantics of business processes to the semantics of applications (e) and domains (f).
On that basis, the main objective of event-oriented analysis would be to distinguish between communication and business semantics, the former dealing with interactions, the latter with business logic.