Doing the Data Mashup

Good to see you again, and glad you are interested in seeing how new trends affect us data professionals. I ended the last blog introducing mashups, and briefly discussed how mashups impact the data architect, data analyst, and data modeler. As an example, let’s say there is a requirement to build a new datamart to view sales by region, which also provides links to GoogleMap so users can see maps, visualize distances, and leverage other features within GoogleMap. The user after entering some specific product and region, might see something like the below:

The Sales Region you have selected, Sales Region T050, had sales of $150,000 last quarter. This sales region is shown highlighted in the map below. The four top cities are highlighted with the blue markings. Feel free to drill in to see details or drill out to get more of the big picture.

The data architect needs to understand how mashups such as GoogleMap and this new data mart fit together. That is, the IT word of the decade: ‘integration’. She therefore requires insight into the GoogleMap design, and might spend some time reading GoogleMap documentation (see http://code.google.com/apis/maps/documentation/index.html). A mashup assumes the component applications can talk to each other. So in this example, there is a subset of geographic information (such as address or longitude and latitude) that is common across both applications. This makes having well-integrated data (at least for the touchpoints) even more important.

The data analyst needs to fully capture the requirements from the user. To ask the right user questions the analyst needs an understanding of the functionality within the existing GoogleMap system and discuss with the business user which subset of this is needed for the datamart. Not only will she need to understand and document the requirements provided from the user, she must also know what it is possible using GoogleMap and present some ideas to the user. For example, would the user like to see the distance between markings, have the ability to create custom placemarks, collaborate with other users, etc.? The analyst therefore also needs to spend some time on Google’s site, but more on the functionality of GoogleMap than the backend where the architect will be focused. She might visit the GoogleMap Mania Site for example, http://googlemapsmania.blogspot.com/. The analyst can really let those creative juices flow. Michael Ogrinz, in his book Mashup Patterns: Designs and Examples for the Modern Enterprise, phrased this more eloquently than I just did in the previous sentence about creative juices:

The greatest benefit of mashups may be their influence on our thought process. When we cast off our biases about the role of technology in the workplace, we discover the folly in applying IT to only the most obvious and well-understood problems. Once the blinders have been removed, you'll discover a world of missed and previously unknown challenges that you can tackle. Recognizing these opportunities is just the first stage. If you don't do something about them, then you've simply added to the tangle of unmet expectations. To achieve continuous innovation, it is essential to look outside the existing methods of measuring and meeting user demand.

The data modeler also has more work to do. She will be responsible for building the subject area, logical, and physical data models for this new datamart. A large part of this modeling effort requires knowledge of existing systems. Google the phrase “GoogleMap data model” and “poof”, no data models come back. Luckily there is less of a driver to build logical and physical data models for existing external application components like GoogleMap. Similar to when an organization purchases off-the-shelf software, there is less of a need to analyze and model the software as we do with custom-built applications. At a minimum however, she should build a Subject Area Model (SAM) that communicates the key concepts within GoogleMap, along with their definitions. We should also have a detailed understanding of that information that needs to be linked to another application, such as GoogleMap’s coordinates information. Perhaps this detailed understanding of the interface is at a logical level, and can leverage existing work that the data architect has done.

So even though we are not writing a brand new application to do map visualization, the data folks are not off the hook. The data architect needs to address the integration issues, the data analyst needs to address unspoken requirements, and the data modeler needs to model at least at a subject area level the mashup components.