By Karen Lopez on Tuesday, July 25, 2006 3:10 PM

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.

By Karen Lopez on Friday, July 21, 2006 5:53 PM

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?

By Karen Lopez on Friday, July 21, 2006 2:10 PM

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.
 

 

By Karen Lopez on Monday, July 17, 2006 9:07 PM

 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..

By Karen Lopez on Wednesday, July 12, 2006 3:39 PM

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.

 

By Karen Lopez on Friday, July 07, 2006 1:03 PM

What if your data or process modeling tool could check for bugs in your model by inferring your intentions?  Computer scientists at University of Illinois at Urbana-Champaign have developed tools to do just that for programming code:

CHAMPAIGN, Ill. – The task of debugging huge computer programs can be made faster and easier by using new software tools developed by programming experts at the University of Illinois at Urbana-Champaign.

Computer science professor Yuanyuan Zhou and her students have assembled a suite of software tools that can find and correct bugs by inferring the programmer’s intentions. The tools draw from observations on how programmers write code.

“Most bug-detection tools require reproduction of bugs during execution,” Zhou said. “The program is slowed down significantly and monitored by these tools, which watch for certain types of abnormal behavior. Most of our tools, however, work by only examining the source code for defects, requiring little effort from programmers.”

An interesting approach to debugging.

By Karen Lopez on Thursday, July 06, 2006 9:16 AM

My laptop has been running slower and slower, plus the boot up time is a major hassle.  Since today's agenda was to clean up my office, I thought I'd run some system maintenance on my laptop.  However, before this, I wanted to free up a bing chunk of space on my hard drive.  The first thing I did was run Disk Clean up under START/PROGRAMS/ACCESSORIES/SYSTEM TOOLS/DISK CLEAN UP.  As usual, this freed up a tiny bit of space.  So I googled on hard drive clean up tips, which helped a great deal more, giving me a couple more gigs of space.  But I still couldn't figure out what was taking up so much space.  Sure, this laptop runs Windows Media Center, but I'd delete or archived all by one show.

I checked under START\CONTROL PANEL\ADD REMOVE PROGRAMS and removed all the applications that were no longer needed.

Then I remembered that I had several log on accounts on this machine.  Checking them out under C:\documents and settings\[user names], I realized that, obviously, Disk Clean up didn't clean up other logons.   So I deleted the temp files, Temporary Internet Files, etc under each log on account.  Another couple of gigs of space.

Next I checked out my Windows\Temp directory and was able to delete a ton of files that were no longer needed. That gave me another gig or so.

Satisfied that I had removed everything that I could, I ran DISK DEFRAGMENTER under system tools.  I carried on my office organizing as it ran forever it seemed.  In the report, I noticed three files that more than one gig in size.  They were back up and working files for Google Desktop Search, which I had removed quite a while ago.  So those were deleted and that freed up a significant amount of space.

So if you are struggling with hard drive space, remember:

1. Windows utilities typically only work for "your" files.  If you have admin rights, you can either log in as all the accounts on the machine, or manually remove extra files.  This tip is especially helpful if you inherit machines from other users, as is common in a corporate environment.
2. Check disk defrag reports for large files.
3. Use Windows XP Search to find unneeded files over a certain size.  I found some downloaded files that I no longer needed this way.
4. Don't forget to empty the recycle bin when you are done.
5. You can run a defrag multiple times to get better results.

By Karen Lopez on Tuesday, July 04, 2006 5:00 PM

Hannah Smalltree, writing for SearchCIO.com has a great short article on what early adopters of Master Data Management should do.  She calls it Best Practices, but I'd call it Minimum Requirements.  For instance, let's look at item 1:

1. Get business involved -- or in charge.

I always recommend that MDM efforts be started only when there is a clear business case (oh, and there always is one) and that the business organizations is on board, driving the effort.  I think it is like implementing Business Party in your models - IT can do all the modeling and drawing it wants, but true Business Party implementation can't succeed without changes to the business.

It's a great article, though. 

By Karen Lopez on Saturday, July 01, 2006 1:31 PM

Steve Ulfelder of ComputerWorld has a great article on Best Balance: How Top Employers Keep IT Staffers Happy.  He interviews employees and employers to find their tips on hiring and retaining IT talent. 

Interviews with Best Places IT organizations (see the complete Best Place to Work in IT 2006 special report)  uncover few secrets but much common ground where employee retention is concerned. The keys are careful hiring, a commitment to promoting from within, tireless training and -- perhaps most important -- challenging projects that offer workers the chance to handle hot technologies. Great benefits don't hurt, either.

His findings:

1. Promoting from within means you only have to hirer entry level employees.
2. Training, training, training...and education.
3. Use consultants or borrow from other groups during urgent needs so that you don't have to lay off employees during a downturn or when a project is completed.
4. Ensure your consultant are there for knowledge transfer, too.

What I find interesting is that many of these tips are anti-patterns in some shops.  I remember working for a client who insisted that his department have no interns or entry level position.  He believed that this somehow 'elevated' his status. 

Many employers withhold training for fear of losing IT staff who now have a greater skill set.  Yes, that happens, especially in government an education, where staff salaries are highly controlled and well below market value.  That means, though, that these employers must provide other benefits such as comp time, flex time, etc. to make up the difference.

Finally, the recommendation to use use contractors might seem conflicting advice.  Some full time employees I've worked with see consultant positions as money that could have been used to hirer a full timer..or two or three.  Yes, in some cases contractors are used to lower wages, but for a true consulting professional, there is no desire or need to fill a regular full timer role.  We often want to be the catalyst to allow the organization to get on track, farther down the track, or to the light at the end of the tunnel.

Every employee has something they want out of their employment, just as employers do.  This article shows that it isn't just salary and pay stubs.

By Karen Lopez on Sunday, June 25, 2006 11:35 AM

An article over on techworld.com reports that Microsoft will offer data modeling support in Visual Studio called Microsoft Entities :

The ADO team's ADO.Net Entities moves the data model up from the physical structure of relational tables to a "data model that more accurately represents business entities such as 'Customer' or 'Order' that could map to multiple relational tables and views," said S. "Soma" Somasegar, corporate vice president of the developer division at Microsoft. His blog is frequently a source of insight into what is going on at Microsoft.

A preview of Entities is due before the end of this year, and it will be in the Orcas version of Visual Studio.

Entities will allow developers to define complex mapping to relational data, enabling development of new business structures when the data schema cannot be changed, Somasegar said.

To me, though, this sounds more like functionality that DBMS vendors put on top of their engines in the mid-Eighties to make them look and feel more relational. 

What's really going to frustrate me when this comes out is all the conversations that go like this:

Me:  So if you look at the CUSTOMER entity, you c.....

Bob:  Uh, that's not an entity.

Me:  Are you saying that you believe it should be split? Or combined with another entity?

Bob:  I'm saying that you don't know what you are talking about, that's not an ADO .Net Entity..

Me:  Yes, this is a data model, not a ....

Bob:  Nope, that's not what a data model is.

Me:  Uh...not again.

I guess though, that since they chose not to call it ADO .Net Classes, at least they are admitting that classes and entities are not the same thing.  And perhaps that by wanting to appear to be more business-oriented, they believe that there is some value in business modeling and understanding business rules. Maybe.