Software AG buys Data Foundations: Business Acumen Meets Data Competency

Co-authored with Forrester's Rob Karel.

On September 18, 2010, Software AG (SAG) — best known for its business process management, B2B, and SOA-based integration solutions — announced its acquisition of Data Foundations, a master data management (MDM) vendor based in Hackensack, New Jersey. Data Foundations is smaller and less well known than the more mature and comprehensive MDM solutions from Initiate Systems and Siperian, both of which were acquired earlier this year by IBM and Informatica, respectively. Once Initiate and Siperian were taken off the market, no tier one MDM vendors remained for potential suitors to consider — especially those that could support both analytical and operational use cases. Having missed out on the opportunity to snag one of those leaders, we believe Software AG made the right technology choice in selecting Data Foundations. 

Who is Data Foundations?

Data Foundations was founded in 1998 as a data management services consultancy, but it moved into MDM software in 2002 with the first release of its OneData platform. Most of Data Foundations’ experience to date has been in the analytical MDM (or as we like to call it, “governance-driven MDM”) market that focuses primarily on delivering version-controlled views of master data across various data domains used often in data warehousing, BI, or analytic environments and included strong workflow, stewardship, and security controls. Data Foundations’ competition primarily included Kalido, Orchestra Networks, and Oracle DRM. More recently, Data Foundations says that the newest version of OneData can now compete in the operational MDM market supporting CDI and multidomain MDM use cases dominated today by IBM, Informatica/Siperian, and Oracle. Since that version is new to the market, it’s too early to tell how it stacks up against the rest.

 Why is Software AG entering the MDM market?

It’s no longer too scandalous or surprising to admit that technology- or IT-centric MDM strategies just don’t work. Building a single version of truth of master data in a central hub somewhere doesn’t directly solve any business problems. The only way master data can reduce risks, improve operational efficiencies, reduce costs, increase revenue, or strategically differentiate an organization is by figuring out how to connect and synchronize that master data into the business processes and decisions most important to an organization’s success. 

With this acquisition, Software AG acknowledges that the customers of its integration and business-process-centric solutions have a strong dependency on high-quality data. This move reflects a trend that we have identified and coined as “process data management,” which recognizes the clear need for business process management (BPM) and MDM strategies to be much more closely aligned for both to succeed. The synergies between BPM and MDM are incredibly strong, and SAG is gambling that its differentiated “Process-Driven Master Data Management” message will both intrigue its existing BPM clients as well as differentiate it from the other MDM vendors. Software AG, especially with its 2009 acquisition of IDS Scheer, is now closely aligned with the business leaders that own these mission-critical processes, which is a relationship that evades many other MDM vendors who are still selling primarily to IT.

In our first report on process data management, we highlighted the inherent risks faced by both MDM and BPM teams when process improvement and data quality are disconnected. Our research uncovered that BPM teams face a vicious cycle of “process data failure” if they don’t invest time to uncover how processes leverage master data from the outset. And on the flip side, MDM teams must continuously prove their value to the organization when data quality is not connected to business context. With Data Foundations, Software AG plans to bridge this gap by connecting process discovery and execution with data governance and data quality.

This doesn’t mean that Software AG is immediately relevant in the MDM market. It has a lot of work to do to integrate the less-known and less- experienced Data Foundations technology platform into its broader portfolio, and it will have to continue to consider what functional gaps may still remain to truly compete with much more mature solutions on the market. Software AG would do well to focus on its process-driven MDM message and hope to get some early wins from its existing BPM-centric install base to prove it can play ball with the more experienced MDM providers. Unlike its acquisition of itCampus, Software AG will need to provide a clear road map to customers on how the Data Foundations acquisition will directly benefit stakeholders and accelerate time-to-value across BPM and MDM initiatives.

Will this trigger more movement in the BPM and MDM markets?

MDM and BPM cannot live independently, and vendors providing solutions into either or both of these competencies need to address this relationship sooner rather than later. Even MDM leaders like IBM and Oracle that also offer business process management software within their product portfolios are doing very little to actually integrate and align these capabilities. TIBCO is probably the most comparable competitor to Software AG from a product portfolio and alignment standpoint, but TIBCO’s MDM solution has not made a significant dent in the MDM market, most likely due to its continued focus on IT and technology issues as opposed to evangelizing MDM to a business audience. This is Software AG’s opportunity to differentiate, while the other BPM and MDM vendors scramble to catch up. 

