I'm scheduled to speak at a DAMA Chapter in the next few weeks. As a former DAMA chapter president, I'm always careful about booking the least expensive options for travel since DAMA chapters are not-for-profit organizations.

I start by looking at my preferred airline to see what it would cost to fly them, then make my way through their alliance partners, then do the bottom line Expedia.ca search. I pick the flights that are least expensive and don't require me to spend the night on a plane or at an airport. So for this trip, USAir came up as the least expensive (and I don't have to take a red eye or stay overnight in any airport). Bonus! The base fare was only $370, which is quite a deal these days to go anywhere. Of course, the taxes, security fees, agricultural inspection fees, immigration fees and fuel surcharges add another $110, but that's the way the airline business wants to play pricing these days. So I booked my flights through USAir.com and was presented with a confirmation page on the website that looked like this:

You can see that the base fare is $371.54 and the Total Fare is $481.05.  Both of these amounts are most likely in US Dollars since I purchased this from a US website.

A few minutes later I get an e-mail confirmation of my purchase with the same confirmation number/locator number.  However, this e-mail has different amounts:

Now the amounts have mysteriously changed to a base fare of $408.02 and a Total Fare of $517.53 .  US Air has also added a Canadian dollar amount of $451.75.

My first guess at the source of these new numbers was that I was seeing Canadian dollar amounts, but that doesn't fit, as the exchange rate today is about $1 USD = $1.018 .  That translates to close to par, or equal, give or take a little under 2 cents.  At any rate (pun intended), $517.53 is not the US Dollar equivalent of $451.75 CDN, nor are either of those figures an exchanged amount of $481.05.

So given my luck with travel issues of all kinds, I call USAir to ask what I was actually charged.  Of course, there's no website phone number for calling about random data being spewed by their automated systems, so I call reservations.  The woman I spoke with said that my credit card was charged only the first amount, $481.05 and that the odd number I was seeing on the e-mail were due to the fact that the Canadian dollar was so much weaker than US dollar (not these days, lady).  Besides, if that were true, why do I have three different numbers?  Are we trying to triangulate the Euro, too?

I worry that the reason she thinks I was charged this amount is that she is looking at the same data I was when I was reading the confirmation page after purchasing my tickets.  However, what data is the e-mail receipt system reading?  Perhaps the actual accounting system?  The payment authorization system?  Someone else's flight information? Some systems that mysteriously adds fees or  increases prices?

When I pushed for more information, she gave me a phone number for Accounting, so that they can help me.  I call this number, but as you probably already expected, this toll free number only leads to recordings about how to write a letter to USAir to dispute charges.

I call USAir again and am told that I have to contact website help, as they are the ones sending out the e-mails.  I doubt this, but I use the contact form on the website to note my information and my issue with their information quality.  The website contact form has a confirmation page that looks like this:

Notice that it says that someone will get back to me in 24-48 hours.  The website system also sends me a follow up confirmation that looks like this:

Notice that the response time period goes from 1-2 days to 5-6 days.  It seems to be perfectly fitting that a customer who is given three different, inconsistent pieces of information about how much I was charged to be given:

1. Incorrect information about how to get this resolved
2. An incorrect phone number
3. Inconsistent information as to when or who will respond.

Anyone want to guess how much my credit card is actually going to be charged?  My guess right now is for the lower amount, but I wouldn't be surprised to find out that there were three charges making their way to my bank, or none...or even a fourth random number.

Come on USAir, let's get your act together.  Get your systems talking to each other.  Yes, I know I get what I paid for.  I could have paid about $500 more to book with another airline, but I didn't.  I chose you.  Perhaps I could get a reasonable response as to what I'm actually going to pay for these tickets.  And maybe, just maybe, it will be the price that you promised when I booked the tickets.

Mirza Dharani and Dyuti Patankar presented a session on their case study of working as data architects in implementing SOA services.

Their first tasks were to consolidate their logical and physical data models.  As with many of these data model rationalization projects, the choosing of a common name for a variety of elements was difficult.  This effort also involved creating common names for XML tags.

Also part of their "commonizing" of various data sources was examining and making consistent values of attributes.  For instance, Gender Codes may be alpha in one system and numeric in others.

Their efforts also included establishing common derivations.  The found that as time goes on, the complexity of their derived data increased.  They observed that users have differing derivations for derived data with the same name.  Part of the training they needed to provide included educating end users that these terms that had differing derivations would now be standardized -- so everyone who asked for a Contract Number would get only a contract number.

They also created common services for hierarchies by giving common codes to each level of the hierarchy, then providing services for retrieving those specific levels.

