Len Silverston and Paul Agnew have recently written a third volume of the Data Model Resource Book: Volume 3, Universal Patterns for Data Modeling.  This volume focuses on data model "templates" of highly reusable, industry-independent modeling patterns such as contact information, statuses, categories, hierarchies, etc.

These are generalized approaches model patterns that apply to every project, every industry, every business problem.  

Normally I'd write a review of this work, but since I was slightly involved in developing this work (I was a manuscript reviewer and I wrote the foreword), I'll leave it to you to read the foreword and to develop your own opinions of the value of this book.

Check it out and let me know what you think.

Comments (0)

Karen Lopez: Musings on Data, Process, and Architecture Reading, Watching and Listening

U.S. cell-only households keep climbing (Reuters) by Reuters: Yahoo! Tech

Are your business rules, embedded in your models, code, and data, keeping up with the real-world rules?  This recent Reuters news item shows that 18% of US households* have no land line -- they use mobile phones only for their phone needs.

Yet fairly recently I was asked to define a business rule that required customers to provide a "home" phone number that could potentially be checked against a service to require that it not be a cell phone number.

As much as I urged the business users to reconsider this rule, they were adamant that one could not be a customer unless one could provide a "real" phone number.  The ideas was that cell phone numbers were given only in an attempt to commit fraud.  I pointed out that even with checking, we could not be totally sure that any phone number provided by a customer was 1) theirs, or 2) a "real" phone number in the sense that it wasn't VOIP or mobile, or even virtual, as is my main phone number.

While I do believe that the customer...user...is always right, I believe that our job as analysts is to help users understand where their world, inside the walls of a corporate office building, can be inconsistent with the real world outside those walls.  Sometimes we manage to convince the project sponsors that certain business rules will cause them more pain that save them from pain.  Sometimes, not.

I remember at one point trying to convince a board member of an international data association that e-mail was a valid form of communication and being told that the Internet was a fad that would soon follow pet rocks and chia pets to a final resting place.  She was wrong about two out of three of those.

How far and and how hard we "push back" on stated business rules is about 95% politics and 5% stubbornness.  Maybe it is the other way 'round.  Either way, it's still our job to be analysts, not just robotic note takers/boxes and lines draftspersons.

*BTW, for almost 10 years an international standard defined a household as "People living at the same address, having the same last name".  Talk about not matching real world rules.

U.S. cell-only households keep climbing (Reuters) by Reuters: Yahoo! Tech

Comments (0)

Karen Lopez: Musings on Data, Process, and Architecture Reading, Watching and Listening

An excellent overview of Semantics, Ontologies, RDF, Owl and more...with a wonderful domain:

ABSTRACT

How ontologies provide the semantics, as explained here with the help of Harry Potter and his owl Hedwig.

Worth the entire year's subscription to the ACM digital library.

Communications: Volume 51, Issue 12 , Ontologies and the semantic ...

This recent SearchSOA article discusses one of the advances I'd like to see with all modeling tools:  integration with change measurement and change management tools.

I want to see more integration (not interfacing) with software development frameworks such as issue management, change management, monitoring, event management...all those systems management functions that we architects have been isolated from.

I wish our tools had better hooks into existing source control and versioning products.  I hope to see better links to project management and data management tools.

These sorts of integrations should be part of the natural progression from standalone tools to integrated components of the development process.  The better we can play with these other tools, the easier and faster it will be to collaborate with our team members.

Santa, are you listening?

On establishing the link between the business and SOA with modeling

Esther Schindler, of CIO.com, has pulled together a fantastic list of 26 signs you need to be working on your resume, fast....

They would be rolling on the floor funny if they weren't so... true... familiar... scary... and TRUE!  Some of my favourites:

The requirements definition is begun four months after development started.

The developer doesn't understand the spec document and continues to develop anyway. And the QA team doesn't know how to test, but they "test" anyway.

The technical project manager asks you to compose the list of user requirements—without consulting any actual potential users.

The program manager decided to try Agile methodology "to save time."

The lead developer tells you that maintaining a complete history of all database updates is a requirement for the application, but he hasn't had time to (read: doesn't know how to) design a data model for it yet. So he decides to go ahead and start with the Web front end and worry about it later. And this is the lead developer.

Probably should save reading the whole article until Friday afternoon...:).

26 Ways To Know Your Software Development Project Is Doomed

Comments (0)

Karen Lopez: Musings on Data, Process, and Architecture Reading, Watching and Listening