Aus einem Artikel auf TR: Das offenste aller Autos:

Bremslichter vorn am Auto anzubringen, ein solcher Vorschlag mag im ersten Moment skurril wirken. Aber aus der Sicht des vor dem Zebrastreifen wartenden Fußgängers erweist er sich als gar nicht dumm.

Und zum Weiterlesen: Full speed into crisis

Found one more reason to keep consuming IT-Weblogs from the US:

First, truth-be-told it really does not matter what process or method you leverage to understand your enterprise problem domain best...ITIL, 12 steps, or your own approach, who cares? As long as you have a basic understanding of semantics, services, and processes so you can select the right solution.

Second, all of this process and mythology stuff we're bringing to SOA is kind of boring. I mean you're not playing with technology...instead service directories, process diagrams, and data dictionaries. What fun is that?

The reality is the core of architecture is not sexy. There is a lot of grunt work that has to occur before you get architecture right. Those who charge at this problem shouting: ESB! Governance! Data Integration! Or, whatever hype-driven buzzword is currently being tossed around, are more than likely to fail. So it's boring...but boring is good in this case.

If you want excitement, do some base jumping, extreme skiing, or shark wrestling...leave your enterprise alone.

-- found in a InfoWorld-Post by Dave S. Linthicum

Scotsman and Artist-husband* Donald Farmer proposes four classes of data quality issues in his "relaxed" Weblog. This is the introduction he gives:

So, being passionate about data quality, I am naturally interested in classifying data quality issues. Nor am I alone - many papers have been written detailing what errors can occur in data, and the myriad ways in which records and datasets can have poor quality. One of the most effective and most popular has been to talk about dimensions of data quality - accuracy, consistency, timeliness, completeness etc. And within these dimensions we can talk about the different types of, say, inaccuracy: invalid values, incorrect representation and so on.

I'm interested in classifying these issues from another angle. I can summarize the approach (whence the title of this post) as who says this value is invalid? What does it mean to say that Redmond, WA, 98072 is inaccurate, or that Dave is not a short form of Christina for the purposes of record matching?

I think of this approach as being about premises of data quality - not just the ways in which data manifest poor quality, but the bases which we determine what quality itself means in such cases.

As I said, I'm a classifier, so I have been doing some classifying of these data quality premises of data, and have defined four that I find particularly useful.

• ... and also Group Program Manager for SQL Server Integration Services at MSFT ...

Update (2006 08 16):

Tried to post this as a (polite enough?) comment to Donald's Weblog ... see what happened below. Need a scotch now.

Die Frau Kullman bei Neon schreibt hier:

Ich muss zum Alleine sein alleine sein.