John Schley, DAMA International President, has a great column in DM Review on how one of his children's favourite stories gave him insight into data management methods:

One night, as I was reading this book for maybe the 3,287^th time, it occurred to me that "Old Hat New Hat" matched some data modeling experiences I've had. Like the clerk in the hat store, I come in to the meeting with a pretty good idea of what kind of data structure the client needs. I'm up on all the latest modeling techniques and am eager to show off my proficiency with my chosen data modeling tool. I'm eager to produce a stunning data model diagram, jam-packed with important details such as the table and column names (in standard abbreviation format!), constraints, and indexes. And I'm sure they'll love the time savings they get when I automatically generate the data definition language (DDL) script that creates all these structures in their chosen database management system.

Sometimes the simplest analogies are the most meaningful.  Good job, John.

One of my favourite member benefits I receive for being a member of the Association for Computing Machinery, ACM ,is the print and online version of ACM Queue Magazine.  You'd think that a rather academic organization like ACM would be lacking in the practitioner side of computing, but this magazine blows other society mags out of the water.

For instance, a recent column by Alex Bell of The Boeing Company comments on the increasing number of silver bullets in the software development industry:

 

Software Development Amidst the Whiz of Silver Bullets...

A call to Transylvania may be needed.

There are plenty of examples in the software engineering realm that demonstrate blatant disregard for Fred Brooks's sage advice¹ asserting that there are no silver bullets available now or in the foreseeable future with which to solve all difficulties. Regardless, the desperate, the pressured, and the ignorant are among those who continue to worship the silver-bullet gods and plead for continuance of silver-fueled delusions that are keeping many of their projects alive. It is difficult to be overly critical of the individuals who have been impacted by silver bullets, however, because the software engineering space is being barraged with them as never before. Even the most savvy of software engineers must occasionally liken themselves to the infamous Neo in the film The Matrix and gyrate wildly to avoid being stricken by the many bullets whizzing by.

Veterans of the software industry will attest to having seen a number of silver bullets come and go in their time. The argentum projectiles of yesteryear, such as OO, high-level software languages, and IDEs, are now obvious to have been only low-grade alloys compared with the fine silver being discharged today. For example, today's silver bullets have demonstrated an unparalleled ability to provide implicit value to both text and diagrams, the power to shift the economics of software development, and a capacity to change the focus of long-established engineering disciplines. Only the passage of time will reveal the new and amazing capabilities promised of future silver bullets yet to whiz by.

I chuckled at Bell's use of personal examples to show why statements such as "the data will be stored in XML" provide no assurances of quality:

    Alanah

    Hi Sweetie, I really am not the weirdest Dad of all the kids in your school.

        Love, Dad.

   

I'm certain that we in the data and process management industry are just as bad.  I've been on projects where data models or UML models are prepared for the sake of the project plan, but add absolutely no value at all to the project or the resulting systems. 

Sure, we have our own buzzwords and hype, but it seems to me that the development process is the greatest magnet for the weirdest silver bullets.  I put these proposed methods right up there with fad diets and 419 scams.

What do you think are the most promising silver bullets in the next couple of years?  What do you think are the most questionable ones, especially in the data and process management areas?

Am I being practical or cynical? 

Even though I recently turned 42, I still tend to think of myself as a young professional.  Perhaps this is due to the fact that I feel overwhelmed by the amount of technical knowledge I don't have.  Our profession seems to change at light speed and this velocity is driven primarily by vendors -- not because they are some evil force, but because no one else is driving change.   Along with products vendors also tend to drive new terminology and acronyms in order to distinguish themselves from other organizations.  The terms most likely to survive are those that are put out for all to use.  Those that are heavily trademarked an enforced add confusion to the marketplace, as other organizations are forced to coin their own trademarked buzz.

Another downside of the buzzword biz is that we end up with new and conflicting names for concepts that have been around forever.  Nothing makes my mind scream "UGH!" more than reading something that says that some brand new technology or technique has arrived to save us from our sins, when actually the concept has been around decades.  I have previously written about my consternation with working with UML modeling tools whose marketing collateral reads something like "For the first time IT professionals have the ability to model data" or "IT has never had an integrated data and process modeling toolset".  I have always assumed those groaners were intentionally added to websites to ensure that we old folks wouldn't dare trespass their new, shiny modeling systems.

One of the hottest buzzwords this years is Master Data Management.  Don't get me wrong -- I'm excited that business execs are being told by the media that having sufficient data quality is important to their success.  I'm also happy to have access to whitepapers, conferences, and other resources to support our data management industry.  I wonder, though, what did those executives think that we've been saying all along about data quality.   Was it our message?  How we said it?  How we dressed?

