2008/6/23 Rob Eamon <[EMAIL PROTECTED]>: > --- In service-orientated-architecture@yahoogroups.com, "Steve Jones" > > <[EMAIL PROTECTED]> wrote: >> >> I agree that Business Events are important, and on occasion I've >> used them to help identify the _real_ (as opposed to imagined) >> business services. > > +1 > > That's one of the pros of event analysis. > >> What I have tended to find however is that if the events don't have >> a clear business service that drives them and an equally >> clear set of services > > (Assuming one is creating an SO BA.)
Or a Value Network one (I'm really struggling to spot the difference right now). > >> that are interested in them then the events themselves become more >> of a problem than an opportunity. > > As you point out below, the identification of events without an > obvious home aren't the problem. It tells you where your service > analysis is lacking. Or to be more accurate it told us that there were people we should be speaking to who were not engaged. This was mainly because IT had never come into contact with them before. > >> To take your retail example I've had experience where "Store >> planning" hadn't been clearly identified but the "store open" event >> had been, this led to a slightly odd concept of an event linked to >> a physical building and a specific system being proposed to notify >> other systems... then we went to the pub and thought "hang on >> someone must know this stuff" which they did but mainly used Excel >> spreadsheets to do the planning and commissioning and then a set of >> emails to spread the info around. >> >> In other words they already were event driven and the other >> departments reacted from the events, the key was therefore to either >> automate that process or to better facilitate the current manual >> process. Adding in Store planning to the architecture however made >> ita lot clearer who owned new stores and who created those business >> events. > > Event analysis helped in this case, correct? > > This is something we touched on a few months back. From your comments > above, it appears you feel events fall out of service analysis. An > *explicit* event analysis identifies important events which in turn > will be linked to already identified services (if one is doing SO- > driven BA) or will help identify overlooked/missed services. Nope I think that Events are one of the ways that the "Why" (the interactions) of SO driven BA should be described. The way the event was found was that we had a capability on the service but no "other end" to the "why". The Events (and other interaction models) are the lines between the services, this means they are very much part of SOBA and fit nicely within the overall context. So event analysis certainly helped and it helped because it was within a consistent context. > >> The final piece in a system I worked on (not retail) was the >> creation of "virtual services" which were effectively an >> amalgamation of disparate events into a cohesive business service >> _which didn't exist_ this made it easier for people to consumer the >> events (they saw it as a central service) and very easy to create >> (it was just a broker transformation) this was pretty much pure EDA >> from an implementation perspective but from a business perspective >> it was a business service, this had the advantage of making it >> architecturally consistent and made adopting EDA seem simpler than >> if we'd either explained where all the messages came from or just >> waved our hands and said "its magic". > > So you are more effective at explaining services than you are at > explaining events. ;-) ;) > > Managing events via services, and creating faux services when > appropriate, seems a natural fit. EDA and SOA fit together quite > well. But I think it is important to still address events explicitly > even if service analysis drives out many/most of the important events. I think its important to address _all_ interactions explicitly and that some of these will be events, the process I do has only three parts "What" - The services "Who" - external actors (including external services) "Why" - reasons that they interact The Why is all about the interaction part and its that part of the analysis that EDA comes into, often highlighting more "Who" and "What" examples (especially "Who" IME). Steve > > -Rob > >
