Andrew White

I took a fascinating briefing today from a vendor that has announced a SaaS-based Order Management offering.  I took the briefing in order to discover how the vendor had solved the problem of integrating the use of master data across the enterprise firewall; this has to be an issue for any user of SaaS-based business applications since some master data will have to be exchanged between the applications behind and in front of the firewall.  Salesforce.com has to synchronize customer master data between its own applications and those used by its customer behind their firewall.  For me, the key questions for any SaaS offering that purports to re-engineer a process:

a)     where is the master data mastered?  Has this location moved?

b)     Is the business process different, or is SaaS simply being used to move the boundary of application interchange across the firewall?

So far, all SaaS offerings I have seen really only move the boundary of the processes, and as such, the “what” moves across the firewall changes.  The business process itself is virtually unchanged. 

Secondly, where the master data is mastered has also not changed.  For most firms, though not all, master data is viewed as sacrosanct and is mastered – and protected – behind their firewall.  Only subsets of master data are exposed in any B2B fashion (think of what content goes into an EDI transaction) and there are strict controls over what is hosted or managed outside the firewall.

If the user is not willing to accept the change in costs, both in terms of organization and technology, associated with the movement of master data mastering, and if the processes remain pretty much the same and the boundaries are just moving around, the SaaS offering itself is pretty much a waste of time.  And this last point was the most interesting for me: I represent business users who talk about business process and execution of same; and the knowledge of MDM exposes to me some major issues and challenges with SaaS; yet technologists that are into architecture, SaaS and cloud computing hype, would argue that such (new) applications are “awesome” and “new” and “innovative”.  They may by – but I challenge vendors to explain to business users what is the material benefit to the business in deploying SaaS offerings.

By the way, Happy New Year to you!

After my blog on When is SOA, DOA? When it’s without MDM!, a vendor kindly sent me an email that explained how they too had similar ideas regarding the important link between MDM and SOA.  Oracle wrote a white paper entitled, MDM as a Foundation for SOA, in November 2007.  The SOA Magazine published in July this year an extract of the white paper, called Data Management: The Missing Link in Your SOA Strategy.  I have to say that the extract is well written, and in fact includes a nice, and more importantly, simple business example, of how MDM and SOA work together.  

I single Oracle out with this blog, but other vendors do “get” the link between MDM and SOA.  I would characterize the vendors that do “get it”, as those that typically have sold offerings into complex areas, where business applications or business intelligence applications intersect with other applications (pre application consolidation toward ERP), or where there is a lot of application to application interaction for complex business processes.  This is quite common in Supply Chain Management, and so many SCM vendors “get” the connection between supply chain oriented master data (products, parts, bills of materials, constraints) and how the “single view” of them are required when composing new business applications.

I have not linked to many vendor white papers so far in this blog, and I don’t anticipate linking to all that I see or hear about.  But Oracle was quick in replying – so they get the coverage today.  Thanks Avi.

I wrote a short time ago about how MDM can help firms cope with the current economic down-turn.  Specifically, I talked about how MDM can help reduce business costs (lower inventory levels, and rationalize supplier spend) as well as help protect customer service and revenue.  It seems that many different areas of IT are also being applied or adjusted to help with managing the business in a down-turn.  Putting on my old “supply chain” hat this morning, I read one of the vendor newsletters.  Here is Barloworld Optimus’s “Inspiring results in Supply Chain Planning”.  There is a neat script explaining how demand planning can be used to help evaluate the market conditions that you might face.  The “Woolworth” situation referred to in the article is the situation (in the UK in this case) where a large customer (Woolworth’s) just happens to go broke or into receivership and as such, a large percentage of your customer business might literally, overnight, disappear.  Demand Planning can help you evaluate what the impact might be on the business, and play ‘what-if’ games to determine what actions can be taken to help negate the impact.

This article reminded me of a TV program I watched last night.  It was a CNBC documentary program called, “Saving GM: Inside the Crisis” (re-aired December 12^th).  The focus was the supplier community that has built up over the years around the US auto-industry.  Though the program reported the possible, even likely, negative impacts on families through pending lay-off’s, I was left with some major questions in my mind.  Why did and do so many parts suppliers remain focused on a customer base that has been dying slowly for years?  One part supplier covered in the program explained how, over 50 years, they built up a business that is fully 50% dependent on GM specifically, and indirectly via other component suppliers, 80% dependent on the US auto-industry in general.  Why on earth did the supplier build such a risky business model?  Why didn’t they evaluate the possibility of targeting the aerospace and defense industry?  Or the commercial airline industry?  Why put all their eggs in one basket?  Surely any good business strategy would lead suppliers to build a robust customer base…  Perhaps these suppliers were just too “heads down” focused and not business savvy.  Perhaps they didn’t use IT to help play, “what-if” games to evaluate the impact of market dynamics on their business.  Hopefully there is still time for these firms to adopt technologies like MDM and Supply Chain Planning to make better, smarter decisions, to save themselves money.