Again, another session that could have been a double session with all the questions everyone had!

________________________________________________________

Impact of Service Oriented Architecture on Data Modeling: A Case Study

Mirza Dharani
Data/Integration Architect
Allstate Financial

Dyuti Patankar
Data Analyst
Allstate Financial

Thursday, March 20, 2008
08:30 AM - 09:30 AM

Level: 
Intermediate

In an enterprise with multiple data sources resulting in an environment where multiple interpretations of similar meaning data exist, data modeling is a challenge. Supporting services adds to this challenge. We will discuss how data modeling was affected by service oriented architecture using a case study of building an operational data store and an operational data mart.

Attendees will learn:

• How to support service oriented architecture initiatives to provide common derivations and common hierarchies to multiple consumers such as integration, application development, and end-users
• How to enable common services through rationalization, common name space, and common codes in data modeling
• How to leverage and extend solutions into larger problem spaces

Mirza has over twenty years of experience in Information Technology. At Allstate Financial, he is the Data/Integration Architect on a wide variety of strategic projects. He has lead enterprise efforts to support service oriented architecture in modeling data sourced from multiple legacy systems.

Dyuti has over ten years of experience in Information Technology including data modeling and business intelligence. At Allstate Financial, she is actively involved in various strategic projects that focus on enhancing the business intelligence initiatives of the company. She is working on starting a Dimensional Modeling Community of Practice within the organization, which will serve as a forum to establish and share enterprise-wide best practices. Before starting at Allstate, she worked as a consultant on various BI projects involving data modeling, OLAP, scorecards, dashboards, and corporate performance management.

The session I am attending just after lunch is by Dr. Tom Johnston of Mindful Data.  He is focusing on the 5 different types of keys and making assertions about selecting primary keys:

• all primary keys should be surrogate keys
• all surrogate keys should be globally unique (unique across all rows of all tables)
• all surrogate keys should be system generated

He also talked about other types of keys: business keys, foreign keys, and intelligent keys.

He did point out some holes in the Relational Model and Codd's Information Principle, one being that the relational model calls for the mixing of business keys and primary keys in order to support the semantics of the data.  As Dr. Johnston points out, this leads to problems when these business keys change (meaning that the semantics are impacted).  He believes that Codd's Information Principle will become more obsolete as more formalizations are developed.

He was able to lightly touch on FOPL, a type of formalized predicate logic.  I'd like to see a whole day or two on this.

All in all this was a very thought-provoking presentation.  I wish there were more time for this topic.

__________________________________________________________

Primary, Surrogate and Business Keys: the Semantics and Syntax of Codd’s Information Principle

Thomas Johnston
Principal Consultant
Mindful Data

Wednesday, March 19, 2008
01:15 PM - 02:15 PM

Level: 
Advanced

Business data describe the objects of interest to us; that is their semantics. Primary keys distinguish, and foreign keys refer; that is their semantics. Therefore, to use business data in primary and foreign keys forces that data to play dual semantic roles.

When those roles conflict, we may be forced to change specific values of primary keys and their related foreign keys, or even change their data types and lengths. Often such changes cannot be completed as an atomic transaction. The result is semantic dis-integrity (broken joins), or else a very high cost to avoid it. These costs will be illustrated and explained in this presentation.

Some professionals object to surrogate keys because they believe such keys violate Codd’s Information Principle. Recent comments of Chris Date’s indicate that this is his position. But the Information Principle can be taken as either a semantic or a syntactic principle.
• As a principle about semantics, the Information Principle forbids surrogate keys, and is wrong
• As a principle about syntax, it permits surrogate keys, and is right

Additionally, over the years, data modelers have developed their own practice-based objections to surrogate keys. These objections, too, will be illustrated and discussed in this presentation.

Dr. Tom Johnston received his doctorate in Philosophy from the University of Georgia in 1979. His studies focused on epistemology, ontology, and the philosophy of language. The logician W. V. Quine was a central figure in his doctoral dissertation.

Tom has been working in business IT for over three decades and has worked as a data modeling and data architecture consultant for the latter half of that time.

In the last decade, Tom's publications have focused on improving system and database flexibility by late binding semantics to both data schemas and to code. Tom is currently co-authoring a series of some thirty articles, in DM Review and DM Direct, on how to manage historical data about persistent objects, using today's DBMSs and today's SQL.

One of the more exciting announcements at the DAMA Conference is that John Zachman has a new version of the Zachman Framework, appropriately named Zachman Framework 2

Rob Drysdale blogs about this announcement.

