Turning 60/40 into 40/60

    I was talking recently to an IT executive at a large bank about why he was looking at enterprise information integration (EII). When I asked him about the primary driver, he told me that it was the marketing analysts. That sounded strange at first, but then he told me about 60/40.

 Marketing analysts at banks are the people trying to figure out how to sell you a new home loan, second mortgage, credit card, or whatever product you don’t currently have. These analysts look at spreadsheets or reports and try to figure out what offers they should mail to what people.

 Turns out, though, that ‘analyst’ is somewhat of a misnomer. Or maybe a better way of putting it is that these analysts are forced by a lack infrastructure to do another job most of the time. To be precise, according to this executive, these analysts spend three days a week trying to gather data, and only two days a week analyzing data. Hence the 60 (3 days) / 40 (2 days) ratio.

    “These people practically need to take an ETL developer to lunch to get their jobs done,” he told me. They run around looking for spreadsheets, asking for new data sets to be loaded, and uploading CSV files. He sees EII as a way to change all that and make the analysts more productive.

 With EII, the model changes. Rather than continue the spread of data marts for all the analysts in all the groups, EII would allow the creation of a self-service model. Views, as they are called in EII, could be set up to span data sources. IT would still be involved in the initial set up, but the virtual nature would allow faster, easier customization by the analysts without the need for an ETL developer’s assistance. The EII layer could span all kinds of sources, from operational data stores, data marts and data warehouses. That’s not to say ETL would go away – there’s still a need to clean, master data and for the data warehouse.

 So EII can change the ratio. It can change 60/40 to 40/60 – or even better. Aside from developers who need to start buying their own lunch, that should make everyone happier and more productive.

XQuery Hullabaloo

    There’s been quite a stir recently on the W3C’s XQuery. In the last three months, I’ve repeatedly been asked two questions, mainly by press and analysts: ‘When is XQuery going to happen?’ and ‘Is XQuery really going to happen?’  The answers are ‘now’ and ‘yes.’

    Related to the question of when XQuery will happen is the ‘Why is it taking so long to become a standard?’ question. Seems like a little history lesson is in order here. Let’s take a look at the history of SQL, thanks to the folks at the International DB2 User Group:

The original version of SQL was called SEQUEL (Structured English QUery Language) and it was designed by IBM research in San Jose, California in the early 1970s. The first commercial implementation of SQL was in 1979 by Oracle Corporation (then known as Relational Software, Inc.).

In October 1986, ANSI approved a basic version of SQL as the official standard. Most SQL implementations since have included many non-standard extensions to the ANSI standard. ANSI updated the standard in 1989 to include data integrity enhancements and again, more substantially in 1992 to a new standard commonly known as SQL2. Further enhancements have been made to the SQL standard to include support for a Call Level Interface (CLI) and stored procedures.

So let's compare:

• SQL
  • Invented: 1971/2
  • First Implementation: 1979
  • Standard: 1986
• XQuery
  • Invented: 1998/9
  • First Implementations: circa 2000 (incl. Ipedo)
  • Standard: Expected 2006

    So, though the origins and circumstances are different, XQuery is set to become a standard in half the time it took SQL!  Not bad for a language that many believe to be even more complex and powerful.

    On the second question, XQuery is really going to happen because it is already happening. Just like SQL, implementations of XQuery are preceding final standardization. Customers, including our own, have been using XQuery for years now to help integrate and manage data and content in applications ranging from corporate dashboards to system management to online music sales. Customers use it because it is useful. Sorry if that sounds obvious, but it seems that there are some who believe customers are all waiting to see the white smoke rise from the W3C working group conclave.

    By last count, there are over 40 commercial and open source products that provide or include support for XQuery. Every major database vendor – IBM, Oracle, and Microsoft – has announced that they will soon be in beta. With every month, we hear about more vendors interested in using it for new applications (some have even suggested XQuery for slicing and dicing blog content - see John Udell's XQuery Adventures).

 At the point, XQuery seems to me less a question than a fait accompli. That’s good news for all those customers out there with real work to do.