As promised, I'll write some issues related to event modeling, which is my current focus of interest.
The current thinking on event processing and actually on some related areas (such as BRMS), and also reflected in Luckham and Schulte's article on event models is that the first step is to build the data model, and then model the logic on the basis of the data model. According to this methodology there is a need to model the used data and events, sometimes also modeling "business objects" that maybe created from the original data or events. When modelling the logic it always relies on the existing events and data already modeled. This is a "bottom up" approach.
A major issue with this methodology is that it moves the modeling immediately to the IT domain, since business users can relate better to goals, processes, and business logic then to data models. Keeping the modeling in the level of business require to reverse the process, model the business logic first, and leave the data and events as "place holders" which need to be completed later in the process.
A top down modeling is also reflected in that article when the phase of "identify the complex events" precedes the phase of "identify base events". I think that in the business user's terminology it is better to talk about situations that need to be reacted upon then on "complex events" that is more technical (and somewhat ambiguous) term. Of course, modeling is an iterative process, since when getting back to the base events or data, a gap (e.g. event that is not being observed) might be discovered. Thus it seems that the methodology should be: start top-down (goal oriented) and tune up bottom-up.
More on event modeling issues -- later.
2 comments:
Hello Opher,
based on my project experience a business user can definitively describe the business objects he is working with. The design might be rather on a spread sheet than on an accurate model (e.g. UML, ERM, ...) but it contains usually all attributes he requires to conduct his business.
I have to admit, that it might become easier to design business objects when actually talking about the actions you require the objects.
Kind regards,
- Christoph
Without an Event, there is never a need to know about Data.
This becomes apparent when engaging with communities that have no notion of Data, but have a notion of an Event.
By modelling an organization by their Events (that is stuff happening, jobs that need to get done etc, the 'verbs'), chances are better to maybe see/allow for emergent designs to evolve over time, for Data Models, Process Models, Object Models, UI models .. while discovering newer Events .. an endless feedback loop ...where the focus is more on the 'verbs' that the organization focuses on for efficiencies/profitability/growth over time ..
Eventually leading to a fluid architecture ..
Post a Comment