We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Blog: Jill Dyché Subscribe to this blog's RSS feed!

Jill Dyché

There you are! What took you so long? This is my blog and it's about YOU.

Yes, you. Or at least it's about your company. Or people you work with in your company. Or people at other companies that are a lot like you. Or people at other companies that you'd rather not resemble at all. Or it's about your competitors and what they're doing, and whether you're doing it better. You get the idea. There's a swarm of swamis, shrinks, and gurus out there already, but I'm just a consultant who works with lots of clients, and the dirty little secret - shhh! - is my clients share a lot of the same challenges around data management, data governance, and data integration. Many of their stories are universal, and that's where you come in.

I'm hoping you'll pour a cup of tea (if this were another Web site, it would be a tumbler of single-malt, but never mind), open the blog, read a little bit and go, "Jeez, that sounds just like me." Or not. Either way, welcome on in. It really is all about you.

About the author >

Jill is a partner co-founder of Baseline Consulting, a technology and management consulting firm specializing in data integration and business analytics. Jill is the author of three acclaimed business books, the latest of which is Customer Data Integration: Reaching a Single Version of the Truth, co-authored with Evan Levy. Her blog, Inside the Biz, focuses on the business value of IT.

Editor's Note: More articles and resources are available in Jill's BeyeNETWORK Expert Channel. Be sure to visit today!

July 2007 Archives

In which Jill remembers Sophie's selective hearing and likens it to the rigor-at-will approach of many IT managers, who--when it comes to business requirements--may find themselves barking up the wrong tree.

I once had an Akita-Shepherd mix named Sophie. We rescued her from the pound on her last day, so she was even more loyal than an Akita-Shepherd mix would be in normal circumstances. She was also scary-smart, great on hikes, and, well...willful.

When Sophie turned 10 she stopped listening to me. I'd come up from behind her and call her name. She wouldn't budge. I'd jangle her leash. I'd tap the food bowl. I'd yell "coo---kie!" in a high, sing-songy voice that made me hate myself. Nuthin' doin'. I finally took her to the vet who did the requisite inner-ear exam and loud-clicker tests and summarily pronounced, "Your dog's not deaf--she's just ignoring you." So much for being pack leader.

I feel the same way sometimes when I talk to IT execs about engaging business users. Some really, really want to. Some assure me that they already know what the users need. And some just ignore me.

But IT's ability to engage the business is critical, not only for data-intensive initiatives like MDM, data warehousing, and BI, but for a range of operational applications. As we've all heard by now, and as many of us have learned the hard way, "If you build it, they will come" is a fraught philosophy. But many IT departments don't have formal requirements processes that would be the logical vehicle for opening a regular dialog with the business side.