Toby Bell, a colleague of mine at Gartner, just published a note called, Get Ready for Content in the Cloud.  The note focuses on the rapid growth likely to be seen in content and services in SaaS deployment models, which exist outside of the firewall and hence in the “cloud”.  When the word “content” is mention we often need to be clear what we mean since content means different things to different people.  For many users, content is synonymous to “unstructured data” which, as my good Gartner friend Mark Beyer will attest vigorously, does not really exist.  Data can hardly be unstructured – it may have implicit structure – it is just that the data may not be understood by people, or computers.  So the real measure is of “machine readability”.  If the data is of “high machine readability” then there is a chance we can automate aspects of management and use of the data.  If machine readability were “low” then there is much less chance we can do this.  But I digress…

The Content in the cloud note really talks about content as email and records management.  There are, of course, lots of email content and records across firms.  In my part of the business, there is an awful lot of highly machine readable data also, that acts like content in that the machine readability is not as high as users would like, or worse, there are competing or alternative ways of interpreting that data.  So the note made me think of an MDM Prediction we are working on for our end of year publication.  

We stated at our recent MDM Summit, “By 2012, 20% of revenues associated with MDM will be sourced by Software as a Service (SaaS) or Cloud Computing Deployment models”.  For MDM, content is real business data that can be used to make the business work more efficiently or effectively.  And some business oriented master data is already sourced from “cloud-based” offerings.  In MDM for Customer Data there are many marketing service providers that offer actual data (think Acxiom, D&B, TDlinx, customer data) as well as services (think of cleaning up customer data files) and in MDM for Product Data there are industry oriented product catalogs (think Bighammer, 1-SYNC, Inovis) that help grease the skids of business-to-business.  So cloud-based content is not new to MDM; but there is certainly a potential for more hosted offerings, services, and data, in the cloud.

The question today is really focused on, “to what degree do firms accept, and even seek, what might be perceived as confidential information, from outside the firewall?”  Some few firms accept that some aspects of product data are NOT confidential and COULD be sourced from outside the firewall.  But when it comes to customer data, and even customer lists, that data is a tad more sensitive.  So MDM spend, related to SaaS and cloud based computing, is likely to be held back for some time.  Perhaps the 20% by 2012 was overstated at the Summit: it might be nearer 10% or even less.  What do you think?

About two years ago Kathy Harris (see her blog here), a colleague of mine, and I spent some time with an idea that went nowhere.  The idea we explored the issue that arises when firms segment their customers, yet customers don’t always follow predictable patterns of behavior that are implied by the suppliers segmentation of the customer.  Still with me? 

Many firms segment their customers in order to focus energies and services more effectively.  We all know the truism that some customers are more important than others (just think about the period end to prove the point) but most firms are not able to treat customers equally even if they wanted too, since resources are finite.  So customer segmentation makes very good sense; it should support notions of leverage of supplier resources in order to better relationships and revenue exchange.  But, the way firms segment their customers do not, as a rule, follow the methods by which customers segment themselves!  So the question arose: would it be better (i.e. more revenue) for the supplier if they could a) understand how customers segment themselves, and b) can a supplier actually relate this segmentation to how they do business?  Can an inside-out viewer understand an outside-in view, and map to it?

Little did I know but this question had some roots in semantics, and MDM. But before I can make that link, we need to first look at segmentation.  Just look at your son or daughter and evaluate how they define their social networks – both online and offline.  These networks, the aggregation of them, represent a near-unique structure that would large numbers of preferences, likes, and intentions.  But these segments are self-described (with respect to the firm, even if they are offered by 3^rd parties who want you to join their network), and most likely not even related to the suppliers of products and services.  Kathy and I came to the conclusion, 2 years ago, that there were two maps that needed to be bridged: one map represents how the firm looks at its customers and market; and the other is how the individual customer relates to all other market stake-holders.  In fact, the problem is how to map ontology’s.

Now before you go all bleary eyed on me, don’t panic!  This is not that hard to talk about, really.  As Wikipedia states, “An ontology in computer science and information science is a formal representation of a set of concepts within a domain and the relationships between those concepts. It is used to reason about the properties of that domain, and may be used to define the domain.”  So a very large and complex ontology could be used to describe how my son connects and relates to all manner of networks; and a much simpler one could be used to describe how a firm perceives its markets and customers, and how they relate to each other and how they are segmented.  

