• Kristian Steenstrup published a note, The Value of Asset Intelligence for Utilities, where Kristian explores “single view” of asset data.  IT systems can provide the support utilities needed to improve the approach to asset management from inception, construction or acquisition, through to performance and investment decisions. This research provides a full explanation of the emerging components of a complete asset management view.  This “360 degree” view of asset aligns nicely with our idea of a master data lifecycle.  Master data (of all kinds) experiences a life cycle that is unique; this is not the same as Information Lifecycle Management, which looks at the physical storage requirements for all data as it moves through a usage pattern.  Asset master lifecycle is unique in that is spans design, construction (two MDM use cases), as well as operations, and analytics (the other two MDM use cases). Utilities are well versed in this lifecycle concept so are in a position to lever MDM quickly.
• Jeff Woods published a note, How to Evaluate Your Vendor’s ERP Strategy, where Jeff provides a comprehensive framework to help you evaluate your vendor’s ERP strategy.  Most enterprises will be tied to their ERP vendors for more than 10 years. Therefore, it pays to make a fully informed decision about those vendors, beyond just functional fit, before you implement or engage in an expansion of your ERP project. This is particularly complex since what is meant by “ERP” has changed over the years.  The original concept was a specific application sported a  “single data model/single process model”.  Over time as those vendors grew in size, and acquired applications and application suites, “ERP vendors” now offer more of a heterogeneous landscape.  SAP and Oracle, the two largest “ERP vendors”, still offer an ERP option from old, but that is far less useful to the majority of users, that now focus on an “ERP strategy” which is “source as much stuff from one vendor”.  Whatever your ERP strategy, this research is great for scoping out the ERP footprint.
• Lastly, Mark Beyer and I wrote a note, The Emerging Vision for Data Services: Master Data and Content Management for SOA.  This is a very important note, because we have not written that much on the relationship between MDM (and Content Management, for that matter) and SOA and this is changing.  This note represents a core piece of research that explains why MDM needs SOA.  There is more to come on why SOA needs MDM.  This note explores the increasing first hand experience users are reporting when they try to create integration between MDM hubs and application oriented data that also stores master data.  Mark and I will be exploring this in more detail at our upcoming MDM summit (see below).

I hope you find the research helpful.  Let us know if you don’t, and why.

Submit a customer case study to win the Gartner MDM Excellence Award 2009!  Go here: http://www.gartner.com/it/page.jsp?id=851612&tab=special&params=pg,zzz.html

Well what a day!  The week ended on a high for me, and by the looks of it, for the attendees of the conference.  Despite the lovely London sunshine a good number of folks remained in the hotel to chat about SOA and application development.

I had a couple of 1-1’s with clients, and also had the pleasure of speaking on MDM.  The 1-1’s were very interesting.  I had a few questions about specific vendors since clients are always concerned about vendor maturity and capability, so this remains a frequent topic.  Some other questions we explored included: 

• It seems pretty obvious that my firm has or should identify master data domains, such as product, customer, and organization, but what about “agreement” or “order”?
• Any clear, obvious MDM principles or best practices?
• You have talked about how business applications (and business intelligence) needs to evolve to support an “MDM awareness” – are there any examples yet in banking?

