Now the other day when I was talking about MDM a bright spark pointed out that I hated data services but wasn't MDM just about data services?
Its a good challenge, mainly because that is the problem about how many people view MDM. MDM is, when done well is about the M and the M not the D, i.e. its more about Mastery and Management than it is simply about Data. What does that mean?
Well lets take everybody's favourite MDM example "Customer" a Data driven approach would give us a Service of
Service Customer
- Capability: Create
- Capability: Update
- Capability: Delete
- Capability: Read
Now this is the "D" approach to MDM and SOA, also known as the Dunce's approach, its about Data Services and viewing the world as a set of data objects.
The smart approach is to view MDM as an information challenge and delivering information services so instead of the data centric approach we get
Service Customer
- Capability: Establish Prospect
- Capability: Establish Customer
- Capability: Modify
- Capability: Change Status
- Capability: Find
- Capability: Archive Customer
- Capability: Validate Customer
- Capability: Merge Customers
- Capability: Split Customer
Here we start exposing the customer service and make clear two things
- We are talking about the customer in context
- We reserve the right to say "no" to a request
So this is where customer genuinely can be used from a single service across the enterprise. This service takes on the responsibility to authorise the customer, or at least ensure that authorisation is done, it sets the quality standards and governance standards and doesn't allow people to do what ever they want with it. It includes the MDM processes elements around customer management and provides a standardised way of managing a customer through its lifecycle.
This is fundamentally the difference between a business SOA driven approach which concentrates on the services in their business context and with their business governance and a technical driven approach which looks to expose technical elements as via a technical wrapper.
Technorati Tags: SOA, Service Architecture
6 comments:
Where did you find a definition of Data Services being CRUD services wrapping a database table?
Unfortunately its something I've come across too much and I'm not alone some people actually talk about this as a good thing to do with tools some even write books on the topic.
So Eric, I'm not saying its ever been smart just that people have done it, some have advocated it and tools have promoted it. The major point though is that Information Services in the MDM context are fundamentally about information governance and not about CRUD on a table.
First of all, I agree with this, but it's good to mention that the capabilities Establish Customer and Modifiy Customer both need to CRUD the same Entity. If this is the case, it makes sense to have a Data Service that the two capabilities can use. Maybe only expose these data services to higer order capabilities and not to the average consumer.
Banter wrote: "...both need to CRUD the same Entity."
Yes but that doesn't make CRUD a "service" if one defines service as a business capability (CRUD'ing isn't a business capability--it's a technical detail; important but not a service). A common implementation component would definitely be helpful but it is an internal implementation detail of the Establish and Modify operations.
At least that's how I view it.
Classic symptom of developer-led SOA, which makes it not SOA at all but SOD (for development).
Developers think about accessing data in databases rather than services as fundamental building blocks of business processes.
Think about it: You don't "create" a customer. That act is reserved for whatever deity suits your fancy. To make the great evolutionary leap from developer to architect requires you to think about building blocks of the business rather than IT functions.
The business thinks about registering customers for loyalty programs, or opening an account, or submitting a loan application. A customer record will undoubtedly be created in some database, but that is purely an IT invention and side-effect of managing the under-the-hood aspects of running the business. When you eventually have this epiphany, exposing something like Create Customer seems downright absurd.
Strongly agree Steve.
I think it's just a question of abstraction level.
There's a corner case where this can work - when you've got all your data validation, business logic and so forth sitting in stored procedures + triggers, and you're just putting a thin wrapper over that stuff.. but I don't think that's a particularly large sweet spot.
Post a Comment