MDM comes in as part of the semantic dialog in that to bridge the ontology’s, some semantic mapping needs to take place and where would you start, but with the master data that is re-used across the ontology’s: the common keys, if you will.  So why this post today?  It so happened that I spent yesterday with a large technology vendors who is researching (they have a large technology research body) how to get commercial value from, and I paraphrase, the semantic enterprise to the semantic web.  I coined the term semantic enterprise 5 years ago when I presented, with another colleague of mine, Simon Hayward, on the topic of the Connected Enterprise.  The premise was: how does a firm change its behavior of semantics were pure and consistently clean across the enterprise.  Today of course we spend a lot of our IT budget coping with the fact that much of our data is messed up, duplicated, of poor quality, and so on.  Semantic are rarely top of mind of executives, but it seems that semantics, or the miss management of them, are the root of many of our mutual ills.

At least I found a peer in industry that is looking at the same problem- and a peer that has some emerging technology that may, in time, prove valuable.  And whoever thought that talking about semantic and ontology’s was boring?

I was trolling my email “inbox” this morning and I read with interest an email from a vendor I met recently at a briefing.  In November, Panjiva updated me on their business: their offering is based on knowledge gleaned from perusing all the inbound manifests for goods arriving in the US.  By analyzing the data, both quantity, content, and frequency, Panjiva can discover information describing how supply chains are performing, as well as the overall economic cycle with respect to purchasing patterns of US firms.  They started by looking at apparel product and supply chains but they are expanding now into many other segments.  

After reading my interesting email, I then turned to my Financial Times and there, on the front page, was the same article from Panjiva.  The head line read, “Slump in US clothing sales leads to 70% fall in overseas suppliers.”  The fascinating article, referring to the same source in the email I had received, reported a reduction in total volume, and number of suppliers (70 per cent between July to October 2009), servicing buyers of apparel products in the US.  Of those suppliers shipping, they report a reduction in volume of at least 75 per cent.  This is frightening data that highlights how the results of the credit crunch are winding its way through the economy.  No wonder many manufacturers are ramping up with their cost cutting efforts.  

Ignoring the actual content, Panjiva is an interesting vendor.  The value proposition is innovative.  By sniffing data that is effectively public (you have to pay the US Customs a small fee to buy the data, every day) and applying specific metrics and analytics the vendor has been able to interpret dumb data and infer business trends that help business users make smarter decisions.  The vendor is now building a business by selling their inferences and insights back to the buyers, and sellers, to help them look for new and better opportunities to improve business.  This is not quite an MDM play, but certainly a neat play on finding value from information that has been around for a long time.

Don’t forget to look at Gartner’s initiative to help IT cut business and IT costs.  We have lots of research that addresses many aspects of the business that you should be leveraging.  

Deb Logan, a colleague of mine, just published a note (see Enterprise Information Management Revisited: Foundations, Progress and Futures) that nicely updates us on the state of Enterprise Information Management (EIM).  Nestled in the note is also a description that relates this holistic information management strategy with numerous other initiatives including MDM.  

The document serves as a starting point for any client wishing to understand enterprise information management (EIM) or undertake an EIM initiative. We would recommend that it be read by information architects, information managers, CIOs, enterprise architects and anyone working on a team evaluating or implementing a portal, an enterprise content management system, a business intelligence application, a master data management system, document centric collaboration, eDiscovery, information access or collaboration software.

We all know that SOA is a design style – a way of developing applications and integration.  Adopting SOA leads to a change in the way ‘stuff’ happens.  Gartner, and others, have published widely on the different uses of SOA, and I myself wrote a note some time ago on where SOA adds most value to the business.  Recent dialog with users has shown however that the majority of spend focused on SOA has been on more tactical uses of the approach; in simplifying integration techniques.  Given my background in Supply Chain, I would argue that there is potentially far greater value to the business from SOA at the strategic level, that is, in the rapid orchestration, and re-orchestration, of business applications supporting new, evolving business processes.  The baby steps of “simpler integration” are fine, but SOA needs to be more relevant to business if IT is to leverage the approach and support the business. 

In doing over 45 reference calls for last summer’s Magic Quadrant for Master Data Management of Product Data, I found 2 customers that explicitly had connected their MDM strategy to their SOA strategy.  That is a terribly low number – but not surprising to me.  The weakness this exposes in many SOA strategies is that it creates a huge risk factor that threatens to undermine SOA and lead to failure. 

