Erik on Software

Copycat Advertising Campaign

First of all, some readers of my blog might be curious as to why the category tag cloud in the upper right hand corner of the page includes "running" as a category. Where does running fit within a blog entitled "Erik on Software"? I eluded to an answer within my first post in this category. The answer is simply that the mind is software, and the body is hardware. Personal interest in the human mind crosses over from my fascination with software designed and created by humans. (And interestingly enough, two of my three posts on running are now #1 and #6 as the most viewed by visitors here, something that I find humorous since the subtitle of this blog touts "musings on business and technology".)

Posting on this topic has been light, mainly because I am so much more intimately involved in the latter category of software in the workplace, although of course I interact with other human software systems every day. My two last posts on running were associated with the ASICS brand of running shoes. In the first post, I discussed my long-term ASICS brand loyalty and raved about this year's ASICS advertising campaign ("The Cleansing Power of Sport"), and in the second post, I discussed my (only recent) disillusionment with ASICS mainly because of the latest iteration of its Gel Nimbus line of running shoes.

The trail running I normally do each morning for work has taken a backseat to the treadmill recently due mainly to the long commute I currently take to and from work each day to my new client, and one of the new channels I typically bounce between while running (CNBC, CNN, and Fox) played an advertisement by UnitedHealthcare during a commercial brake this morning that I had not previously seen. And the advertisement, part of a new "Health in Numbers" campaign, showed a runner eerily reminiscent of the runners in this year's ASICS advertising campaign. Check out the print version of this ad:

And here, re-posted for your convenience from my first post, is a close-up of one of the ASICS advertisements from earlier this year:

While words - in this case, associated with sadness (the other three ads of the campaign are associated with anxiety, stress, and worry) - flow away from the ASICS runner as part of a seeming exorcism-through-run, numbers congregate around the UnitedHealthcare runner like an aura (the company claims that they "use information and numbers from across the health care system to help you access health care that is simpler and more responsive").

Perhaps these two campaigns were created by the same advertising agency. Let's see. The ASICS advertising campaign is apparently being run by Vitro Agency. The UnitedHealthcare advertising campaign is apparently being run by Ogilvy & Mather. Uh-oh. You might have read in my bio that I worked for a company which is now global marketing intelligence firm Synovate. As an individual with both advertising and marketing research experience from that company, the similarity between these two campaigns is too close for comfort. What do you think? Send me your thoughts.

New Book Review: "The Data Model Resource Book Volume 3"

Recently posted book review for The Data Model Resource Book Volume 3: Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, Wiley Publishing Inc, 2009, reposted here:

Incredibly well done follow-up to the first two volumes of Silverston's data model series (see my reviews for "The Data Model Resource Book Volume 1 (Revised Edition): A Library of Universal Data Models for All Enterprises" and "The Data Model Resource Book Volume 2 (Revised Edition): A Library of Universal Data Models by Industry Types"). As discussed in the introduction to this book, while the first volume answered the question "Where can we find a book showing a standard way to model common data model structures?" and the second volume extended the template models presented in the first volume by adding additional data model constructs that are industry specific, this third volume answers the question "How can we quickly extend and customize these models for our organization and our needs to quickly develop any data model with higher quality, even if it is specific to our enterprise?"

The patterns that Silverston and Agnew present are categorized into chapters entitled "Setting Up Roles: What Parties Do", "Using Roles: How Parties Are Involved", "Hierarchies, Aggregations, and Peer-to-Peer Relationships: The Organization of Similar Data", "Types and Categories: The Classification of Data", "Status: The States of Data", "Contact Mechanisms: How to Get in Touch", and "Business Rules: How Things Should Work". Each chapter is well laid out, similar in style to other books of this genre such as "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. In this text, each pattern is laid out in its own section that answers the following questions: "Why Do We Need This Pattern?", "How Does This Pattern Work?", "When Should This Pattern Be Used?", and "What Are the Weaknesses of the Pattern?"

In addition, an aspect of this book that this reviewer especially appreciates is a presentation of each pattern at different levels. While the data management industry habitually refers to conceptual, logical, and physical data models, because there are widely different views as to the definition and purpose behind each of these types of data models (this reviewer is all too familiar with this inconsistency from his consulting engagements), the authors devised four levels of patterns that span from the most static and the more specific (Level 1) to the most flexible and more "generalized" (Level 4). The authors explain that the two key purposes of a data model are (1) "to illustrate and communicate information requirements, and (2) "to provide a sound foundation for a database design", and because these purposes can obviously be at odds with each other, depending on the stakeholders involved, care needs to be taken during the modeling process to determine appropriateness of approach.

While this reviewer offers no suggestions for alternative terminology, the decision of the authors to use the term "generalization" to describe the transformation of very specific data model structures to those which more flexibly support data requirements is interesting (especially given their explanation that they chose to do so since the object-oriented community uses the perhaps more intuitive term "abstraction" in a different way that has a different meaning) because this reviewer is well aware that software developers also use the term when referring to an object class superset that has object class "specializations". But despite this small matter, the consistent focus of the authors on the purpose of each level of data model presented throughout the text for each group of patterns (always discussing Level 1, Level 2, and Level 3, and sometimes discussing Level 4) is highly valued by this reviewer, especially when the authors discuss these levels in relationship to the Zachman Framework and other data model classification schemes.

This reviewer also enjoyed the last two chapters, entitled "Using the Patterns" and "Socializing the Patterns", in which the authors answer the questions "How do I use, apply, and/or implement these patterns in my enterprise?", "What is an appropriate balance between requiring adherence to the patterns and allowing them to be used completely optionally and used if and when they are helpful to the modeler/designer?", "How do you get your enterprise and various people in the enterprise to adopt these patterns?", and "What types of policies or principles regarding use of the patterns would be most appropriate to get the most benefit from these patterns?"

In the first of these last two chapters (Chapter 9), the authors demonstrate how the patterns can be used to create different data models that meet different needs, using the different levels of patterns as interchangeable components and combining them to solve common data modeling challenges for circumstances surrounding the building of prototyping and scoping data models, application data models, enterprise data models, data warehouse data models, and master data management (MDM) data models. In the list of additional considerations when using generalized patterns at the end of this chapter, this reviewer appreciates their remark that "generalized structures move the change process from the typical 'data architect to DBA to developer to tester' process to a data change process, and often organizations have no formal process for data change like they have for application change" and that "this can be addressed with organizational commitment to flexible data modeling structures", especially because this reviewer experienced firsthand the impact on culture when implementing database change management processes at his last two clients.

Chapter 10 addresses getting these patterns accepted and used appropriately, discussing in detail many of the objections that one might face in the workplace as well as what the authors see as key to success in this regard: (1) understand motivations and work toward meeting them, (2) develop a clear, common, compelling vision, (3) develop trust, and (4) manage conflict effectively. In addition to understanding the motivations of others, the authors also indicate that understanding one's own motivations is also important. While this last chapter is focused on the data model patterns discussed throughout the text, in the opinion of this reviewer the psychological aspects discussed are applicable to a much broader context in the workplace, and it can only help the industry if more authors choose to address such matters. Well recommended book to all data architects and other data management professionals.

New Book Review: "Enterprise Master Data Management"

New book review for Enterprise Master Data Management: An SOA Approach to Managing Core Information, by Allen Dreibelbis, Eberhard Hechler, Ivan Milman, Martin Oberhofer, Paul van Run, and Dan Wolfson, IBM Press, 2008, reposted here:

The best text on enterprise master data management (MDM) in the marketplace today. Other reviewers have commented that this work is "the Bible" of MDM, and this reviewer agrees with this assessment at a deeper level than acknowledging its near-600 pages of content. In addition to providing an introduction to MDM, the authors walk the reader through architecting solutions and provide industry examples at a level of detail not found anywhere else. As a consultant, one aspect of this book that this reviewer especially appreciated is its true vendor neutrality. It is not until Appendix B that the authors mention commercial products in this space, and although this appendix might help readers understand what might be purchased as commercial off-the-shelf (COTS) software, it is quickly apparent that there has been a lot of movement over the last two years.

Admittedly, after reading this book for the first time, this reviewer understands why the authors recommend first reading chapter 1 ("Introducing Master Data Management") followed by chapter 3 ("MDM Reference Architecture") and chapter 9 ("MDM and Data Governance") in order to understand MDM, data governance, and how to implement MDM, but these chapters also contain long stretches of content sans diagrams that are often slowly drawn out, so reading chapters in order is recommended unless the reader is already knowledgeable about MDM and is looking for industry-specific examples, in which case chapter 6 ("PIM-MDM Solution Blueprints") and chapter 7 ("CDI-MDM Solution Blueprints") should be read, or the reader is looking to integrate MDM with other systems, in which case chapter 8 ("MDM Integration Blueprints") should be read, although chapter 8 has difficulty standing on its own and the reading of chapters 6 and 7 heavily relies on chapter 5 ("MDM Architecture Patterns").

The authors present well MDM and service-oriented architecture (SOA) theory and how MDM enables SOA, and this reviewer especially appreciated their presentation on patterns and industry examples. MDM architecture patterns are broken down into (1) "MDM Hub Patterns", (2) "Information Focused Application Integration", (3) "Process Focused Application Integration", and (4) "Enterprise Systems Deployment", which are further broken down into the following, respectively: (1) "Transaction Hub", "Coexistence Hub", and "Registry Hub", (2) "Initial Load" and "Information Synchronization", (3) "Transaction Interception", "Messaging", and "ESB", and (4) "MDM-DW Integration", "MDM-BI Analytical System Integration", "MDM-ERP Integration", and "MDM-CRM Integration".

The authors follow up their presentation on patterns by providing solution insight to New Product Introduction (NPI) for the consumer electronics industry, Global Data Synchronization (GDS) for the retail industry, and PIM-RFID for tracking and tracing product, as well as solutions to Master Patient Index (MPI) for the healthcare industry, Cross- and Up-Sell and Fraud and Theft for the banking and insurance industry, and Self-Service Website for the telecommunications industry. Along the way, the authors discuss business context, relevant business patterns, relationships between business patterns and architecture patterns, and provide dozens of diagrams that tie-in directly to the discussion, walking the reader through architecture components and the interactions between these components. Expect to spend some time reading through these examples. Well recommended text on MDM for a wide spectrum of reader needs from the high-level to the deep-dive, but be aware that data models, a critical aspect of MDM, are unfortunately not discussed.

New Book Review: "Controlling Software Projects"

New book review for Controlling Software Projects: Management, Measurement & Estimation, by Tom DeMarco, Yourdon Press, 1982, reposted here:

 

This text was initially noted by this reviewer while reading a white paper written by Johanna Rothman that a colleague recently passed on to me entitled "Are We There Yet?: Creating Project Dashboards to Display Progress", and after a good experience reading "Waltzing with Bears: Managing Risk on Software Projects" by Tom DeMarco and Timothy Lister (see my review) this reviewer was ready to re-experience the superb writing style and diagram notation of the author. But then the publish date was discovered. Is it possible that a 30-year-old project management text can be appreciated in an age of agile development? In the opinion of this reviewer, large portions of this book are still viable, but the reader needs to maneuver through some of the information that is outdated, and in many cases downright risky to follow. Because of this intermingling, this reviewer can only recommend this text to readers with a substantive amount of software development experience.

While following a reading of this book this reviewer still recommends "Software Estimation: Demystifying the Black Art" by Steve McConnell (see my review) as the best overall project estimation text, what is appealing to this Six Sigma practitioner are the metrics presented throughout this text even though McConnell indicates that many of the early metrics that are still being referenced within the industry were harvested from large government projects. Metrics can be compelling, but it helps to understand that there are many different types of software development projects taking place in many different corporate cultures, and "Balancing Agility and Discipline: A Guide for the Perplexed" by Barry Boehm and Richard Turner (see my review) interestingly enough co-written by the individual who wrote the forward for the object of this review 20 years prior can greatly aid leadership in this industry as they choose which direction to take in this regard.

While the content in this book is well connected throughout, DeMarco discusses four main areas that are each dedicated a section in the book, although the largest amount of text is dedicated to the second section: (1) "Chaos and Order in the Software Development Process", (2) "System Models and System Metrics", (3) Cost Models, and (4) Software Quality. Some of the questions that DeMarco addresses might be posed as follows: What does it mean "to control" a software development project? What is estimation and how can it be approached effectively? How can project costs be projected into the future? How are metrics generated and who should do this work? What long-term benefits can be provided by a cost model? What exactly does software quality mean and how can related goals be achieved? The author also provides four appendixes, but in the opinion of this reviewer only the third, entitled "A Tailored Primer on Statistics", is suggested reading.

While less than 300-pages, this book covers a lot of ground. While the author carefully lays out his approach on how to gather metrics in the second part of the book, it is obvious from a year-2010 perspective that this method relies much too heavily on the classic Waterfall software development methodology, and so this part of the book should only be given a cursory reading. Some of the material in this section is beneficial, but harvesting this information is like separating the wheat from the chaff. In other words, while still taking into account the excellent conversational writing style of the author, the reader is advised to read other material such as that found in texts sited earlier in this review. Because DeMarco offers so many great diagrams in this book, a possible way to explore this third section is by looking at these diagrams to determine whether reading the surrounding text is worthwhile. The fourth section on quality does not seem to belong in this book, even if it were not for its lack of inclusion within the subtitle. The other two sections were well received by this reviewer, especially the first.

At the outset, DeMarco is entertaining by presenting the default definition of "estimate", which he writes is "the most optimistic prediction that has a non-zero probability of coming true", and his proposed definition of "estimate", which is "a prediction that is equally likely to be above or below the actual result". In addition, the author exposes one chief villain of accurate estimates: corporate policies that use estimates to create incentives. As the author explains, "when such a policy is allowed to prevail, the estimation process is nothing more than a charade. Whenever estimates are required, the person requiring them is not truly interested in the estimator's probabilistic assessment of when the work will be done or at what cost. Rather, the 'estimator' is being asked to establish goals for performance. In many cases, it's even worse: The 'estimator' is being asked to accept previously established goals. And what shall the characteristics of those goals be? If they're going to serve real prods for the development process, they have to be totally unachievable."

If you do not have time to sit down with this book for long periods, this reviewer recommends that the latter portion of chapter four where the author discusses five objections to empirical software projection be read at a minimum: (1) "We don't have the data. Without that vaunted bluebook, the metal extrusion estimator would be nowhere. That's where we are." (2) "Even if we have the data, we haven't got anything to correlate it with. What can we use as the early measurable indication of size? (If you say lines of code, I'll scream.)" (3) "Each software system is different. You can't use data about developing small on-line systems in PL/I with experienced people to project results for a development of large batch systems in assembler by novices." (4) "The data don't converge. The tolerances will be so wide that no one will accept the results." (5) "Upper managers won't accept the projected numbers because the figures will be too high. The worker bees won't work as hard without unreasonable numbers to strive toward. Everybody's ego will be offended by the idea that the work is predictably doable and that people's efforts are interchangeable."

As this reviewer wrote the list in that last paragraph, he was reminded of some of the technologies mentioned by Frederick P. Brooks, Jr. in his classic work  entitled "The Mythical Man-Month" (see my review). "PL/I"? "Batch systems"? "Assembler"? As this reviewer mentioned in his earlier review of "Object-Oriented Technology: A Manager's Guide" by David A. Taylor, "the next language of the day/week/month/year" will come and go soon enough.