Spending time at the MDM/DG Summit in NYC this week demonstrated the wide spectrum of MDM implementations and stories out in the market. It certainly coincides with our upcoming MDM inquriry analysis where:
Clients now have a report that helps them make more informed choices about selecting a PIM solutions. PIM is not always a well understood master data solution option for Enterprise Architects. Questions arise about, do I need PIM or MDM or do both? Aren't PIM and Product MDM the same? How does this fit in my architecture? This report takes away the confusion, answers these questions. It gives insight into how vendors satisfy PIM demands, differentiate from MDM and operate in hybrid scenarios.
The first Forrester Wave collaboration across the Business Technology and Marketing and Strategy groups. In the age of the customer, tighter collaboration between business decision makers and technology management professionals is critical. This wave addresses both perspectives providing the business requirements for marketing and product professionals while also addressing the technical questions that are important when selecting tools. Yes, business and technology management can work together, be on the same page, and produce great results!
If you have implemented or used either application wrapping or containerization technologies, please COMPLETE THIS SURVEY.
Application wrapping versus containerization: Which technology provides better security to an enterprise mobile deployment? What are the use cases for each technology, and which technology has a longer shelf life when it comes to being the de facto standard for enterprise mobile security? Are there times when containerization provides a better user experience than application wrapping? And more simply speaking . . . what the heck is the difference between these two technologies, and which one should you purchase?
In the sport of boxing, "the tale of the tape" is a term used to describe a comparison between two fighters. Typically, this comparison includes physical measurements of each fighter as taken by a tape measure before the bout, thus the term "the tale of the tape." I'm currently conducting research for a "tale of the tape" report between mobile containerization technologies and mobile application wrapping. There has been a significant amount of discussion lately regarding which of these technologies is better suited for enterprise deployment. In order to settle this dispute, I'm going to get out the virtual tape measure and analyze the fighters!
VMware recently announced that it has signed a definitive agreement to acquire AirWatch, a leading provider of enterprise mobile management and security solutions. The acquisition is expected to provide customers with the most complete solution to manage users, devices, and applications across server, desktop, and mobile environments.
VMware obviously has had to expand its penetration beyond the server-centric virtualization market. So far, it has had mixed success with selling virtualization as a platform in the region, even though it has successfully entrenched itself as a leading hypervisor provider (unfortunately, VDI has proved a difficult sell for VMware in AP). In order to gain much deeper penetration and traction, VMware needed to add an end user computing offering to its portfolio. The pairing should result in:
On January 22, 2014, a new mobile security player was born. This is the date that VMware announced its intention to purchase the mobile device management (MDM) firm AirWatch. With a price tag of $1.5 billion, this acquisition confirms that the mobile security market is scorchingly hot. This news comes on the heels of the November acquisition of Fiberlink by IBM. I expect additional mobile security market consolidation to occur throughout the remainder of 2014. This acquisition is a shot across the bow of any other major vendor looking to play in the mobile security market. If you don't step up and spend now, you might just be left holding the bag.
Big data gurus have said that data quality isn’t important for big data. Good enough is good enough. However, business stakeholders still complain about poor data quality. In fact, when Forrester surveyed customer intelligence professionals, the ability to integrate data and manage data quality are the top two factors holding customer intelligence back.
So, do big data gurus have it wrong? Sort of . . .
I had the chance to attend and present at a marketing event put on by MITX last week in Boston that focused on data science for marketing and customer experience. I recommend all data and big data professionals do this. Here is why. How marketers and agencies talk about big data and data science is different than how IT talks about it. This isn’t just a language barrier, it’s a philosophy barrier. Let’s look at this closer:
Data is totals. When IT talks about data, it’s talking of the physical elements stored in systems. When marketing talks about data, it’s referring to the totals and calculation outputs from analysis.
Quality is completeness. At the MITX event, Panera Bread was asked, how do they understand customers that pay cash? This lack of data didn’t hinder analysis. Panera looked at customers in their loyalty program and promotions that paid cash to make assumptions about this segment and their behavior. Analytics was the data quality tool that completed the customer picture.
Data rules are algorithms. When rules are applied to data, these are more aligned to segmentation and status that would be input into personalized customer interaction. Data rules are not about transformation to marketers.
It is easy to get caught up in the source and target paradigm when implementing master data management. The logical model looms large to identify where master data resides for linkage and makes the project -- well -- logical.
If this is the first step in your customer MDM endeavor and creating a master data definition based on identifying relevant data elements, STOP!
The first step is to articulate the story that customer MDM will support. This is the customer MDM blueprint.
For example, if the driving business strategy is to create a winning customer experience, customer MDM puts the customer definition at the center of what the customer experience looks like. The customer experience is the story. You need to understand and have data points for elements such as preferences, sentiment, lifestyle, and friends/relationships. These elements may be available within your CRM system, in social networks, with partners, and third-party data providers. The elements may be discrete or derived from analytics. If you only look for name, address, phone, and email, there is nothing about this definition that helps determine how you place that contact into context of engagement.
Ultimately, isn’t that what the business is asking for when they want the promised 360-degree view of the customer? Demands for complete, relevant, and timely are not grounded in the databases, data dictionaries, and integration/transformation processes of your warehouses and applications; they are grounded in the story.
So, don’t start with the data. Start with the story you want to tell.
There is a shift underway with master data management (MDM) that can't be ignored. It is no longer good enough to master domains in a silo and think of MDM as an integration tool. First-generation implementations have provided success to companies seeking to manage duplication, establishing a master definition, and consolidating data into a data warehouse. All good things. However, as organizations embrace federated environments and put big data architectures into wider use, these built-for-purpose MDM implementations are too narrowly focused and at times as rigid as the traditional data management platforms they support.
Yet, it doesn't have to be that way. By nature, MDM is meant to provide flexibility and elasticity to managing both single and multiple master domains. First, MDM has to be redefined from a data integration tool to a data modeling tool. Then, MDM is better aligned to business patterns and information needs, as it is designed by business context.
Enter The Golden Profile
When the business wants to put master data to use it is about how to have a view of a domain. The business doesn't think in terms of records, it thinks about using the data to improve customer relationships, grow the business, improve processes, or any host of other business tasks and objectives. A golden profile fits this need by providing the definition and framework that flexes to deliver master data based on context. It can do so because it is driven by data relationships.
I recently had a client ask about MDM measurement for their customer master. In many cases, the discussions I have about measurement is how to show that MDM has "solved world hunger" for the organization. In fact, a lot of the research and content out there focused on just that. Great to create a business case for investment. Not so good in helping with the daily management of master data and data governance. This client question is more practical, touching upon:
what about the data do you measure?
how do you calculate?
how frequently do you report and show trends?
how do you link the calculation to something the business understands?
I just came back from a Product Information Management (PIM) event this week had had a lot of discussions about how to evaluate vendors and their solutions. I also get a lot of inquiries on vendor selection and while a lot of the questions center around the functionality itself, how to evaluate is also a key point of discussion. What peaked my interest on this subject is that IT and the Business have very different objectives in selecting a solution for MDM, PIM, and data quality. In fact, it can often get contentious when IT and the Business don't agree on the best solution.
General steps to purchase a solution seem pretty consistent: create a short list based on the Forrester Wave and research, conduct an RFI, narrow down to 2-3 vendors for an RFP, make a decision. But, the devil seems to be in the details.
Is a proof of concept required?
How do you make a decision when vendors solutions appear the same? Are they really the same?
How do you put pricing into context? Is lowest really better?
What is required to know before engaging with vendors to identify fit and differentiation?
When does meeting business objectives win out over fit in IT skills and platform consistency?