Data Foundations had an existing OEM partnership with Netrics for data matching, but with TIBCO’s acquisition of Netrics earlier this year, SAG will instead focus more on its relationship with Harte-Hanks Trillium Software ongoing to provide data quality and matching capabilities to support MDM. Of course, on the same day that SAG announced its acquisition of Data Foundations, TIBCO announced its agreement to launch a joint MDM and data quality platform with Trillium Software, which dilutes the differentiation that SAG could have had with Trillium as a partner. We expect to see other MDM vendors, most notably Oracle, continue to partner with Trillium as well to deliver best-of-breed data quality capabilities. We’ve blogged this recommendation often to Oracle and will provide the same advice to Software AG and TIBCO: Bring data quality and matching capabilities in-house to support your MDM strategies. It’s too important a component of MDM to rely solely on a third-party partner.

Additionally, we expect Software AG’s move will spur other BPM suite players to move beyond “data services” as the catch-all solution for addressing master data issues encountered on BPM initiatives. While leading vendors, such as Appian and Pega, understand the challenges of connecting master data to process improvement, very few support business-oriented data modeling as a key component of process modeling. Our recently published “Forrester Wave ™: Business Process Management Suites, Q3 2010” report highlighted IBM as the only BPM suite vendor to offer a full-featured business glossary as part of their BPM suite — but even then, the business glossary was not connected with IBM’s InfoSphere Business Glossary targeting data stewards and data management professionals. By connecting ARIS’s business-oriented process and data modeling features to the Data Foundations environment, Software AG would become one of the first BPM suite vendors to provide a seamless environment for modeling and managing data across different roles and perspectives that contribute to both MDM and BPM.


Further convergence of business process management and data management solutions may see some of the following changes over the coming years:

  • Bridging of business glossaries created within BPM suites and business glossaries/data dictionaries created by data management and metadata management platforms.
  • Combining data modeling and process modeling best practices and technologies with the deliverable of a true enterprise process data model as a result.
  • Increased focus to align data governance and process governance initiatives across organizations.


Processes, Data and ...?

Dear Clay,
I think your predictions are crucial for both the data and process management fields. I would actually read them more as a recommendation to potential adopters than a mere prediction. I think that the evolutions you mention in the vendor market are only external signals of a deep need that has been latent for (too) long.

I strongly believe that business process models "per se" are not enough for representing the complexity of real world enterprises and therefore also of software applications devoted to implement the enterprise processes.
I think that other design dimensions should be taken into account in the analysis, design, and implementation of such applications.
Besides business processes, data is definitely one of these dimensions, and probably the most important one. In the approach we have been devising for some years, we studied some further aspects:
- application structure
- user navigation
- visual identity
As a research team, we have tried for a long time to find a way to combine all these aspects together in a sensible way. We ended up with Model Driven Development (MDD): different orthogonal models represent the various aspects of the applications and a set of mappings and transformation rules allow a seamless integration of all of them (plus a set of nice-to-have features, such as quick prototyping, integrated documentation, automatic alignment of models and implementation, and so on).

I would be glad to get feedback on this. Do you think it makes sense to consider further aspects wrt data and processes? Might MDD be an interesting option for integrating them?

Hi Marco, Right now the real

Hi Marco,

Right now the real challenge is to these two worlds - MDM and BPM - together at the business-level, initiative-level. These are often two large-scale initiatives that live in silos and we know teams often try to address this at the application-level, but that's too late in the process.

While I think MDD is a great approach at the design/architecture level, it really doesn't address the real problem: How do you get the process professionals thinking about and taking ownership for maintaining data quality, and how do you get data professionals to take process into account for maintaining the quality of master data?

The MDM/BPM disconnect is less of a technical design/architecture issue and more of an alignment/synchronization issue. Most of the teams we've interviewed have tried to solve this problem at the technical level have had limited success - basically they're using technical and development resources to triage data quality issues that creep up as a result of process improvement projects.

Alternatively, we've seen really good examples from successful teams. These teams have moved beyond trying to address MDM/BPM at a technical level and focus on governance to synchronize roles and activities across both initiatives.


MDD as methodology to approach problems

Dear Clay,
thanks for your response. In my post I was mentioning MDD more as a methodology than a technical framework (although it it is more often intended in the latter sense). This means to think about reality purely in terms of models, and relations (or mappings, or transformations) among them.

In this sense, MDD could contribute in MDM and BPM alignment.
Indeed, I fully agree with you that the real challenge is on alignment and synchronization. I think that MDD can help also on this, to some extent, thanks to the its "models and relations" paradigm.
I bring this in as an integrated design alternative to the siloed worlds you mention. Obviously this is not always possible, but it's definitely the one I would embrace when starting new projects (if instead you already have the siloes as a starting point, a longer discussion is needed on how and if MDD can be applied).