John Zachman introduced a new version of the Zachman Frame.work with new names and one more row in the earlier session.

Stan took the new framework and broke it down into various parts and showed how it really is an enterprise model and put it all into business terms.

He began by breaking it into into four quadrants that can be used by business leaders to help manage an enterprise.

The four quadrants are:

Resource ideas (top left)

Behavior ideas (top right)

Resource reality (bottom left)

Behavior reality (bottom right)

Stan then went on to show how each row and column can be broken down and put into basic English to describe what each row and column means and give more meaning to it than the simple row and column headings.

Each row can be represented by what is in it:

Row 1 is lists

Row 2 is semantic models

Row 3 is schematic models

Row 4 is blueprint models

Row 5 is listings

Row 6 is instances

Then the actions and perspectives and outcomes of each row can be analyzed

If you put each of these together you end up with a sentence describing the row. For example the architects' semantic models define business.

The underlying idea here is to stop referring to these concepts by the row or column position, but by the name or what is in each box. This is how it can be the most help to everyone especially business users and leaders.

Note from Karen:  I think that last point is a really good one.  I've seen many eyes glaze over so fast when a team of data architects starting talking about "row 2 and row 3 column 1 models". 

I do like these new names and approaches to the Zachman Framework.

_________________________________________________________

Zachman Framework² for Management Control

Stan Locke
Managing Director
Zachman Framework Assoc

Wednesday, March 19, 2008
10:00 AM - 11:00 AM

Level: 
Intermediate

Until the Enterprise Architecture artifacts are employed by senior management in the day-to-day operations of the business, Enterprise Architecture is going to be perceived as overhead and will always be vulnerable to short term, cost saving, budget cuts. This presentation explores using the Framework as a senior management tool in control of the business of the Enterprise.

Stan lectures on the implementation of the framework concepts, bringing a practical business perspective to the framework logic. Since graduate school, his special interest is in the management methodologies required to define an enterprise and the ways in which this can be represented in repository technology. Stan has been the architect of the Zachman standards under John’s direction, model builder of the hexagon implementation constructs and directs the applied research through ZFA.

Hudson's Bay Company is Canada's oldest retailer -- more than 307 years old.  Binaifer and Irina's session is a case study of their meta data program.

They use CA ERwin for preparing data models.  Teradata SQL is used to do downstream views impacted.  They use Informatica MetaManager for administering their meta data program.

Some of the prepackaged reports they offer:

• Re-usability analysis of objects
• Data Integration operation and administration
• Metamodel exploration (class inheritance, class attributes)
• Mapping of dependencies from source to target

They also map their meta data to an industry standard XML schema, the ARTS XML (IX Retail) schemas in MetaManager.

In the future they hope to build a more business friendly view of their meta data tools, as they feel that currently their tools are not usable to a wider business audience.

__________________________________________________

Role of Metadata Management within the Integration Framework at Hudson's Bay Company

Binaifer R Karanjia
Data Architect
HBC

Irina Kleiner
Senior Data Analyst
HBC

Wednesday, March 19, 2008
11:15 AM - 12:15 PM

Level: 
Intermediate

HBC is currently setting up an Integration Center of Excellence using the SOA Framework and Metadata Management is at the core around which all the other services are planned to be structured. The presentation will show the work we have already done in implementing an Integration Metadata Management Framework within the Organization and how we plan to use this Metadata. The key areas for which HBC envisages to use Metadata Management are: 1. Interface Inventory 2. Understand the Lineage 3. Impact Analysis and Change Management Process 4. Linking the Business and Technical Metadata. The presentation will seek to enable the audience to appreciate the point of arrival for HBC in this journey, where we are and the process we have followed to reach this stage in our journey and the road ahead of us.

Binaifer is working as a Metadata Architect with Hudson's Bay Company(HBC) with the Integration Center of Excellence (ICE) Group. She is responsible for setting up the Metadata Center of Excellence within HBC. Prior to this Binaifer has worked extensively in the field of Data Warehousing with organizations such as IBM Business Consulting Services and NCR Teradata specifically in the area of Data Modeling. She has done her Bachelors in Engineering followed by a Masters in Management.

Irina is working as a Senior Data Analyst in Hudson's Bay Company(HBC) with the Integration Center of Excellence (ICE) Group.

She is a part of the team for setting up the Metadata Center of Excellence within HBC. Prior to this Irina has worked extensively in the field of Data Management with organizations such as Sun Life Trust & Securities, Ministry of Public Health (USSR) specifically in BI. She has done her Bachelor in Information Technology & Masters in Science.