2008/7/9 Kirstan Vandersluis <[EMAIL PROTECTED]>: > --- In [email protected], "Steve Jones" > <[EMAIL PROTECTED]> wrote: >> >> 2008/7/8 Kirstan Vandersluis <[EMAIL PROTECTED]>: >> > Steve, a couple more comments and questions: >> > >> > --- In [email protected], "Steve Jones" >> > <jones.steveg@> wrote: >> >> >> >> 2008/7/6 kavandersluis <kirstan@>: >> >> > What I'm really suggesting is using XML models to define entities >> >> > which become the basis for entity-style services, which supply the >> >> > data to apps and higher level services. It is this set of entity- >> >> > style services that constitute the XML-based data abstraction yer. >> >> > >> >> Fair enough for me as long as its post-transactional information >> >> rather than "live" information. >> > >> > First, I'd like to be clear on what you mean by post-transactional >> > data. My assumption is that we are talking about data that feeds >> > BI/reporting/BAM functions. Feel free to point me to other >> > posts/discussion areas if appropriate. >> >> Yup those are the ones that I mean. >> > >> > Now, can you expand on why this is inappropriate for live data? I >> > have seen it work for both live and post-transactional data, though >> > I'm sure companies I work with are at a different scale than those you >> > work with. >> >> The problem with using "live" data, by which I mean data which is >> currently in an intermediate state under the management of a service >> (or a process within a service), is that the raw data represents only >> 50% of the story the other 50% is in the code that processes the data >> and which knows that if the field that says "customerType" is >> currently set to "Narnia" while the "notificationReceived" field is >> set to "true" but the "verified" is false then it means that the >> customer has been sent a notification but is sitting on it. This >> might make perfect sense in the context of the code but makes no sense >> whatsoever to anyone external to that code. The point is that the >> data at this stage has a very high cohesion with the >> service/process/application that is processing it. Exposing this >> information via a data service for all to access is very dangerous as >> it means either also exposing the processing logic or letting people >> make assumptions like "hell we've got a lot of new customers in >> Narnia". >> >> That is a real example, the reason for Narnia was that it was added as >> a holding country with only verified customers having the country set, >> and only verified customers should have been exposed to the world. >> >> Now if _within_ a service you want to use a DAL to help you access >> your inflight data then that is fine but the DAL shouldn't be exposed >> wider. > > Yes, I've also seen many types of incomprehensible hacks to make > systems work.
It wasn't really a hack, it was just that the country couldn't be null (underlying database) so they needed a fictional country as a holding marker. > I do think there might be value applying a DAL within > this service. The DAL would provide a rationalized view, e.g. > "Narnia" customers would be shown as "Pending" or similar. Part of > what the DAL does is hide gory details like this. I'm not saying this > is easy, because I'm sure there were many other hacks in there as > well, most of which depend on coded rules. But I would say the more > hacks you have to deal with, the more a DAL makes sense. You isolate > the hacks to one layer so consumers don't know or care. This > isolation creates opportunities to change or migrate without any > affect to consumers. It is possible the cost is not worth the > benefit, unless there are other users for this rationalized data view. > This raises the following question... > > In your example, were there reporting requirements that had to expose > this "live" data? It seems like somebody would be interested in the > state of customers in such a pending state. How would the data for > such a report be exposed? Via the application. There was a quite a nice BAM piece that described the current bottlenecks and issues, the point was that the information was contextualised based on its position in the process (not done with a process engine) rather than showing all the data so it was Customer X is awaiting confirmation etc. > There is opportunity for the "Customer > Management" service and this separate reporting service to use the > same view of data. Could it be that the "CustomerManagement" service > also manages the reporting service? The implication is a drifting > definition of live versus post-transactional data. One services's > live data is another services's post-transactional/reporting data. That can indeed be true, but I'd say that in most cases people _consume_ post transactional data but _act_ on live data. > >> >> > >> >> > "Add customer" is an operation in the "customer" service, which is >> >> > an entity-style service which constitutes part of the "XML-based >> >> > data abstraction layer" as described in the article. >> >> >> >> This is where you loose me I'm afraid. "Add Customer" is very >> >> rarely an entity based thing. If I am a regulated utility the "add >> > stomer" >> >> flow can take several months to complete. If I'm selling someone a >> >> car then "Add Customer" involves selling and supplying a car. >> >> Treating these elements as data centric is (IMO) very dangerous. >> > >> > We've missed on semantics here, sorry. "Add customer" in my example >> > is really "create customer", the 'C' in CRUD... I very recently >> > attended a presentation that used this vocabulary. So, I'm not >> > advocating that your "Add customer" be defined in the DAL. I agree >> > with your placement and your point. Deeper in the service >> > decomposition, I think there would be a "create customer" operation. >> >> Indeed and to the example above "createCustomer" occurred after they >> had been verified (or was after we fixed it!). >> >> > >> >> > Then, >> >> > applications, processes, and other higher level services access >> >> > this service instead of accessing the data directly. This is an >> >> > area I'd love to hear discussion on from you and others. >> >> >> >> I'd say that you have CustomerManagement as a service which provides >> >> access to the functional capabilities of the organisation around >> >> customer management, it is also responsible for the "blessing" of >> >> the customer data master record which is a data centric service that >> >> is supplied to the organisation to ensure single view of the > customer. >> >> The two pieces represents different facets of Customer Management, >> >> one being about the capability and functional operational aspects >> >> (the true RWEs) and the other being about the provision of >> >> post-transaction facts (technical RWEs). > > My first thought is that this is a bit contradictory here, that this > data centric service for single customer view (post-transactional) is > "supplied to the organisation". If this organization also has a call > center and a self-service web site, those systems would each share > this data-centric service. On post transactional information yes, for instance unified customer record. For the live information they look at it via the process view not the data view. > Thus, the service *is* exposed and > available for other purposes, and is not a private service. But > perhaps this depends on how you define your service boundaries... Indeed user interfaces are not always good boundaries that just means different service consumers, but the same service. > maybe the call center and self-service systems are also part of the > Customer Management service? I'd hope so, after all why would you want to manage customers in fundamentally different ways? > >> > >> > Hopefully the above clarification on post-transactional data will >> > clear up my understanding of your point here. >> >> Hopefully so... did it? > > I am understanding your points much better, subject to my concerns > above, thanks! Steve > > -Kirstan > >