Order and Agreements: There constructs clearly include master data (an order is an aggregation of products and/or services, a client, and a data, along with other bits and bobs such as price, terms, rules etc.  But an order or agreement is just that – an aggregation.  There are many of them, and they operate like a transaction: actual specific transactions (a sale, a fulfillment, a settlement) are all logged against the order in some fashion.  The content of the order or agreement includes master data, but also other data.  Lastly, MDM implies a living governance infrastructure and process, so that again separates orders, agreements, and master data.  The lifecycle of orders, and agreements, needs its own kind of governance, but it would be different.  It is highly unlikely, and I could not think of a single instance, where a firm would want to govern “order” as if it were master data.

MDM Principles/best practices:  We have published several notes on best practices; some focused on specific domain oriented MDM (such as Top Ten Best Practices for MDM of Customer Data, and Top Ten Best Practices of MDM of Product Data) and also some other notes on what to do and what not to do when setting up your MDM initiative, or looking more broadly at other information management strategies.  A good source for what is out there is our periodic, “Roundup of Master Data Management and Related Research”, last updated Q4 2008.

“MDM Aware” Applications: this is a new area of research and one that is proving particularly interesting.  In talking with those users that were innovators or early adopters of MDM we are seeing that an increasing number of firms are implementing now the second, or third, MDM technology in support of their own MDM strategy.  As these processes and systems come on line, the ease (or difficulty) with which MDM systems interact with data stores (business application, packaged or developed applications, business intelligence data warehouses) becomes complicated.  Some firms have little ability to “open up” the legacy applications and interaction is very basic.  Other firms have some ability to “open up” part of the legacy infrastructure and so the dialog about how MDM works and interacts with these systems becomes more complex, and so interesting.

Of course, most applications do not “play well with others”.  Additionally we know that architecturally MDM is shifting a focus for data integration from “point to point” (many of them) to fewer “hub and spoke” models.  But if the legacy applications are not easily accessed, the degree to which an ideal MDM implementation style can be adopted becomes harder.  Some initial business applications vendors (i2 Technologies in SCM, Soft Solutions in retail) and a few others, are beginning to externalize their master data model such that “control” could be wrested from the business application to an external, 3^rd party system (ie MDM).  Though not a panacea, this does make interaction between MDM and the business application easier, if only the MDM applications were mature enough to monitor and control what goes into those externalized data stores…  Bottom line: if MDM as a discipline is to take hold and grow, many, many more business application oriented data stores have to be made “MDM aware” in order to simplify the information infrastructure.  If the master data models remain, as they are now, firmly hidden behind the application “firewall”, then integration between MDM and the rest of the application stack will be ‘traditional’ and as such, an opportunity for lower costs will be lost, and more importantly, a degree of agility for the IT stack will be lost also.  

My presentation, entitled, “Does SOA need MDM, or Does MDM need SOA?” seemed to go well.  I was lucky enough to attract a sizable audience (this was the only MDM session at the event) and we covered a high level overview of MDM, and then explored the various interplays between SOA, application development, and value of MDM.  The conclusion I tried to draw out was that:

• For MDM be effective, it (the technology enabling MDM) needs to be part of the services infrastructure that comprises the SOA strategy as this simplifies how the technology works across the business, and
• For SOA to be effective in more complicated environments, that is, heterogeneous “semantic bounded” data stores, MDM needs to be adopted before hand else the any composed application would have to incur the cost of coping with semantically inconsistent data every time it was executed. 

Based on the questions from the audience and the feedback during the afternoon, and at the closing session, MDM and SOA is a popular topic and the content seemed to strike a chord with many attendees.  Who knows, maybe I will be back next year…perhaps with a user panel to talk about the interaction between MDM and SOA…

Gartner’s SOA & Application Development and Integration Summit, London, UK

I sat in a vendor presentation today on SOA.  Specifically the presentation was focused on SAP and how SOA oriented was its technology stack.  I asked a question of the speaker that was not pointed to SAP, but to SOA in general, and the role of MDM was to SOA.  You see, I have an opinion that much of SOA’s promise wont be realized if the underlying data in the various data silos are not semantically consistent (ie governed by MDM).  

The answer I got stunned me: “MDM, for me, [he said] is really just a set of services that will be governed in a SOA framework”.  I was stunned since MDM is not really that at all.  MDM is a discipline that seeks to simplify the integration landscape by assuring semantic consistency across data stores.  So if a service “get customer” is orchestrated to work with a service designed and even delivered by a different source, “charge customer”, the actual definition of “customer” is the same (the easiest part) and ultimately, the actual instance/observation of each customer instantiated across the two data stores (order file, accounts receivable file) when the services are executed, are consistent.

After I got over my stunned response, I realized that the speaker may or may not agree with this, but I realized that he really over simplified the implementation of MDM.  Of course, MDM will be implemented as a series of services, but this was really only half, or maybe 10% of the story.  It maybe that the speaker realizes that there is much more to MDM than that, but I will give him the benefit of the doubt. He wanted to respond from the perspective of the execution of the MDM technology.

I had a couple of 1-1’s where I talked about our vision for the multienterprise business process platform (ME-BPP).  The vision is something we (myself, Benoit Lheureux, and Debbie Wilson coined) have been talking about for some time; that, over time, the center of gravity of many business processes, is moving outside the firewall for many firms.  This is consistent with the hype in the past with SaaS and now with Cloud computing.  Each is another wave of enthusiasm for accessing things from outside the firewall.  A ME-BPP is a governance infrastructure where a community (think supply chain, value chain, industry or some other community of interest) shares in the organizing, governance, and use of a set of data integration, business services, and business applications, to help support multienterprise business processes.  The ME-BPP represents a long, slow burn that will lead to large swathes of consolidation in the B2B industry.  Some vendors like e2open, Sterling Commerce, and wesupply, look and smell like emerging ME-BPP’s.  But ME-BPP’s are not technology that firms buy; it is an alignment of technology that describes how they are used.  Technology plays a key role nonetheless.

More to follow…

Interesting also- the writer (Greg Todd) focuses on analytics at Accenture.  Analytics, technologies to help guide and improve effective decision making (thus improving business performance), are as much dependent on data quality in general, and increasingly recognized by users, master data.

While perusing this article, I came up with another: Simplifying IT with Master Data Management and SOA.  Fascinating article, which seems to read nicely inline (mostly) with your view of SOA and MDM.  The hype around MDM remains very high, and it seems the connection between MDM and SOA continues to increase also.  This is key – for MDM as it is for SOA, though business users are still, for the most part, not this far along or even aware….  We all have much more work to do.

I myself have written on this topic really as a reaction to the limited number of client interactions that highlight the connection.  The surprising thing is a) so few clients really make the connection, and b) once a connection is made, it is very obvious, clear and strong, and leads to a very different understanding of MDM and how it can provide value to the business.  

