Recently I was in a conversation about data modeling standards. I confess that I’m not really the standards type. I understand the value of standards and especially how important it is to follow them so others can interpret and use work products. It is just that I prefer to focus on understanding of the principles behind the standards. In general, it seems to me that following standards is trivial for someone who understand the principles, but impossible for someone who doesn’t. But there doesn’t seem to be general understanding of data modeling principles. Continue reading
In my experience, some BI projects ultimately finish as a success, but exceed budget and schedule targets and fall short of functional goals along the way. On projects like this, somewhere in the midst of report development, things get sticky and tasks fall behind schedule as the team runs into unexpected complexities. Continue reading
As a relational database professional I couldn’t help but feel like something would be lost with the emergence of the new Big Data/NoSQL database management systems (DBMS). After about two years of buzz around the topic, I’m really excited about the emerging possibilities. However, I’m pretty sure we’ll miss the relational model’s strengths in requirements definition and conceptual design. Continue reading
I’m a data modeler, so I enjoyed Jonathon Geiger’s recent article entitled “Why Does Data Modeling Take So Long”. But why does he say it like it’s a bad thing?
Mr. Geiger’s bottom line is exactly right: “Most of the time spent developing data models is consumed developing or clarifying the requirements and business rules and ensuring that the data structure can be populated by the existing data sources.” On the projects he describes, no one took time before modeling to determine available data sources and identify business entities of interest, relationships among them, and attributes that describe them before database design started, so the data modeler had to do it.
I’ve worked with health care data for the past few years, and in a recent conversation I realized it might be valuable to detail some of the complexities of health care data for those who might enter this growing field. Of course these considerations aren’t unique to health care, but they are typical of the challenges that the new health care application developer or analyst might face. Continue reading
Recently my friend Mark Hudson posted about the inappropriateness of the term “sprint” for an agile project phase, preferring the cycling term “interval.” That post really struck a chord with me.
As a rugby union fan and former wing/fullback I’ve always thought the whole rugby analogy was wrong. Agile development is continuous and fluid, yet the agile originators chose the word “scrum” for its daily standup meetings. In rugby union a scrum is a set play resulting from a minor penalty, like offside in American football or a foot fault in tennis. If you like the rugby analogy the right term would have been “ruck,” which is kind of like a scrum but part of the continuous run of play (in the other kind of rugby, called rugby league, the scrum has devolved into an almost meaningless stylized ritual – which I guess happens on some agile projects). Continue reading
I’ve often thought that conceptual data modeling was an underused tool in the arsenal available to requirements analysts, and in a recent conversation I found that many were surprised that it would be used in the requirements phase at all. Checking the Business Analysis Body of Knowledge (BABOK) I found data modeling listed among the tools available to requirements analysts to “to describe the concepts relevant to a domain, the relationships between those concepts, and information associated with them.” There’s also Steve Hoberman’s excellent book on the topic, Data Modeling for the Business, an introduction to data modeling aimed at a business audience. Continue reading
Thanks to all who attended my presentations at SQL Saturday on April 10. Here are the materials from my two presentations:
– The Business End of Data Modeling (2.5m powerpoint presentation)
– Normalize Metadata For Data Integration Analysis (5.5m full version, zip including presentation and code samples)
– Normalize Metadata For Data Integration Analysis (small) (2m reduced size version, graphics removed from ppt file)
Here are some quick notes for those looking to run the Metadata prototype:
The prototype metadata database includes SQL Server 2008 data definition language and data manipulation language (DDL and DML) needed to create the database and populate it with tables and columns from Microsoft’s AdventureWorksDW sample database. It also includes a sample requirements spreadsheet and source-to-target map, and SSIS jobs to load the spreadsheets to corresponding metadata tables. These define fictional requirements and mappings to populate the AdventureWorksDW FACTInternetSales table from tables in the AdventureWorks sample database.
AdventureWorks and AdventureWorksDW are available here: http://msftdbprodsamples.codeplex.com/Wikipage (accessed 4/14/2010)
“Our goals can only be reached through a vehicle of a plan, in which we must fervently believe, and upon which we must vigorously act. There is no other route to success.” – Pablo Picasso
It is an old story: about 30% of IT application projects succeed, 45% are “challenged,” and the other quarter fail altogether. That’s the consistent result over the years of the Standish Group Study of Project Outcomes. Jorge Dominguez, here, displays a chart of the remarkably similar results since 1994. Not a pretty picture, right? Some question the validity of the Standish studies, but Scott Ambler parallels the Standish story in a recent Dr Dobbs column called “Lies, Great Lies, and Software Development Project Plans,” which itemizes the strategies commonly used by IT project managers to “stay out of trouble” when schedule/budget results don’t match initial estimates. For example, “18% change the original schedule to reflect the actual results”. Continue reading
Many see IT as application of technology to solve business problems.
Of course, this is true but it leaves out the third element, which is to apply the right architectural pattern to solve the problem. For example, when the business problem is that reporting is slow and reports from different departments don’t match, the astute IT professional immediately thinks in terms of a data warehousing pattern employing technologies like databases, extract-transform-load (ETL) tools, and multi-dimensional reporting suites. Continue reading