The importance of a Data Architect

As a consultant doing a BI project, for a client that remains nameless, I am doing a dashboarding solution.

The majority of the sales data for this client was already in the data warehouse, however we also needed to integrate a couple of extra data sources, one of which is the GL (General Ledger) - the general ledger is based on a JD Edwards system, and taken into Essbase.

Our first query was about whether data is changed in Essbase, being that if so, we had to get the data out of there. Thereby ensued a merry chase on my part on the best way to do so:

(I know very little about Essbase)

http://essbaselabs.blogspot.com/2008/10/custom-defined-functions.html

http://essbaselabs.blogspot.com/2008/10/cdf-jexport-and-dynamic-members.html

Found it right at the bottom of this page :

http://forums.oracle.com/forums/thread.jspa?messageID=2096489

Luckily, as it turns out, none of the data we need changes in Essbase.

So we go off to the developers at the client, and request an extract from them : and an extract from JD Edwards was requested, and given, and we imported into our warehouse. (in the EDW schema that we have access to)

OK, great so far, we have new tables. We need a little bit of extra information, request it, and talk to someone else - Lo and behold, in another schema on the same database that we are using, is a table containing EVERYTHING from the GL.

Upon talking to the first dev, he tells us that that is where he's getting his extract. Never mind that we've been talking about an extract from "JD Edwards" and he's giving us an extract from the data warehouse (and all the attendant dependency information)

Moral of the story? A data architect who knows how all the data interrelates and the correct source would have saved us all a LOT of time : add permissions to a schema on a database for 2 consultants, vs build an extract package AND an ETL package for data that is within the same DB.