2008/7/8 Kirstan Vandersluis <[EMAIL PROTECTED]>: > Steve, a couple more comments and questions: > > --- In [email protected], "Steve Jones" > <[EMAIL PROTECTED]> wrote: >> >> 2008/7/6 kavandersluis <[EMAIL PROTECTED]>: >> > 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. > >> > "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). > > Hopefully the above clarification on post-transactional data will > clear up my understanding of your point here. Hopefully so... did it? > >> >> > >> >> >> >> For me data only architectures are a dangerous thing. >> > >> > The article is not intended to propose a data-only architecture, >> > but rather a DAL as part of a larger SOA. From the intro section: >> > >> > "A data abstraction layer reduces the architectural complexity >> > required to provide access to enterprise data, and allows >> > organizations to create and leverage services that support >> > critical business objectives." >> >> My argument would be that a DAL can _increase_ architectural >> complexity if it aims to separate functional aspects from data >> aspects too far. >> >> > >> > It seems to me that if you follow the process in your book >> > "Enterprise SOA Adoption Strategies", at some level of service >> > decomposition, you will begin to recognize entity-style services >> > that form the basis of what I'm calling an XML-based data >> > abstraction layer. I'd love to hear your opinion on this, too. >> >> See above on how this would happen with customer. Yes you would but >> the DAL would be "governed" by the business service and provided as >> a support service. > > OK, good. I've already quoted you in another post :-) Steve > > -Kirstan > >
