Data as an Asset – Walk the Talk

Establishing data governance programs, data quality initiatives or other projects aimed at looking after or enhancing the well being of a company’s data can be difficult to get underway and sometimes even more challenging to keep alive.  Such initiatives (especially if your company’s funding approach forces you to tackle them as a series of individual projects) cannot always deliver the concrete and tangible “things” that you might get from a more traditional IT project. More often than not there is no new asset created, no new system to implement and enable across a go-live weekend, nor are benefits always obtained and measurable in the short term. Unless your business is facing real pain (and honestly attributes that pain to not just problems with the data itself, but also with how the data came to be in the state it is) then you may well struggle building support for, and keeping data initiatives running.

Often this seems surprising to data folks. It seems that this isn’t logical. The business says all of the right things about valuing data quality, about wanting a single source of truth from which to make better, faster and more cost effective decisions and maybe someone has even sprouted the “data as an asset” phrase, but this hasn’t resulted in them beating down the door with bags of money to fund data improvement initiatives. At first glance it seems key business stakeholders are showing moral support for the concepts but no commitment to the actions required to really solve the problems in the longer term.  They are the chicken to the data team’s pig.

But perhaps it’s not all that surprising. Are you, as a data leader, walking the walk or simply talking the talk? Do you treat your company’s data as an asset yourself? And does your data strategy reflect that? Do you even have a data strategy or are you one of the many, described by Joyce Norris-Montanari in her recent blog post  (http://www.dataroundtable.com/?p=12661), who fall into the group lacking a vision for their data and a strategy to help them get there?

If you’re not walking the talk then chances are that you’ll need some work up front to sell a congruent picture to the business, and particularly to those stakeholders holding the purse strings.   Make sure that you can show the basics around the company’s data that you would have around any other asset.

• Knowing what you have – an inventory of your data;
• Knowing where this data is – which systems house which data and (ideally) how it moves around between them;

• Knowing which stakeholders care about which data (you don’t need to get to business data ownership just yet, but at least you should know which data helps achieve, or threaten, which stakeholder’s bonus package);
• Knowing what preventive maintenance is required to keep your assets running at the required level and optimize the investment in them- some idea (and documentation) of where the problem areas lie. The big data quality issues (and importantly their real impact on the business);
• An understanding of how you can protect your asset – which may include classifications for data along with associated handling rules and other security aspects; and
• A vision for continuous improvement and a better future state of asset management – thought out and documented ideas for better use of your asset (which might include identifying and reducing redundancy, identifying inventory gaps or working better at the extreme ends of the asset life cycle).

With enough of the above in place you have your house in order and can say that you are indeed making efforts to treat data as you would any other asset. Now that you have a congruous story to present to the business you may find your next funding request is met more favourably. Even better, chances are you may well have identified a number of projects to deliver some concrete shorter-term benefits along the way as well.   

What Do You Mean You Don't Need a Data Model?

On more than one occasion across my career I've found myself having to justify why we should bother undertaking data modeling exercises. Thankfully I'm not facing that problem currently, but I am in the midst of refreshing a set of strategy, standards and guidelines documents and recently found myself writing a "Why Model Data?" section as a preface to one document. It got me thinking that, despite all of the prior times I'd had the discussions, I'd never really succinctly put down in one place the why it is that I think we should undertake a data modeling process - how it adds value, if you like. So, this blog post is the result.

Modeling of information systems without modeling of the data they operate with can, and does, lead to bad outcomes. Modeling at only a systems or application level often fails to consider important characteristics of the underlying data, instead painting a picture which is only representative of a particular method of use of that data. Such modeling frequently impedes reuse of data across organisations, lowers the quality and speed of decision making and can lead to the unnecessary IT spend and the development of siloed IT applications with unwanted and sometimes unrecognised redundancy. Modeling of data assists with building understanding not only of data content but also of data relationships, with an effective data model being a key enabler of successful integration and well aligned and efficient application architectures and portfolios.

The explicit act of data modeling also encourages discussion about the meaning of data and the appropriate (or otherwise) use of various data elements in different functions of the organisation. It may well expose differing definitions and understanding of the same elements of data that, prior to the modeling exercise, those in the organisation had been unaware of.

Higher level data models also serve as a useful communication tool, helping to bridge the IT – Business divide and provide a mechanism to forge a common understanding of particular areas of the organisation’s data. Data which is easily and well understood is more likely to be reused as not only is the barrier to reuse lowered, but the urge to collect and store the same data elsewhere for another purpose less likely to come to the fore. This important aspect can be a mechanism for cost avoidance in that it lessens the risk of the design and implementation of systems which make ineffective or inappropriate use of the data assets.

Finally, when coupled with other [types of] models, data models allow an understanding of an organisation’s current technology landscape and the way it interacts with business processes. This understanding forms the foundation for efficient and low cost impact analysis around process and system change, in turn enabling business agility.

So there you have it. Part elevator pitch, part business case executive summary. I hope it helps someone the next time they're arguing for funding to develop or maintain the enterprise data model or trying to convince a bunch of rogue developers that simply using Visio to draw an ERD after the application is delivered isn't really the best approach!

Rethinking Your EIM Program

I've not looked at a Gartner Hype Cycle in a while, but I'm pretty sure if I did I'd find Enterprise Information Management (EIM) Programs heading into the Trough of Disillusionment. From what I'm hearing these programs are doing it tough and its not surprising.  EIM aims and value can be hard to articulate, I know I've struggled at times with ours . If you have an EIM program what's your elevator pitch? Phrases like improved decision making, better data management, and leveraging the data asset abound but chances are that many decision makers are coming to see those as little more than motherhood statements, particularly if there's been an EIM program in place for a while with few real benefits yet realised.  Although there may have been initial agreement around the problems to be solved and excitement around the promise of the program your sponsors may no longer really be signed up for the journey and are probably now struggling to see the way there.  


Perhaps it's time to rethink the strategy we take toward reaching our EIM goals. Rather than one big program maybe the use of strategic themes might work better. Use themes to chunk your nebulous program down to smaller quick projects which deliver toward and enable a common theme and focus the efforts and imaginations of people around a few key areas and projects at a time. It's easier for people to see value along the way yet (if you keep your eye on the longer tern prize and larger goals) still possible to get to the bigger picture by drawing synergies from projects along the way. Some of the themes I'm promoting right now include making information findable and believable, and the use of templates to tie information and process together and allow nimble reuse when new business initiatives arise. 


Using strategic themes also means it's much easier for people to "get it" and you, as the architect of the broader EIM initiative, will have better control over how they perceive what's important to do next. Equally importantly you'll have a better chance that they won't "get the wrong end of the stick" and become focused on the wrong things and put their energy into work that really delivers little to advance your true EIM aims.  Another plus is that it's more likely that you'll have people wanting to get involved (and hence get better people) if they can see what is going to be delivered in the smaller projects within the theme. 


If your team structure allows it then look to embed account managers in to the various business areas to get early signals and information about what needs are out there and weave these into the strategic theme sets where appropriate. Doing so will get people on the train.  Let the inertia build and then use that inertia to drive through those pieces of work which are less tangible - whether they be advancing data stewardship, building out the enterprise data model, or something else.


I believe this chunking and strategic themes approach will become more important across the coming 12 -24 months,  particularly if your company places more stock in initiatives with strong business cases and has an over representation of business improvement projects among the successfully funded initiatives and pushes those with less obvious or quantifiable benefits to the back of the queue. This approach will also give you the flexibility to be nimble and stay aligned with business strategies and priorities as they change rather than locking you in to a full year's budget cycle many months before the first work even begins. 


With this approach there are bound to be trade offs but, hey, at least you're moving forward and making (some) progress toward your EIM goals. And that's got to be better than the program being killed entirely.