When I read all the MDM buzz, the thing that strikes me is that the 20% new stuff is middleware.  So is it really that our tools weren't installed in the right place?  Not expensive enough?

Hannah Smalltree's December column "Is MDM All Hype?" in SearchDataManagement.com hits on this very topic:

MDM is "80% old stuff and 20% new stuff," White said. The "old stuff" is technology expanded from product information management and CDI tools, as well as some of the data definition concepts of metadata management. The "new stuff" is a major emphasis on data governance and new MDM tools, which are different from anything the industry has seen before, White said.

Could we use this same tool injection to solve some of our other data and process-related exposure problems?  Perhaps we should introduce some middleware, throwing in some governance and web services to make it more prominent.

Jerry Weinberg also has a great saying about all this, too: "The more they pay you, the more they respect you."  Perhaps that's where we went wrong, trying to impose data management on an organization that couldn't respect us because our tools are stable, affordable, and easy to use.
 

 July 17, 2006 09:00 AM US Eastern Timezone  

Embarcadero Technologies ER/Studio 7.1 Facilitates Best Practices for Database Security and Data Model Design Quality SAN FRANCISCO--(BUSINESS WIRE)--July 17, 2006--

New Data Security Properties Provide System for Classifying Sensitive Information; Improved Validation Simplifies Model Review; Feature Enhancements Raise Data Modeler Productivity

Embarcadero Technologies, Inc. (NASDAQ:EMBT), a leading provider of strategic data management solutions, today announced Embarcadero(R) ER/Studio(R) 7.1, the latest release of its award-winning data architecture and database design solution for the discovery, documentation, and reuse of data assets through visual data models. In the 7.1 release, ER/Studio builds on its enterprise model management and collaboration capabilities to help organizations take a global approach to two important aspects of data management: reducing risks associated with data security and enhancing data model quality.

With ER/Studio 7.1, data architects can facilitate compliance and reduce the risk of inappropriate data use through the improved identification, classification, and communication of policies around sensitive data. In addition, the 7.1 release vastly improves model consistency and quality by providing validation rules to enforce company-specific standards and practices across the enterprise.

Read More..

Over the years, I've worn many hats, from project manager to 3-hole paper puncher - seriously.  And I've had a variety of titles, including Senior Systems Analyst, Senior Consultant, List Mistress, Chief Methodologist, Data Architect, Data Modeler...the list goes on and on.

When I present or write, I tend to use very flexible terms for talking about roles.  I don't make a significant distinction when I write Data Modeler, Data Architect, or Data Administrator.  The latter term has fallen out of fashion in most shops, but it is still used.   This flexibility often gets me in to terminology trouble when I speak, though, as many organizations have formal distinctions tied to responsibilities and compensation based on the specific title used.   And some professionals are insulted when I refer to their role as a Data Modeler, when no slight was intended.

The same thing happens when I speak about DBAs.  In some shops, a DBA is someone who runs pre-scripted jobs and changes passwords. In other it is the only person allowed to access the database via means other than an application.  I recently posted something about this title issue on another list:

Terminology gets us all the time. The role of a DBA can vary, something along the lines of:

• operational DBA:  keeps databases up and running. Has few planning, design, or development assignments. Sets up accounts and checks the status of jobs. Usually first line on-call person. Probably what you are referring to as "administrator".
• planning DBA:  plans for database activities to keep them up and running. Things like capacity planning, security, backup strategies, compliance issues, replication strategy etc. Most likely the one who sets database architecture standards and processes. May also supervise other DBAs. May be second or third tier on-call support person.
• developer DBA:  designs databases, often on a project by project basis, builds triggers and stored procs, etc. Might even be responsible for writing applications. Might even be responsible for logical designs.  Typically optimizes designs for ease of development. Usually on call for database and application issues.
• Jack of all trades DBA: "I'm the only person in the shop that knows how to spell SQL, so I'm the only DBA" and I'm a part time developer, too. On call all the time for all data stuff. And some application, too.

Larger shops tend to have these roles separated across multiple positions (people). Smaller ones tend to lump them all together.

Lately I've been working in shops that have 1-5 DBAs, so pretty much they are Jacks (and Jills) of all trades DBAs. Sometimes there is a junior DBA who performs mostly operational DBA jobs. SOX compliance issues are taking their toll on these all trades DBAs, as many organizations are interpreting SOX as requiring a great deal of separation between development and operational roles.

All these are generalizations, I'd admit. I once worked with an end-user who was first line DBA support. And he was really good at it, probably because he had more to lose than a typical DBA if the data were fubarred.

I'd be interested in reading about your use of data management related titles, what they mean to you, and what pecking order are embedded in them.