And then, I was trying to push the things a little bit further by saying that besides models for MDM and BPM, one could think to other aspects of the real world to address, and generalize the approach.
Maybe a grand vision, not for tomorrow, but something worth imagining.

We actually had some successful experiences on this, both at research and large-scale industrial level, by working on projects that integrated BP models, complex Data management models, user and role models, and user interaction models. Some slides about this are online on Slideshare ( and we are going to publish the experience in the upcoming book edited by Michael Rosemann and Michael zur Muehlen following up the industrial session of the BPM 2010 conference in Hoboken, NJ. I'll keep you posted on this if you want.

Sorry to contradict you on BPM and MDM integration

Clay, it was great to connect with you in person in Washington. Social media networking only gets us so far ...

Thank you for pointing out the absolute necessity of linking MDM and BPM. But why end it at BPM? How about ECM and CRM? MDM is further not just about defining business terminology, but about taking the MDM definition right into deployment, meaning that the MDD Model Driven Development of the previous comment must be expanded to Model-Preserving Execution. From the data and process model straight into production through an embedded project and deployment capability!

So where do I see the contradiction? I don't see that independent MDM products such as employed by TIBCO, Oracle, IBM and others will get you very far, except if the products that execute are completely rebuilt. While it is cute for the developer to have access to a MDM during development, what happens when someone changes anything in the MDM? How are changes highlighted and all the products that use it notified and changed when they use compiled code? So a 'front-end-only' MDM is only part of the story.

While you consider Appian and Pegasystems as leading vendors because of your US focused perspective, we at ISIS Papyrus have taken that ultimate step of putting a Business Ontology Repository onto the front-end of our application platform already in 1997 and delivered the first large applications in the US in 2001. ISIS Papyrus is the only true MDM and BPM consolidated platform.

In the Papyrus Platform any change made to the data definitions in the repository will translate to changes in all parts of the applications for CRM, CRM, BPM and SOA interfaces as soon as they are tested and deployed. We actually execute the models!

So all these large well established vendors are ten years behind what we have been doing and we still have not been able to break through the wall with analysts understanding that power. We proposed the combination of ECM inbound and outbound documents with BPM in 2001 and only now it sort of gets understood as EMC and IBM buy a similar product stack. We proposed the merging of CRM and BPM in 2005 and now it is big news with Pega acquiring Chordiant.

In all these areas of MDM, CRM, BPM, and ECM analysts have been blind to look outside the market fragments they cover and got stuck in the rut of best-of-breed feature chasing.

It is well known, that simply taking the best possible components does not produce a working system (i.e. an airplane) but that these have to be designed to work together from the outset. So all the acquisitions and merging of products will NOT PRODUCE the best systems. These vendors are also held back by the needs of the customers that they acquired with the products, further slowing consolidation.

I know that company size and market share are the most relevant in shaping analyst opinions. Understood. But what does it take to finally open the eyes of analysts to a fully consolidated solution like the ISIS Papyrus Platform that exists since ten years and builds on your 23 years reputation in ECM. Any suggestions?

Regards, Max J. Pucher - Chief Architect ISIS Papyrus

Hi Max, Thanks for the

Hi Max,

Thanks for the feedback. I also enjoyed catching up with you during our BP Forum event and look forward to our upcoming briefing on the ISIS Papyrus platform.

I don't believe you're contradicting the basic thesis that Rob and I have established for connecting BPM/MDM. In fact, I think you're reinforcing our thesis that it is critical that these two disciplines come together.

I point to your statement: "MDM is further not just about defining business terminology, but about taking the MDM definition right into deployment, meaning that the MDD Model Driven Development of the previous comment must be expanded to Model-Preserving Execution. From the data and process model straight into production through an embedded project and deployment capability!"

I read your statement as MDM is so intimately linked with process that it can't just be dealt with at pre-defined intervals (e.g., upfront modeling); MDM (i.e., data quality) must be addressed at all phases of a process. This includes addressing addressing data quality during process development and execution.

This is the same framework that Rob and I are proposing. But the most important piece is putting some level of governance around the two initiatives to synchronize efforts and key roles.

If you get a chance, take a look at our first process data management report: "Warning: Don't Assume Your Business Processes Use Master Data" (


The issue of integration.

Hi Clay, thanks for the feedback. I have read your previous research when it came out and its the reason why I want to brief you on what we do about MDM in our platform.

My contradiction is not about the principle of merging MDM and BPM, on which we are in absolute agreement. I am simply cautioning that the software integration of two disparate products is not easy and even if you manage to do it, MDM has still to be linked to the target execution environment.

So it is more a pragmatic reality check of what Software AG might be able to do with the MDM capability soon.

Thanks and talk to you soon, Max