Stylesheets and the Data Services Layer

I was on a conference call the other day with a customer talking about their deployment of Ipedo.  This customer has done some pretty cool, cutting-edge stuff, combining rules technology, virtualization, XML and SOA, all for a very large user population with a very large and growing data set.

What stuck me during the conversation was how they were building out their data services layer (Actually, they modified the term, calling it a 'knowledge services layer,' as it adds intelligence and the collective wisdom of the user base to the data, but it's all available as a service.  Intriguing.)

Anyway, what was interesting was that they installed the data services layer to help build their application, but they are leaving the data services layer open for others to build upon later on.  Since they know other groups will want to do different things with the data, they just standardized on the data integration layer and will let others go to town.  So they get what they need for their app, and the company gets a 'data foundation' they can use later on.

In fact - and this is where XML stylesheets come in - they think that getting the data integration right was the bulk of the work.  Many people will just want a different slice of the data, presented in a different way.  So what they do is let them get the data slice in XML, then the developer just applies a stylesheet to it, and voila, new Web application.  This is something I wrote about three years ago in an article called 'Send Me Your Stylesheet.'  Nice to see it actually happening.

You'll notice that I used the term 'data services layer' in this entry rather than EII.  Perhaps its more fashionable to talk about data services when people are using XML and SOA.  EII seems more to do with relational databases accessed with an ODBC/JDBC View.  Ipedo does ODBC/JDBC/SQL and SOAP/XQuery/XML, and combinations of the two, so we don't really care.  It should just be interesting to see if EII and data services emerge to mean the same thing to people over time.

Data Governance Meets SOA Governance Meets Data Services - Incomplete Thoughts

Unless you have been on an extended ski vacation, you've probably been seeing quite a bit written about governance recently.  Governance.  A nice word.  It's worked its way down from the board room to the server room.  And now we have several different kinds of governance in IT: IT Governance, SOA Governance, and Data Governance.

Ipedo plays a role in all three: as a federator collecting system data for IT Governance; as an XML-oriented query and federation engine in SOA Governance; and as a facilitator of data integration, delivery and security in Data Governance.

SOA Governance, in particular, is red hot right now, esp. since one of our customers Systinet got acquired by Mercury last week.  Now all the SOA ecosystem is talking about how they deliver SOA Governance.

Which got me wondering, trying to connect a few dots in our EII world, which is at the confluence of data integration and SOA.  A data/services/governance mashup, if you will.

Given that a) Data Governance is how you control the correctness, accessability, and security of your organization's data, and b) SOA Governance is how you manage the development, accessibility, security and lifecycle of your SOA, and c) Data Services is how you take your corporate data and service-enable it, I started wondering the relationship between Data Governance and SOA Governance in an SOA.

Once you have all of your data available as a service, is there a Data Governance component of SOA Governance?  It seems like SOA opens up a lot of interesting possibilities.  Not that you want to use SOAP to wrap and communicate with all of your corporate databases (as I wrote about in an SOA Journal article), but for the information you want delivered via a Web Service, you could call a set of Data Services that a) make sure the data is correct (aka data quality), b) make sure it's accessible via presentation in the right schema, and c) the proper security checks are in place before it's delivered.

It will be interesting to see how things shape up.  Where Data Governance seems somewhat lacking is in the protocol/specification area.  SOA has an embarrassment of riches here,  while Data Governance has to settle for process and metadata.  Now, access to data and restrictions thereto are exactly what Data Governance is all about, and with companies spending so much of their IT dollars to comply with SOX, Basel II et al, Data Governance could add a lot.  James Governor writes about the interesting idea of Compliance + SOA = COA.  So much of the compliance issues are around data.

We'll see how things evolve.  It might not be too far off that EII uses SOA to govern the federation...

 

A New Day: Gartner and the Bright Future of Data Services, XQuery

One good thing about the holiday season: you get to clean up your desk and catch up on your reading.   Which I did.  And among the gems in my bookmarked reading list was a recap of Gartner's "Death of the Database" presentation from last year's Gartner Symposium ITxpo.

There were lots of intriguing items in Gartner's presentation, but two jumped out at me.

First, Gartner sees data distribution increasing.  It's only inevitable.  They use the example of data on RFID tags.  Does it make sense to continually read and store the information on tags as they move though a distribution chain, or would it make more sense to have a service that can read that data on an as-needed basis?  Obviously, the latter. 

This is what Gartner has been calling the "Data Services Layer."  It's an abstraction at a higher level, above the databases, repositories, caches, and small data stores (like RFID tags), that knows where and how to get the data, and adds an appropriate level of security controls and auditability to make a CIO smile.   And though Gartner only uses the term EII parenthetically in their research, an EII server that can federate and control information access across distributed and disparate data sources is exactly what Gartner is describing. 

The second thing that jumped out at me was this: Gartner sees SQL taking a back seat to XQuery.  Wow, I never thought I'd hear Gartner say that.  That's something only XQuery evangelists would likely say.  That doesn't mean SQL is going away anytime soon.   Just that all the XML in the world (RFID info, Web Services, Blogs and RSS) is going to need some way to be queried.

Looks like 2006 is shaping up as a pretty interesting year for a company that can federate and control access across relational and XML sources, creating an instant data services layer.