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. 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 that are interested in them then the events themselves become more of a problem than an opportunity. 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 it a lot clearer who owned new stores and who created those business events. A slightly more tangential one was the weather, weather can be viewed as a series of events that can impact your business, rain, flood, snow, wind, etc can all impact current sales and logistics so need to be considered by potentially multiple systems. 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". Steve 2008/6/21 Todd Biske <[EMAIL PROTECTED]>: > Just as some food for thought, I do think it is possible to apply EDA > concepts at a business level in the same way as we apply SOA concepts at a > business level. I don't think it provides as much value toward defining a > business architecture as a services view, such as Steve's Business Service > Architecture, but I think a business architecture is incomplete unless it > has both Business Services and Business Events factored into the mix. > > For example, in the chapter I'm working on in my book, I was writing up some > information on establishing service utilization baselines and was trying to > write up how these baselines must be continually maintained, and realized > that changes are triggered by business events. Sometimes, it is a very IT > centric event, like the system is deployed to production, but other times it > can be a very business focused event. For example, suppose it's a retail > organization that has a bricks-and-mortar presence. Any system that is > primarily used by staff in the stores or branch offices is going to have to > adjust their expected utilization and the utilization of any services it > consumes whenever a new location is opened. While this may seem like common > sense, I'm sure there any many organizations that lack linkage from the > business side back to IT and are at risk of having IT failures whenever > these events happen. > -tb > On Jun 21, 2008, at 8:06 AM, Michael Poulin wrote: > > Steve Jones wrote: >>Now I'm not sure about EDA in its own world without an SO world that >>encapsulates it. > > I need more input to discuss this. EDA existed and can exist on its own, w/o > SOA, right? > Encapsulation in this context means that principles of one are included into > or among principles of another. In SOA we are talking about loosely-coupled > service consumer and provider. In EDA they may be totally decoupled. In SOA > we are talking about Service Contract, i.e. direct agreement between > consumer and provider. Implementation of EDA via MOM allows for an > intermediary which estranges consumers and providers to each other. ESB > tries to do the same but I argue that this contradicts SOA principles of > loose-coupling and reach-ability if the ESB does not take a 'service > representative role' on itself. > >>If we are talking about events being fired then >>these needs sources and sinks, from a business perspective it makes >>sense to think of these as different business services and the event >>being the particular implementation of the execution context for that >>interaction. >> > Agree. > >>There isn't a B-EDA approach that I've seen > > How would you classify following case: end-users (consumer) pay by Debit > Cards on a Web Site; the Web Site provider does not deal with Card Issuers > (Banks) directly but delegate payment requests to an intermediary ( called > acquirer in this scheme ), which, in turn, multicasts payment requests to > appropriate Card Issuer. The end-user may not know which actual Card Issuer > will be involved (a Bank may engage a 3-rd Party for the Debit Card payment > processing, i.e. the Card may be processed by another organisation than > issued the Card) and when ( the acquirer has its own processing pace ). > > This is the typical business scenario in financial industry; it includes > 'event' (payment request) and 'event-caused action-er' (actual Card > processing organisation), everything else is the event message delivery > means. The end-user contract is between him/her-self and the Card Issuer who > represents actual Card processing organisation. The Web Site and acquirer > are hidden infrastructure, which can easily violate the contract because > they do not have a direct contract with the end-user with regard to the > Debit Card payment (similar to ESB or MOM ). > > As we know (at least, I had such cases), the Debit Card payment is not > guaranteed until the seller gets the money. Moreover, it is poorly managed > because the customer has no clue about the acquirer. That is, the customer > takes the contract with hidden dependencies and risks, which I do not call a > good SOA practice. > >>so I'd say that EDA makes >>sense as an implementation approach for a business service >>architecture. > > Agree but with the condition (mentioned above) > > - Michael > > > > ----- Original Message ---- > From: Steve Jones <[EMAIL PROTECTED]> > To: service-orientated-architecture@yahoogroups.com > Sent: Friday, June 20, 2008 4:49:30 PM > Subject: Re: [service-orientated-architecture] Re:Data services (was Re: > Definition of SOA) > > 2008/6/20 Rob Eamon <[EMAIL PROTECTED] net>: >> --- In service-orientated- architecture@ yahoogroups. com, Michael >> >> Poulin <[EMAIL PROTECTED] .> wrote: >>> >>> <<<<<<<<<<<< <<<<< >>> >>> Your point, I guess, is how we can explain a message exchange >>> between the consumer and the service engaged in the 'pure >>> orchestration' [coment: this is meant to be a non-service >>> component] from the service interaction perspective. >>> I think, there is no interaction between consumer and service in >>> this scenario, i.e. the question is not applicable. >> >> What are you referring to as the consumer in this case? Can you >> clarify a bit? >> >> My preliminary take on the above is that it is the >> orchestration "application" that someone put together using an >> orchestration tool that is the consumer. But I may wrong so thought >> I'd double-check. >> >>> In SO interpretation of this case, a consumer does not know about >>> service existence and invocation; it does not have a contract with >>> the service and never evaluated service description. There is no >>> consumer intent of obtaining a RWE from the service. >> >> If there is an interaction with a provider, something somewhere is >> the consumer. >> >>> More difficult case when a consumer reviews Service Description, >>> chooses the service but has to deal with an intermediary - >>> Mediator/Broker/ Destination - instead. >> >> [additional good stuff about use of intermediary snipped] >> >> +1. >> >>> I also see your point where you try totally decouple consumer from >>> the service. First, it is impossible because they have to agree on >>> the messages taxonomy and semantic; second, consumer agrees to the >>> providers communication and execution policies (and may not agree >>> to the intermediary policies unless they are the part of the >>> Service Description) . >> >> +1! >> >>> >>> I think we should not try to merge SOA with EDA. They are different >>> architectures, >> >> They are different architectural *styles*. And can (should?) be used >> together to great advantage. > > Now I'm not sure about EDA in its own world without an SO world that > encapsulates it. If we are talking about events being fired then > these needs sources and sinks, from a business perspective it makes > sense to think of these as different business services and the event > being the particular implementation of the execution context for that > interaction. > > There isn't a B-EDA approach that I've seen so I'd say that EDA makes > sense as an implementation approach for a business service > architecture. > >> >>> have different concepts and principles. Does EDA compliment SOA? >>> Absolutely, but they are not the same thing. >> >> +1!! >> >> -Rob >> >> > > >
