August 9, 2012 at 12:09 am
Comments posted to this topic are about the item A Data Hub
August 9, 2012 at 5:05 am
I really like this article. It's the balance between centralized and distributed departments. In a BI environemnt, data quality, mastering and core IT function stay central, while relevance and application are handled in close proximity to end users.
If the hub gives the spokes great tools and practices, the spokes can be an amazing source of innovation, helping the systems keep up with the changes that otherwise end up causing projects to stagnate.
I've helped pioneer this kind philospohy with a client who stated the system we build for them was the most bang for the buck by far.
Love it!
August 9, 2012 at 7:34 am
Even well known data such as postal codes can change and easily become stale quickly. How many developers are willing to write import routines to update this data for something such as postal codes, let alone internal data such as customer names.
The first line is kind of thrown out there as true, but in practice, I have found postal codes to be very stable. There are new ones sometimes, and occassionally there are changes, but that they change easily and become stale quickly is a bit much in my view.
As far as the developers go, if that's the mission that they're being paid to do, whether they are willing or not doesn't matter. Any good data download is going to handle edits as well as adds (and deletes if they are possible). If someone's name changes in my system, the name change propogates to the central warehouse. If other name changes, then a new record is created. Part of the job.
August 9, 2012 at 7:39 am
We do this now in our organization. We have data that is badly organized (ie poorly designed databases with complex and improperly partitioned data structures) that needs to be access by reporting and other business processes inside and outside of our organization. By pulling this data and re-organizing it in a more efficient (and normalized!) manner it now becomes available for concurrent use by all sorts of standardized tools and access methods by any processes that need it.
I suspect this idea is used a lot where we need to get a bit more useful life out of antiquated or poorly designed systems.
The probability of survival is inversely proportional to the angle of arrival.
August 9, 2012 at 8:23 am
This is what I wanted to do and was trying to do for a previous employer. But it was completely lost on the decision makers. I was accused of not being a team player, of refusing to complete assignments, and of being "defensive." Is there any benefit of bringing such a vision to a company that can't seem to grasp it?
Jay Bienvenu | http://bienv.com | http://twitter.com/jbnv
August 9, 2012 at 8:37 am
jbnv (8/9/2012)
Is there any benefit of bringing such a vision to a company that can't seem to grasp it?
Sadly, No. A lot of existing organizations have business architectures that were 'designed' up by a VB programmer back when the company had a fraction of the transactional activity or amount or scope of data. Back then the quality of the design was unimportant, and it would have worked as well if the data was stored in flat files.
As the company grew to a point where they realized they needed a full time DBA (probably after being scared because of a database crash or getting hacked) the architecture becomes sort-of locked in. The powers that be usually adopt the attitude that "it served us well for the past 10 years.." so it will continue to do so, they just want a DB professional to make a few 'index tweaks' and do backups and improve security. The scalability and concurrency (or lack thereof) of the existing architecture is is never questioned because there is no conceptual understanding of relational database engines or the data designs that allow them to perform to their maximum potential.
The probability of survival is inversely proportional to the angle of arrival.
August 9, 2012 at 9:26 am
sturner (8/9/2012)
jbnv (8/9/2012)
Is there any benefit of bringing such a vision to a company that can't seem to grasp it?Sadly, No. A lot of existing organizations have business architectures that were 'designed' up by a VB programmer back when the company had a fraction of the transactional activity or amount or scope of data. Back then the quality of the design was unimportant, and it would have worked as well if the data was stored in flat files.
As the company grew to a point where they realized they needed a full time DBA (probably after being scared because of a database crash or getting hacked) the architecture becomes sort-of locked in. The powers that be usually adopt the attitude that "it served us well for the past 10 years.." so it will continue to do so, they just want a DB professional to make a few 'index tweaks' and do backups and improve security. The scalability and concurrency (or lack thereof) of the existing architecture is is never questioned because there is no conceptual understanding of relational database engines or the data designs that allow them to perform to their maximum potential.
This is what my old manager called "solution jumping" but I'm not sure if that makes sense. I'll try to explain...
If I'm the DBA, you don't get to tell me that you need index tweaks, you tell me you need better performance or some other thing that you understand. If I decide that index tweaks are the way to accomplish that, then that's what you'll get... but if I decide the database needs more work than that, you have two options: accept that my expertise is legitimate and go with what I say, or learn enough about databases to fully understand what I'm saying and then help with the decision about what to do. Most people are not open to the second option, but reluctant to accept that the person they hired is actually capable of the job they were hired for. This is insulting to me, and I've never liked it.
However, you can't just come in as the new guy and start bossing people around. You have to be tactful, and in some companies "DB done right" is a foreign concept and a cultural change, so you have to wait for it to happen, and play along, leading them slowly to the inevitable realization that you know what you're doing.
The probability of survival is inversely proportional to the angle of arrival.
Awesome! That's totally going on the wall 😀
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply