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!

We Don't All Need World's Best Practice

In anything but the smallest of IT departments chances are that at sometime you will need to rely on the efforts of others to design and deliver some project or other, be they internal staff, contract resources brought in-house or a full blown systems integration firm. There’s also a reasonable chance that you may not have managerial authority over those undertaking the work, or perhaps at best a dotted line report to you.  When faced with this scenario most of us will want to exert some degree of control or influence over how the work gets done or, at the very least, we’ll have an approach we’d prefer those charged with performing the work to follow.

One common element I’ve noted amongst many of the people I’ve managed or mentored over my career is an hesitation, or even unwillingness, to commit to paper a set of rules or guidelines which will govern the way in which others conduct their design, development and implementation activities. Often these folks have claimed that this sort of guiding documentation isn’t required, citing reasons including direct supervisory authority over the project team, the ability to exert technical influence in a one on one scenario with key project team members, or that the project team is experienced and skilled enough that such governance is not required. To my way of thinking none of these reasons really holds water. Even if you are able to direct or influence the behavior of the project team, to tackle this in an ad-hoc fashion is ineffective, not fair on the project team (it’s hard to work within given constraints when those constraints are only trickle fed to you and often only arrive at a review stage) and often this direction falls by the wayside as project pressures heat up (if it ever actually occurs at all). Leaving things ungoverned is also a risky proposition – there are many ways to skin a cat – and there is no guarantee that the approach taken by the project team (no matter how good or effective it may be) will result activities or outputs which mesh well with your existing team, processes, procedures or landscape. Failure to govern, guide and set some ground rules can, and usually will, result in project outcomes which are not as good as they could otherwise have been.

I have another theory as to why people are reluctant to commit such ground rules to paper – fear! It’s a natural reaction when you’re dealing with the unknown. Other than a paper CV and perhaps a few preliminary meetings you have little real idea of the depth of experience and skills of the “outsiders” you will be working with. Concern creeps in: “will they know so much more than me” and “will I look stupid alongside them or in their eyes” are just two of the things those little voices in your head might start to whisper to you. I can recall these feelings in the past even the project lay squarely in an area in which I had deep expertise. Imagine how uncomfortable a person already a little uncertain of his or her skill and experience in an area might feel! Alongside the fear comes overwhelm: the feeling that there are just too many things to think about, that it would not be possible to get them all documented without missing at least one or two items. This thought process leads right back to feeding the fear with concerns that omissions from the document will only make the author look even worse in the eyes of his or her management or the new people arriving for the project.

Let me put an idea out there. You don’t need to know more than the people coming into your company, you don’t even need to know the best way to tackle a certain technology problem or the ins and outs of the latest development techniques or what domain thought leaders are debating amongst themselves. There is no need to commit to documenting world’s best practice, nor to hold your project resources to that standard. Good practice will be fine for the vast majority of situations. But how do you even know what good practice is? And how do you make sure that you cover all of the big-ticket items? Knowing everything that is important to think about can be daunting.

I favour tackling this with something I call the Bad Outcomes approach. Rather than trying to think of everything that needs to be done in a certain way or toward a certain approach, simply make a list of the bad outcomes that could result from the upcoming project. Start with the really big ones; the things that might cost your company at the high end of the scale, whether it be financially or in other less direct ways such as reputation or brand damage, or even worse could cost you your job. Once you have those down move on to the layer below, those bad outcomes which may not be as catastrophic but are still likely to cause a prolonger period of discomfort. Mull on these items for a few days; discuss them with colleagues, both from within the IT function and from the business, adding any new items that might come up. Revisit your list and drop any items which would only cause minimal impact or short term pain and with luck you’ll have a relatively short list of the outcomes that you need to govern against. As an example, the last time I went though this exercise I ended up with only eleven items for a project likely to be worth multiple tens of millions of dollars. Now you’ll have focus – you’ll know what to work on that’s really important. It won’t matter if you don’t use the World’s Best Practice approach to govern and guide each item, so long as you find a way which is likely to avoid the outcome then you’ll have what you need and you’ll likely have saved your company a pretty penny in avoided costs and perhaps even your job along the way.

The next time you’re faced with the need to craft a strategy or pen a set of standards or guidelines don’t worry about what you don’t know. Remember, no-one will know all there is to know about a subject, so accept that you won’t always know the best way to solve a problem or everything there is to think about, but I’m pretty sure you, like me, have your scars and war stories so you’ll know what you want to avoid, so start there. Good luck!

Technology Leadership - A Misnomer?

If you've had a career of any reasonable length in the IT industry and have a track record of success behind you then chances are you're now in, or at some future point will be offered, a role which is considered a Technology Leadership role. In the data and information space these types of roles include Architects, Business Intelligence Managers, Competency Centre Leaders, Data Quality Managers and the like.

I've worked in many of these roles at various times and the one thing that they all have in common is that often this so called technology leadership is actually dealing with issues that have little to directly do with the technology at all. Rather the Technology Leader spends his days strategy setting, looking for ways to deliver business value through future change or the current actions of his people, engaged in stakeholder management, selling concepts to senior management, and so on. Most of these issues are actually more closely aligned with managing functions, people, shaping programs of work, etc and require some ability to control and direct and have access to, and authority over, budget and resourcing decisions. Without this the leadership may become divorced from the ability to deliver which can have serious ramifications on credibility, influence and ability to show effect and value from the leadership role. Perhaps it could even be argued that people in such roles are shouldering, and in some cases having to own, some of the concerns traditionally associated with line management without having enough say in solving those problems - i.e. their plans could be quashed, derailed or rerouted by others who do have control over budget, resourcing or strategy.

In order to allow our technology leaders to add the most value we need to realise and acknowledge their leadership is in fact only in part technology based. Our technology leaders need a seat at the management table to be truly effective. Taking this step delivers another benefit. Technology Leaders are in the decision loop early, ensuring better alignment with other initiatives and allowing others in the management structure better visibility of, consideration of, and therefore use of the area from which the "technology" leader comes.

The alternative to this arrangement is the introduction of Thought Leadership roles. These may well be ideal positions for the person formerly known as Technology Leader if the organization can stretch to that. However most can't due to lack of size, true need, commoditisation of many facets of the IT function, or shrinking budgets. The unkind (or is that better phrased as jealous?) spin on these roles might well be lots of thinking, musing and sprouting of opinion without the need for implementation efforts hampered by real world constraints and politics. Hey Gartner - if you're ever looking, I'm over here :)