Bob Lambert
Jul 14 2010
Use conceptual data modeling in requirements definition
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
May 10 2010
I’ve always been drawn to activities that stress team interaction over individual achievement. Maybe that’s why application development appeals to me. Success relies on integration of diverse skill sets and perspectives. Project failure often results from failure of one or more specialists to fully integrate into the team. Projects exceed expectations often because individuals subsume skills and achievements in support of team efforts. Maybe that’s why Adrian Cho’s “Jazz Process” piqued my interest.
Apr 12 2010
Defaulting data integration to customers = risky business
Here’s a little-recognized fact about data integration: if you run a business or any sizable chunk of one, someone is integrating your data.
In my professional life I have, on occasion, suggested data integration efforts. Sometimes my suggestions have been accepted and sometimes not. As an IT professional I understand that different managers have different priorities, and in a given business situation sometimes other things may be more important than, for example, having a single, consistent source for all customer records, or making sure production data matches financial data.
But as a customer? That’s different.
Mar 31 2010
Business requirements up front
"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".
Feb 15 2010
Groupthink and the Agile Architect
Need uber-guru types who are willing to challenge the existing groupthink on design and architecture, especially on TDD and emergent design and pair programming anti-pattern” – job post at Monster.com 2/9/2010
I stumbled upon that quote following links on the role of the architect on an agile project. Maybe one important role of the architect is to help the team avoid groupthink.