Tuesday, February 06, 2007

Services Fabric and Data Management

Reflecting on the previous posts referring to events, content and semantics it's apparent to me that data management is ever more important in a world of services. Just because a database is buried deep behind a service interface doesn't mean we can ignore the basic principles of data management.

As we know semantics are critical at the service interface or the definition of an event, but how do we know that data passed through an interface is handled correctly? Given that we're moving to a service world in many cases by service enabling legacy applications we need to establish a framework for managing data across the service enabled landscape. We can not rely on a sea of services that are going to perform every validation for us - much of this will still be left embedded in applications. After all how would our services perform if every valdiation required a service invocation?

The framework needs to deal with:

Synchronisation (including translation) of content - ensuring that reference data or master data (not my favourite terms - see below) are up to date and distributed to where it's required when it's required. As above real time look up of content will not be performant in many situations. Therefore data needs to be 'cached' as part of the service implementation.

Synchronisation (including translation) of definition - as with any language, establishing a single dialect for the business and implementing it in its information systems is probably not a reality, especially when many system components are sourced from outside the enterprise and/or need to interoperate with customer and supplier services. Is Oracle's semantic model the same as SAP's?

Data (and service) ownership - as those that have tried will know, until this fundamental principle of data management is established many of the advertised benefits of service orientation will remain elusive. Unless ownership of data and associated rules are established multiple definitions and implementations will remain along with multiple service implementations performing similar functions.


As mentioned above these are the basic principles or needs of enterprise data management. However, apart from a few execution tools aimed at areas such as master data manaagement and canonicals I see very little discussion on this aspect of the services fabric. Of course this may be limited to whether SOA is treated as an IT or Business issue. The development and management of business ontologies has to be a cornerstone for establishing true SOA.

In this vein, what is the collective for the 'things' the business cares about (e.g. orders, customers, accounts)? Objects? Entities? Types?

(Note: Reference data or master data are not my favourite terms as these terms appear to lump in to one bucket what are probably a number of critical subject areas that define the enterprise. Indeed, MDM appears to be an IT persons response to the problem when of course managing information about the basic assets of the organisation is a business problem, requiring ownership and process.)

5 comments:

zyy1265 said...
This comment has been removed by a blog administrator.
Tom Rose said...

Adrian,

I agree with the points you make, and really these issues have always existed.

The recently minted SOA term only brought to the table a standard for technology integration and business process. Although, that has great value, and sets us up for reaping further benefits, it’s only a piece of the architecture puzzle as you pointed out.

I think the positive take away is the SOA hype is bringing more “basic” architecture tenets into the light of day, ensuring our service-oriented-architects have to deal with these issues directly. I’m hopeful that will continue to drive standardization, or at least better tools to manage all aspects of our SOA approach. I guess the next step is throwing out solutions that people can start to tear apart, and evolve into something useful :o)

Tom

Adrian Apthorp said...

Tom,

I agree with you and definitely see an increase in architecture awareness. Of course that awareness is not universal. However, I do just wonder how long it will be before 'we' have to come up with another term for the same set of principles once the SOA = ESB crowd have discovered this is not the case. Of course the technology side is a lot easier now we can buy it rather than build it.

At the end of the day the essential principles of SOA are the same as the fundamental principles of systems engineering (broadest sense of the term). Indeed I like to think of SOA as Systems Engineering for the Enterprise.


Adrian

Tim Matthews said...

Adrian,

Good post. I agree that data access and data management have been given short shrift in discussions of SOA. Why I don't know.

I've been doing a lot of writing about this over the last year or so. I got a lot of reaction from DBAs to this one, which I think makes the point: Mind if I SELECT * Your SOA?

It's amazing people get away with just saying things like "Use an ESB." It's much more complicated than that.

john said...
This comment has been removed by a blog administrator.