The result is that business people try building what they perceive to be appropriate business requirements and give them to IT. Then IT either pushes back and requests more detail (but doesn't really say what detail) or relegates the project to the Futures list.

IT needs to define the business user engagement process. It's much easier for IT to learn about the business than it is for the business to learn about IT. In fact, open any IT industry rag and stories of CIOs struggling to partner with business executives are as plentiful as, well, black labs at the dog park. It means defining a process, choosing a reasonable group of business users with a pressing need, refining the process with them, and then with other business users over time. It means documentation, frequent headchecks, and regular follow up.

The business should ultimately own its own requirements. But business people can't be expected to invent the process for engaging IT. IT has to make the first move, and lay out the process for not only initially engaging the business, but incrementally re-engaging them as the project moves forward. As my vet says, "Good communications makes for lasting friendships." This is usually right before he tells me how much the bill is going to be.

Technorati tag: BI requirements, business requirements gathering, agile requirements gathering

Posted July 24, 2007 7:01 PM
Permalink | 1 Comment |

In which Jill enters dangerous territory, has a tough conversation with a client, and picks up the dog poop.

I like to consider myself a little subversive. To me being subversive doesn't mean challenging the establishment as much as it does finding a fresh way of thinking within the confines of whatever system you're working in. Nothing wrong with confronting the current hegemony, being a bit heretical from time to time, and shaking things up in the name of moving forward. Paradigm shifts can be subversive.

Then again as I get older, subversive has taken on a milder definition. Like yesterday, when I made a left on a red arrow. Or last weekend when I took the dogs to an elementary school playground and let them off the leash. (Yes, I picked up after them. Just because I'm subversive doesn't mean I've forgotten my good manners.)

Last week I told an IT team that their company wasn't ready for data governance. At Baseline, we call these discussions the "I Love You But I Have to Kill You" talks, and they're never easy.

One of the questions we ask clients and prospects who are interested in launching a formal data governance program is: What's your ability to execute? Of course the answers vary and the interpretation of "execute" is always a bit loose--usually hovering around the maturity of data stewardship at the company. I love this question 'cuz everyone always learns something new, which is one of our value props.

Turns out after we explained why they weren't ready, our client sponsors weren't ticked off but newly-emboldened to lay the groundwork for data governance. Preparation itself can be a project. And it can also be an act of subversion. As part of its data governance readiness, our IT client approached the CMO and requested budget for staffing a data steward. This team had never approached a business-side leader before. It was a daring act of, well, courage. Which can be subversive. Or just plain smart.

Technorati Tags: Data Governance, Data Stewardship

Posted July 16, 2007 9:05 PM
Permalink | No Comments |

In which Jill relates the philosophy of a data warehousing and MDM best practice--MDM newbies take note!--implicitly admonishing smart people not to buy her martinis.

I recently spent some time with Neil Freake, manager of BI development at Scotiabank's Enterprise Data Warehouse. I'd met Neil last year at the DataFlux User Event in Vegas and we shared a nice conversation about MDM strategy, some stories about data ownership challenges, and a couple martinis. My memory of the details is obviously hazy, so it was nice to catch up with Neil a few weeks ago in Ottawa and in Toronto, where we were fellow speakers at an MDM executive briefing hosted by DataFlux and SAS Canada.

I've been bemoaning the fact that we've recently watched a few data warehousing teams circle the wagons, protecting incumbent technology platforms and headcounts and claiming that they're "already doing" MDM. In doing so, they sabotage organizational understanding and delay adoption of MDM capabilities that could actually enhance the data warehouse--not to mention strategic business programs.

Scotiabank is in the all-too-rare and refreshingly visionary position of supporting its MDM efforts through the data warehousing group. Neil has a realistic and practical vision of how the bank's MDM strategy overlaps, but doesn't represent, its enterprise data warehouse capabilities.

"Our data warehouse is requirements-driven," he explained to a packed auditorium at SAS Canada headquarters. "We only pull about 30 percent of our corporate data onto our enterprise data warehouse. We consolidate data marts, integrate enterprise data and provide information in near real-time, but we are not operational...we're not systems. That's how we keep our business users happy, and it's also how we manage growth."

Neil echoes the view of many EDW best practices--Scotiabank won a TDWI best practices award back in 2002--that the data on the warehouse should be informed by the business' need for analytics and BI, rather than a general-purpose dumping ground for all the data ETL programmers can get their hands on. "We're not going to put a bunch of data onto a data warehouse or an ODS that we don't need for BI," he says.

Notwithstanding its data evolution, Scotiabank's needs for MDM (specifically CDI) are quickly emerging as the integration and reconciliation of customers across systems promises to augment initiatives from target marketing to anti-money laundering. Data warehouse professionals are uniquely positioned to see the benefits of operationally-integrated data through MDM, and usually have the incumbent skills to support operational integration and deployment of master data.

"The EDW can help start MDM," Neil Freake concluded. "But we can't fix it, and we can't be it." Scotiabank's MDM program--supportive and mindful of, but separate from the data warehouse--is well underway.

Technorati tags: Master Data Management, Scotiabank, customer data integration, CDI

Posted July 7, 2007 1:02 PM
Permalink | No Comments |