--- 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. 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? 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. > > > > >> > "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. 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... maybe the call center and self-service systems are also part of the Customer Management service? > > > > 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! -Kirstan