Dan’s note is not about MDM and SOA; but how to get a SOA initiative underway.  And in that dialog he highlights how MDM has a symbiotic relationship with MDM.  I will be presenting on the topic in London in June at Gartner’s SOA & Application Development and Integration Summit.  The presentation brings together a lot of research and weaves the pieces together…hopefully it is of value to you.  Hope to see you there!

The analysis is very interesting (I encourage you to get!).  Overall it seems that there is a lot of interest with SOA.  Without giving the game away it would seem that much interest in SOA is very tactical (i.e. integrating legacy applications) rather than strategic (building a design platform for repeated re-use of application assets over time).  Worse, and this is for a different thread, tactical uses of SOA do not necessarily ensure that a strategic foundation is established anyway.  

But, the research did show up a gap: retailers are focused on a range of uses for SOA, but these uses to not align well with the business process/application focus areas.  One hot area where SOA is apparently being applied is multi-channel integration. This is one of those last bastions of integration complexity in retail.  Most retailers have a range of different systems acquired or developed over the years to service one particular channel – not unlike their manufacturing/supplier brethren who have basically the same mess (so this is not retail, or industry specific).  As such there is a ton if spaghetti integration (point-to-point) across channels to integrate product, data, order, customer, and price data.  So SOA looks like a natural place to simplify this mess, right?  Yes, and no.  

SOA will help – from the perspective of replacing one set of pipes for another set of pipes that have more in common (and so can be interchangeable) but the underlying data is messed up!  Unless the semantic model is simplified, thus ensuring the data semantics in the different systems mean the same thing, then a better integration mousetrap will fail to provide the benefits expected.  One set of pipes will be replaced with another set of pipes but the stuff flowing through the pipes will remain messy.  This is the “SOA needs MDM” argument.  

In my travels when talking with retailers, I do not see the same level of effort going into MDM as I see going into SOA.  It could be that retailers assume that with tactical SOA, MDM would be overkill.  This is a big mistake, in my view.  MDM is not overkill – users do it today; we all do it today and that’s the problem.  We each manage our own semantic part of the world and do not take the time to relate to others enough.  Adopting MDM should not be a significant cost; it should be approached slowly and in stages – just like SOA.

I have only looked at the vendor’s SCM, analytics, and MDM technologies.  In the SCM market the vendor sports some pretty good, even best of breed, capability, that heralds back to the companies founding.  Agilisys was formed out of the spin-off of the SCP engine that was part of SCT Adage, a process ERP/manufacturing vendor.  Agilisys, originally a niche SCP vendor, became Infor.  Later acquisitions have led to the consumption of a discrete best of breed SCP engine also, originally known as Mercia Software (a vendor I had interviewed with way back in time, though I turned them down in order to move to the US).  Other acquisitions have led to some other interesting offerings, though some not neatly aligned to the two SCP offerings already mentioned.  Thru-Put Technologies was an old “drum, buffer, rope” engine (think The Goal) designed to optimize discrete product scheduling, that had been acquired by MAPICS, that was itself acquired by SSA.  So Infor now owns that IP but alas it remains focused in-plant, and not yet applied to distribution. 

Analytics, or more precisely, Performance Management (that is, the embedding of analytics and business intelligence capability inside the business process) and MDM remain challenges.  Admittedly these would be challenges for any vendor that has acquired so many different applications each with their own architecture.  Infor has an interesting approach to supporting analytics (see the note above) but certainly has changed, for the better, its views on MDM.  When I started talking to Infor about MDM (June 2005) MDM was a lower priority, even following the foundation of a SOA strategy.  Back then I said that this approach looked odd; how could an architect settle on an SOA strategy that promised cross department/application integration and composition, without some notion of an end-to-end (interoperable data model?  Not 12 months later, MDM had moved up the priority list at Infor, and even now, is a much higher priority for the vendor.  This is no criticism of the vendor; this question comes up many, many times in end user conversations.  Infor was, and is, reflective of how our mutual customers view this technology.  Thankfully Infor is now more able to participate in the conversation with its users about how it can help in this area.

Bottom Line: MDM, as part of a methodical and broad EIM strategy, should precede and/or be part of, any broad SOA strategy.  See When SOA Breaks, What Then? and SCM Vendors Support Master Data Management as a Precursor to SOA.

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.

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.