When designing a new business application with application and data services that span multiple data stores (as they exist today), something has to incur the cost of reconciling the different [master data] semantics across the multiple data stores.  Today, IT has to incur this cost with yet more integration work that seeks to link each stove pipe of data to the next with ever more complex point to point or spaghetti integration.   With any new application this same spaghetti has to be expanded, unless something different is adopted. See When SOA Breaks, What Then?   With SOA the development of new applications means many more service to service interactions; far more than there were between today’s far less granular application to applications.  Clearly, if every SOA-based application interaction had to incur the costs of data reconciliation, mapping, clean up etc, then the cost of building and maintaining that SOA-based application would exceed what it costs today without SOA.  The bottom line: SOA needs MDM to help with the evolution of the information infrastructure.  See The Role of Master Data Management in the Business Service Repository for one view on how MDM will get aligned to a SOA oriented strategy focused on reusable services.

However, the reason why so few users align MDM and SOA is because so little SOA is really focused on the high value-add parts of the business, that being between application and/or data domains.  Most SOA oriented spend is focused on tactical improvement centered on integration currently existing applications.  AT some point, as SOA becomes more strategic, MDM will get another fillip in the arm in terms of demand.  SOA runs the risk of being DOA without MDM (in complex environments).  You should see more research on the connection between MDM and SOA in 2009.

So I was writing my “book of the month” summary (I post them in my email footer) and in October I finished Edith Penrose’s, “The Theory of the Growth of the Firm”, originally published in 1959 and updated in 1995.  Despite being more of a text book, it was good fun to refresh my knowledge of the factors that dictate the absolute size and growth of a firm.  All too often I found myself reading the book and thinking about a firm I had worked with, or for, and realized that the theories described are very real and impact our day to day lives. 

But as I read the book I was struck by two things: First, I had an experience years ago, upon leaving a firm I had worked for (manufacturer) I then spend several months afterward consulting for them.  I found the experience flattering of course, but the idea that came to me was this: Why was it that my previous employer did not listen enough to me when I was employed by them, but since I was now outside the firm, they would pay more than they did previously to get access to the same knowledge?  I then generalized the experience with the notion of “company IQ”.  As we each join, and leave firms, the overall company IQ changes.  This explains why, over many years, firms have to re-learn the stuff they learnt before, and since lost.  It explains why we each get asked to consult wit hour previous employers. 

The second experience followed on from the first.  Given that MDM is a relative new attempt at solving an old problem (how to sustain ‘single view’ of key master data assets across the business for any and all purposes), how long will it take firms to adjust their overall company IQ in order to make MDM part of the natural and standard processes of the firms?  Will most firms be limited by the current small pool of users that really understand what MDM means to their business, and will early adopter implementations start to fall into disrepute during 2009 as practitioners get lured away by bigger and higher paying opportunities?  How do firms embed these new processes into their standard practices? 

My guess is that a proportion of currently active MDM programs will suffer in 2009 as organizational IQ will fall with the exit of highly sought after resources that really understand MDM.  The only way to prevent the organization IQ from falling (as it relates to MDM) is to highlight those individuals quickly and ensure that they have what they need in order to keep them on board.  MDM is a key initiative, so the need to keep the knowledgeable resources is very important too.

I sat down with a large business applications vendor that sells to retailers and manufactures yesterday, to get an update on their “multi-channel” strategy.  Multi-channel, or as we are increasingly calling it, “multicommerce”, represent the complexity in a firm that exists when that firm interacts with its customers (or partners) across multiple channels using different methods.  For retailers, this can include store, direct, web, catalog, and so on.  For many retailers these channels are not all natively developed businesses, but some are acquired over time by the absorption of a smaller, niche competitor.  It is very common in fact to find a retailer with all manner of complex business applications systems loosely integrated in an attempt to align data and processes across channels.  The fact is that much of this integration is traditional (unchanged in design or structure for the last 8+ years), weak, and now overly expensive to maintain.  The result is often experienced by you and me: we can purchase items from one channel and not return it via another; we can place an order via one channel and experience unrelated customer service on another.  

The briefing was very interesting and the focus was more on how this vendor was helping retailers with “multi-channel planning”; how to aggregated forecasts and planning information across multiple channels in one holistic process.  I asked of the vendor, what they do to help the retailer integrate the underlying transaction and master data across the different channels. 

The response was a very bland “same old thing” answer that talks about “integration the way we have been doing it for years”.  This particular vendor does not “get” MDM, or at least does not relate publicly the connection between this latest attempt to unify single view of master data (like product, customer, location, channel, price) and how it will significantly reduce the costs of integration associated with managing duplicate and redundant and inaccurate master data.  

This is a great shame, in my view.  The retailers themselves are not collectively thought of as visionaries when it comes to MDM – though I met two such rare visionaries at our recent MDM Summit.  With the majority of retailers not understanding what MDM should be to their business, and with vendors selling into retailers not really “getting it”, the result will be slow adoption and apathy: not a recipe for significant improvement in retail performance.

Have you seen some good examples of MDM being applied in retail?  Do you think your examples are isolated?  Do you agree retailers are taking too long, in general, to get to grips with their master data?