Security and privacy have always been at the core of data governance. Typically, company policies, processes, and procedures have been designed to comply with these regulations to avoid fines and in some cases jail time. Very internally focused. However, companies now operate in a more external and connected fashion then ever before.
Let's consider this. Two stories in the news have recently exposed an aspect of data governance that muddies the water on our definition of data ownership and responsibility. After the tragedy at Sandy Hook Elementary School, the Journal News combined gun owner data with a map and released it to the public causing speculation and outcry that it provided criminals information to get the guns and put owners at risk. A more recent posting of a similar nature, an MIT graduate student creates an interactive map that lets you find individuals across the US and Canada to help people feel a part of something bigger. My first reaction was to think this was a better stalker tool than social media.
Why is this game changing for data governance and why should you care? It begs us to ask, even if a regulation is not hanging over our head, what is the ethical use of data and what is the responsibility of businesses to use this data?
Technology is moving faster than policy and laws can be created to keep up with this change. The owners of data more often than not will sit outside your corporate walls. Data governance has to take into account not only the interests of the company, but also the interests of the data owners. Data stewards have to be the trusted custodians of the data. Companies have to consider policies that not only benefit the corporate welfare but also the interests of customer and partners or face reputational risk and potential loss of business.
In a month or so I’ll be launching a survey to research issues around information strategy, information architecture and information management in general. I thought it might be useful to do a bit of crowdsourcing to get the best ideas for what questions to ask and make sure I’m covering your top-of-mind issues. We ask you all fairly often to provide answers to survey questions – maybe you’d like to provide input into the questions this time out?
Surveys are interesting – one is tempted to ask about everything imaginable to get good research data. But long onerous surveys produce very low percentages of completes vs. starts -- it’s classic case of less is more. Twenty completes for a very comprehensive survey is nowhere near as valuable as a couple hundred completes of a more limited survey. For example, I really wanted to provide an exhaustive list of tasks related to information management or information architecture practices and then provide an equally exhaustive list of organizational roles to get data on who does what in the typical organization and what are the patterns regarding roles and grouping of responsibilities. But the resulting question would have been torture for a respondent to go through, so I edited it down to the 15-ish responsibilities and roles you’ll see below, and I’ll probably have to reduce the number of roles further to make the question viable.
So, below are the questions I’m thinking of asking. Please use the comment area to suggest questions. I can’t promise to use them all but I can promise to consider them all and publish some of the more interesting results in this blog when they come in.
Data management is becoming critical as organizations seek to better understand and target their customers, drive out inefficiency, and satisfy government regulations. Despite this, the maturity of data management practices at companies in China is generally poor.
I had an enlightening conversation with my colleague, senior analyst Michele Goetz, who covers all aspects of data management. She told me that in North America and Europe, data management maturity varies widely from company to company; only about 5% have mature practices and a robust data management infrastructure. Most organizations are still struggling to be agile and lack measurement, even if they already have data management platforms in place. Very few of them align adequately with their specific business or information strategy and organizational structure.
If we look at data management maturity in China, I suspect the results are even worse: that fewer than 1% of the companies are mature in terms of integrated strategy, agile execution and continuous performance measurement. Specifically:
The practice of data management is still in the early stages. Data management is not only about simply deploying technology like data warehousing or related middleware, but also means putting in place the strategy and architectural practice, including contextual services and metadata pattern modeling, to align with business focus. The current focus of Chinese enterprises for data management is mostly around data warehousing, master data management, and basic support for both end-to-end business processes and composite applications for top management decision-making. It’s still far from leveraging the valuable data in business processes and business analytics.
The number one question I get from clients regarding their data strategy and data governance is, “How do I create a business case?”
This question is the kiss of death and here is why.
You created an IT strategy that has placed emphasis on helping to optimize IT data management efforts, lower total cost of ownership and reduce cost, and focused on technical requirements to develop the platform. There may be a nod toward helping the business by highlighting the improvement in data quality, consistency, and management of access and security in broad vague terms. The data strategy ended up looking more like an IT plan to execute data management.
This leaves the business asking, “So what? What is in it for me?”
Rethink your approach and think like the business:
· Change your data strategy to a business strategy. Recognize the strategy, objectives, and capabilities the business is looking for related to key initiatives. Your strategy should create a vision for how data will make these business needs a reality.
· Stop searching for the business case. The business case should already exist based on project requests at a line of business and executive level. Use the input to identify a strategy and solution that supports these requests.
· Avoid “shiny object syndrome”. As you keep up with emerging technology and trends, keep these new solutions and tools in context. There are more data integration, database, data governance, and storage options than ever before and one size does not fit all. Leverage your research to identify the right technology for business capabilities.
Lately, I have become a bit obsessed with evaluating the linkage between good process design and good experience design. This obsession was initially sparked by primary research I led earlier this year around reinventing andredesigning business processes for mobile. The mobile imperative is driving a laser focus for companies to create exceptional user experiences for their customers, employees, and partners. But this laser focus on exceptional design is not only reshaping the application development world. This drive for exceptional user experience is also radically changing the way companies approach business process design.
Over the past six months, I have run across more and more BPM teams where user experience is playing a much larger role in driving business process change. Some of these teams highlighted that they see experience design playing a greater role in driving process change than the actual process modeling and analysis aspects of process improvement.
Insufficient flexibility for business customization, poor ease of use, and long implementation have become major complaints about SAP’s core products by many SAP clients in China. Despite SAP’s wide adoption by large enterprises in China, including Nongfu Spring (the first one in APAC using HANA — in-memory computing platform — in production) and Sinopec (ranked No. 5 in Fortune 500 in 2012), these client issues are problems for SAP for its continued expansion into the China market. SAP uses its SAP Labs network across the globe to deliver local market-oriented solutions for different geographies. In my recent visit to SAP Labs China, one of the four hub labs that drive corporate product strategy and execution of global projects, I found that SAP is taking the right steps to integrate local requirements and deliver product capabilities that address the above issues:
Solutions customized for China regulations and business practices. SAP Labs China developed not only localized solutions for general purpose such as Golden Tax features, which is mandated by the Chinese government for its interfacing national taxing system, but also key solutions for local industries such as business real estate, international commerce, public finance, and healthcare.
More ease of use. To solve the ease-of-use problem, including the user interface look and feel and usage behavior of the product, SAP Labs China reinvented finance user experience and business processes for Chinese customers, and it also optimized the user interface for its human resource module.
The use of road maps to illustrate technology plans is fairly widespread. Whether it's a vendor explaining its product plans or a technology architect showing the evolution of a particular area of the infrastructure, road maps are great for communicating what happens when. And when plans as illustrated by the road map get sign-off, they can become a useful tool in change management as well. Someone wants your key resources for a special project? Fine, but all the dates on that road map they just approved just shifted six months to the right. Road maps tell the story of what to expect an organization to accomplish for the foreseeable future, and that's what makes them powerful.
That's why road maps that link traditionally difficult-to-explain areas of technology, such as those related to information management, to specific and highly desirable business outcomes can be a major win for architects looking to communicate what they're doing and why. There's always been a Catch-22 about explaining the value of complex technologies to audiences with no appetite for technical complexity -- but with needed sign-off authority for key resources (like funding). If the EA team has credibility (OK, that can be a big "if"), just showing the interrelationships between business outcomes, business capabilities, IT projects, and required activities in the various EA domains can satisfy the need for "explaining" that complex technology. Or for explaining the need for that not-well-understood architecture process that requires business involvement, such as information architecture development or governance.
I just finished analyzing our Q3 2012 Global State Of Enterprise Architecture Online Survey, where we asked a number of questions at the end of the survey on how firms identify and introduce new technology – new technology that your firm is counting on for innovation and competitive advantage. The results underscore a conviction that is growing in me: IT’s “one-size-fits-all” approach to standardizing everything and general aversion to risk isn't cutting the mustard. Simply put, opportunities for competitive advantage through technology-fueled disruption get missed, and this means digital extinction. Some data from our survey of 207 enterprise architects:
58% reported that sales and marketing is among the top five most likely organizations to deliver technology innovations, and they are chasing windows of opportunity that close in months. IT typically takes at least a year to do anything.
52% say there is at least some business dissatisfaction with the level of new technology introduction. The top reason, given by 78% of respondents, is that IT is too slow.
70% of respondents admit their firms have trouble reacting to disruptions caused by emerging technology, and 60% admit to difficulty reacting to change in general.
Over the last few months I have met or spoken to a significant number of Forrester clients who are undertaking a business architecture initiative. As you can imagine, these initiatives have various sponsors and are at various levels of maturity. Some business architecture (BA) initiatives are being driven by chief information officers (CIOs) and chief technology officers (CTOs) wanting to get a seat, and become an influencer, at the strategic decision-making table. Whilst others are being driven by business executives, who either believe business design and transformation is a business responsibility or that IT has insufficient business competency to understand and deliver what is required.
The different levels of maturity struck me, as just like the English Premier League (that’s where real football is played, for those not in the know) there are the elite (the big boys – top five or six teams) and there are the also-rans/others. There are also the elite BA teams and the non-elite BA teams. The gap between these two groups is growing, which will be a nightmare for a non-elite BA leader benchmarking his initiative against other organizations. Where one could argue in the football reference it is money that divides the two groups, as this attracts better players and creates better teams, with BA teams it appears to be more based on focus. Less mature and non-elite BA teams focus their efforts primarily on the building of BA, reacting to siloed demand and then selling or pushing BA artifacts to stakeholders in the hope that they find these artifacts useful. Whereas, the elite BA teams focus on addressing stakeholder needs and the use of BA, delivering relevant BA services and allowing stakeholders to pull the BA artifacts that address the challenges they face.
The number one reason I hear from IT organizations for why they want to embark on MDM is for consolidation or integration of systems. Then, the first question I get, how do they get buy-in from the business to pay for it?
My first reaction is to cringe because the implication is that MDM is a data integration tool and the value is the matching capabilities. While matching is a significant capability, MDM is not about creating a golden record or a single source of truth.
My next reaction is that IT missed the point that the business wants data to support a system of engagement. The value of MDM is to be able to model and render a domain to fit a system of engagement. Until you understand and align to that, your MDM effort will not support the business and you won’t get the funding. If you somehow do get the funding, you won’t be able to appropriately select the MDM tool that is right for the business need, thus wasting time, money, and resources.
Here is why I am not a fan of the “single source of truth” mantra. A person is not one-dimensional; they can be a parent, a friend, or a colleague, and each has different motivations and requirements depending on the environment. A product is as much about the physical aspect as it is about the pricing, message, and sales channel it is sold through. Or, it is also faceted by the fact that it is put together from various products and parts from partners. In no way is a master entity unique or has a consistency depending on what is important about the entity in a given situation. What MDM provides are definitions and instructions on the right data to use in the right engagement. Context is a key value of MDM.