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
A recurring theme in the literature on IT over the years has been frequent failure of IT projects. Most studies lay the bulk of the blame on requirements (examples here and here). One way to improve accuracy and fit-to-purpose of requirements, and thereby promote project success, is to include data analysis as well as process analysis in the requirements plan.
I’ve cited here the need to start data interface analysis early to avoid budget and schedule blow-ups when, as a result of not thinking early about interface complexity, data integration work turns out to be bigger and nastier than anticipated. Continue reading
In a recent very thoughtful post on data quality, Paul Erb plays out an analogy comparing data users with Don Quixote and data quality professionals with Sancho Panza, then reverses the analogy to cleverly coin the “Sancho Panza” test of data quality professionals. He encourages data quality professionals promoting the critical role of data quality to apply a what would Sancho say test to ensure that they are aligned with the needs and interests of data consumers. Continue reading
In a new post at Insurance Networking News Ara Trembly provides a balanced perspective on IT/business misalignment (Business/IT Misalignment: Whose Responsibility?). He describes the problem as cultural, more amenable to relational than management solutions. His conclusion sums it up: “Take a geek/suit to lunch today!”
To me (speaking as an IT professional) IT should take the initiative to solve the problem. Continue reading
History is littered with IT application projects that end late, go way over budget, or abandoned altogether. I was fortunate enough to see one work out really well (almost – please read on). It was no mistake. It came down to a simple method advocated by a gentleman named named John Carpenter.
The project was an HR management software conversion from one commercial off-the-shelf software (COTS) package to another. The company concerned was conservative about spending money. A previous business case had proposed a similar project. The problem with that business case was that the benefits were really tough to conceptualize, so the cost/benefit analysis relied on soft benefits like “improved access to information” and “more consistent reporting data”. The folklore was that the CFO had physically thrown that business case out of his office. Continue reading
