 Live from Cambridge, Massachusetts, it's theCUBE at the MIT Chief Data Officer and Information Quality Symposium with hosts Jeff Kelly and Paul Dillon. Welcome back. We're here live at the MIT CDOIQ Symposium. I'm Jeff Kelly. You're watching theCUBE. We're here all day today talking about the evolution and the elevation of the role of the Chief Data Officer. We're talking about data governance and transforming businesses through the use of better use of data and analytics. Our next guest is Bill Ulrich. He's the president of TSG. He's working with a number of organizations to help them transform their organizations, find better uses for data, how they organize their data, how they apply analytics to their enterprise-wide processes. So Bill, thanks for coming on theCUBE. Great for you to be here. Thank you. Thank you. Appreciate it. So tell us a little bit about yourself and kind of TSG and really what your mission is. Sure. I've been working in the field of information management, IT, business IT transformation for about, well, most of my career, so about 35 years. The last 25 years I've had my own company. The focus has been largely on large-scale transformation initiatives. Historically, I've come at it in the earlier days from an IT perspective. What I found out gradually probably started dawning on me about 25 or 20 years ago and really started hitting me in the head about 15 years ago is that if the business doesn't get behind and drive the transformation strategies that you want to pursue, you're going to end up with a non-sustainable environment or non-sustainable solution. And the reason is because IT comes up with its approaches and its technologies, but they're not sustainable from a business perspective because the business doesn't really understand what's happening. They have a lot of promises on improving things and making things better, but they don't really understand how it's delivering value to the bottom line. So what I've been focused on over the last 10 plus years is getting to more business-driven sustainable solutions where the business can't just stop something because it's their initiative, they're vested in it, they've defined it, they've defined the strategy and the direction they want to go, and it becomes their focal point. And more recently, over the past five to six years, we have found that the best way to do that is to establish a business architecture in the business to then take the business architecture and take your strategies and your plans and your requirements and your demands you want to pursue and put those through the lens of the business architecture so that you can articulate that for IT. So let's just take a step back for just a second and just unpack the term transformation. So are we talking about organizations that want to enter a new line of business, that want to change the way they're doing things because perhaps revenue growth is stalled? What do we mean by transformation? Right, so transformation can mean a lot of things to a lot of different people. It all depends on what you're trying to accomplish. On a small scale, it might just be doing some basic alignment of your customers between two business units. On a larger scale, there's some organizations now, financial institutions for example, multi-line insurance and financial that are trying to go from a very product-centric business unit siloed business model to a horizontal business model where the customer is viewed consistently across all of the different insurance and financial lines. The value to the business of doing that is now that the customer has a consistent view of you. You have a consistent view of the customer. So when they show up on your doorstep, for example, you know that this person has six other insurance products, two financial products. That's one example, mergers and acquisitions, large-scale consolidations, divestitures, or even just going to the point where you've realized that your IT systems have so much technical debt they've got so far out of line with how your business works to get a better framing of your business to try to move through some sort of scenario where you can realign your solutions to the business needs and strategy. You talked about strategy and I think a lot of CEOs would tell you that they do strategy well. I'll bet precious few of them actually do. What is a good strategy from an IT perspective? What is it? It gives an example of a strategy statement that can actually be used for tangible IT deliverable. So I don't believe there's – and it was interesting because I was just helping somebody advising them. They were trying to craft what they call their IT body of knowledge or IT box. And their focus on IT strategy was very IT-centric. How does IT deal with procurement better? How does it deal with vendors better? How does it deal with all the different things you see in the ITEL model? I don't believe there's such a thing as an IT strategy. I believe that there's a business strategy. I believe that IT is a business unit that aligns to that strategy. So my view of strategy is the business strategy. We are going to move into these new markets. We are going to increase market share for these types of products. We are going to roll out a new product line and series of products with their product line. We are going to move from the personal line to the commercial lines. To me, those are your strategies. And business has to set those and define those and define the aspects of the organization that they want to focus on to improve that. And then IT needs to align its solutions to the directions, the focal points, and so forth. So I believe that the office of the CIO, and many of them are, need to be at the business table talking about these things. And then in order to make this actionable, we need to be able to have the business articulated first and foremost, as opposed to going right to, I need to build three new systems or replace this database in order to implement this. We need a business focus first, action plan, transformation plan, and then move to the IT plan. So well, increasingly, so some of those business type of decisions and strategy decisions you were just talking about, should we move into a new market, want a new product, change a product? Those kind of decisions are being driven by large-scale data analysis. What role is data playing in driving those kind of decisions, and how do you advise clients to actually start taking data into more account when you're actually setting the business strategy, not necessarily the IT strategy, but the business strategy? Good question. So when we look at strategy, first of all, I just want to frame this, from a business architecture perspective, we espouse the normal tools for looking at strategy, whether it's Porter's Five Forces model, whether it's Norton Kaplan strategy maps, whether it's the traditional SWOT analysis, the different types of tools we look at for espousing strategy. So first of all, that's really important, and even if it's just something more basic than that, we need to understand what they're trying to accomplish. Now there is information that needs to feed that. How do we get better information about what we're trying to accomplish? Well, you have a little bit of a situation where you're trying to evaluate how well you're doing information today, and whether or not you're getting adequate information being fed up into your analysis processes. We look at something through business architecture, it's sort of a multi-focus lens. One is we look at the value delivery for your stakeholders, we call the value streams. We look at the capabilities you have that are necessary to deliver that value, and we look at the information perspective that's necessary to enable those capabilities. Now the information perspective provides the vocabulary, if you will, which has to align to what you're trying to accomplish from a capability perspective, which has to align and support your end-to-end value delivery. So as we look at this, and we get the information defined by the business in concrete ways, and it's as simple as defining a taxonomy of terms, or if you will, just a glossary of terminology of all the things you work with in your business so that you can get that consistency and terminology. We then need to frame what's necessary to deliver that stakeholder end-to-end value to improve those capabilities. So we look at capability heat maps, we look at value stream heat maps, we look at where the weaknesses are, and then we take the information necessary to deliver that, and we see where those weaknesses are, and we look to then improve that information, whether it's a more horizontal view across siloed information that's redundant and inconsistent. I tell a lot of organizations that there's a reason that the Tower of Babel never quite got finished, and it's because everybody was speaking a different language. Well, when we look at all the projects we have going on and all the requirements were going on, all those projects across all those different business units, I have business analysts, all of which are using a localized dialect of the overall language of the business. Localized dialects are creating chaos in the back-end IT environments. So we try to focus on moving away from the... You can still have your localized dialects. Just like if you go to Germany into certain corners and pockets, people will be speaking Schwabian. But if you want to speak, if you want to go to the centerpiece, the official language, if you will, there's a common language that they speak. So it's the same kind of thing. You can still have your localized dialects in a given business unit, but there is a common binding perspective on information. That perspective, then, how well is that supporting your capabilities and your value? We need to build all that and roll it together. Information quality is kind of an amorphous term. And to say it's a good thing is kind of motherhood. What are some of the more common problems, shortcomings of information quality that you see with the clients you work with? I'm doing oversight on a very large program, multi-year transformational program. It's a federal agency, U.S. federal agency, where we're doing this work. And they have a business architecture, and they've defined their information vocabulary, and they've driven that back through into the data architecture. So they now have a consistent perspective from how they want to organize this information. First of all, the information, the way it's organized today in the existing environment is not organized in a fashion that's conducive to delivering what the business really needs long-term. More end-to-end perspective, more of a value-based perspective, more consistency across all the business units. I don't mean to interrupt you, but you were saying the information itself isn't bad, but it is not complete? Well, we got down to the fact that in fact it isn't complete, which is one thing IT doesn't quite realize. We find out that a lot of the data that people are really using in some of the business units, which should be centralized and defined and available, are either buried in spreadsheets or literally in some cases in file drawers, where they have to pull the information out. So first of all, what IT doesn't realize is they only see part of the picture. Half the business in some estimates is automated, half of it isn't. A lot of it can be automated, but we don't know what can be automated, because IT only sees what's automated as opposed to what's not automated. There's information that doesn't exist in the IT environment. So when IT looks at going from point A to point B, they only look at what they have. What they don't look is what they don't have. And what is coming at it from the business perspective tells you where the information is that you don't have. So there's entire business units that are doing things largely manually today that have been left, for whatever reason, left off of any type of automation over the decades. So again, we want to, they're focusing on the piece that's already been automated. We need to focus on the big picture, because if you don't have the big picture, that data will remain in spreadsheets or in people's file drawers. Then we got to the point in the same project of saying, all right, so we know that. We now have a big picture that we need to get to long term. What about the existing information? In that case, we had a lot of data problems. In the example that I'm, and many projects I've been on have the same problems. We look at date fields, there's no dates. We look at basic information on the country of origin, there's no country code, or the country code is wrong. So you start doing this filtering, and you start doing this what if analysis of, or what's in their analysis based on where you're trying to move, because now you have a target, and you put out based on certain levels of rules, and we came up with a rule hierarchy. There's a basic level where you can't have garbage in a date field. That's one level. There's another level where you need to have things actually connect to each other in a reasonable way and not conflict. There's a third level where the data is actually breaking a whole bunch of business rules. So we created a business rules committee within the business, and all these issues are being brought to the table, and the business then looks at these things and signs off on, this will be corrected in this way, this will be corrected in this way, so that when you're putting dates in front of people on the screen, it doesn't show up as 1BC, which is what happened with one of the display situations. Well, we know it wasn't 1BC when they went through this process. So I want to push back a little bit on, so you mentioned about having this kind of centralized, basically having one language throughout the entire organization is speaking, so you want to have a kind of a centralized taxonomy, right? Now, does that in any way, I can definitely see the benefit of that, but does that in any way limit the flexibility of the different business units to do what they want to do? In other words, are they bound now by the central language, the central dictionary, if you will? Does it have a more distributed approach while it will not have as much consistency across the organization, allow the different business units to actually be a little bit more flexible, a little bit more nimble? Is there a tension there? Okay, so there is some tension. It's largely political as opposed to real. The tension is that I have my money and my budget, and I'm going to spend it the way I want, just like I have been for the past 20 years, and you're not going to tell me how to do something better or differently with my budget just because it's for the good of the organization as a whole. So that's the political pushback that we get at that quite a bit, large and trenched organizations, you run into it all the time. In terms of the general, the common language, we're not trying to tell people that they have to do things differently in their business, we're not trying to tell people that they can't continue to use their dialect within here, but when we're bringing all the groups around the table, we're going to have a thesaurus, and that thesaurus will have one common vocabulary that we can all use to communicate. That common vocabulary, if you can do that, and where we've done this on major initiatives, and you bring that to the data architecture team, this is something that's gold to them. This is something that they've been trying to accomplish for years and years and years, but they haven't been able to get it because they're pushing it from the bottom up, or from the IT side in, as opposed to the business, which is really driving it from a strategy perspective, coming at it from a, what does my business architecture look like, what's my common underlying vocabulary for this. So, yeah, the largely what we went into with business architecture as a whole is political silos and fiefdoms. I want to go back to something you talked about earlier, about a lot of data being locked up in spreadsheets and even file cabinets, and I think of companies I've worked with, most of them, in fact, who prefer to send spreadsheets around on e-mail lists rather than using a shared spreadsheet. And perhaps in most companies I would submit that most of the data the company has is locked up inside individual computers and is this something that has to be busted up? I mean do we need to adopt more of a different set of tools to make data really accessible to the companies as a whole? I think it's a combination of things. Yes, we need some different kinds of tools, and there's great tools on the market. There's incredible things out there in the area of semantics and all kinds of technologies. So I wouldn't say that the tooling's not out there. I think that there's enough tooling to solve the problem. Largely what you're talking about here, what you're describing is a cultural phenomenon. And it's the cultural phenomenon is it's my information. I have it in here, I do it my way and if you... Or this is how I know how to do it and I don't want to learn to do it. I'm going to have to learn to do it a different way. So the session that we were in the round table we were in this morning or just after before lunch we were talking with Jim Gilligan from Blue Cross Life and he was explaining that they were using 10,000 spreadsheets to do their work. So they moved through this very much, they came out from a governance perspective and then very much of a cultural alignment perspective and then they began to move towards the slow incremental resolution of those particular issues. But if you don't do that you can't get to any kind of major degree of transformation because everything is interlocked in those spreadsheets those are locked into the systems. We have situations that we run into where those spreadsheets are not only taking data off of systems but they're playing an in-between role and then feeding data back in. And I was at a financial institution investment company about a year ago and they had 25,000 spreadsheets and this is still small for some organizations and there was a huge room in one of their buildings that was just loaded and everybody in there that I could tell was working with spreadsheets at the same time. And a woman said, well they just put a new release of this system in and I just had to add 25 more spreadsheets to my solution. IT thought that they were doing a great job but what they don't see is there's no visibility to the other side. So what we're trying to do is come at it from a business perspective to drive it back into IT from a business perspective because left on their own nothing against IT they will fill the gap with their own solutions and come at it from their own perspectives. The CDO role, interesting we've been talking to a lot of our guests about what CDO means and one of our guests yesterday actually a chief information officer said he doesn't believe we'll have chief information officers in 10 years. We will have chief data officers because the information, the infrastructure is all becoming invisible, the data is what counts. What do you think is the future of the CIO versus the CDO role? An interesting question. I do think that somebody needs to own the information and we have a lot of organizations have CIOs and CTOs CTOs are the ones who are managing a lot of the technical infrastructure what I call the technical architecture. CTOs largely are dealing with what I call platforms and plumbing all the stuff that's keeping everything working under the covers. The part that gets ignored by a lot of organizations is the application and the data architectures which collectively roll into the solution architecture. So it's easy to ignore the solution architecture because you say well we can't change it it's too complicated we don't understand how it works because the applications are so interwoven we'll never be able to do anything with that. So that gets ignored and it's also intertwined with the data architecture we can't do anything about that because that's all interwoven and tied up and twisted up with everything else. Well those are the areas that actually have to change moving to a new platform, a new technology whether you have mainframes or not getting rid of one language over another largely that's all happening behind the scenes and to a great degree and some people may not like be saying this but to a great degree underlying technology and plumbing is largely irrelevant to these business solutions and the business functionality that you're trying to deliver as long as you have a good solid, rock solid data and application architecture back to your question I still think we need CIOs to play that role I also think that somebody needs to focus on the data because largely the CIOs haven't been doing that from their perspective. I think a chief data officer whatever you want to call them should be resident in the business because when the business says that they own the data or they own the information however you want to word it I think they say that but I think largely it's been lip service and I don't think that they've put enough focus on actually investing the time and energy and people and just getting them to establish a business architecture team with an information focus within the business has been like pulling teeth so they say they own the data but then they throw it over the wall to IT and frankly that's a lot of lip service in my book. So you're out there every day on the front lines working with clients I wonder if you shared a few examples I wonder if you could share a few more maybe one of the more successful engagements you've had recently maybe contrast that with some of the projects you've worked on where you've had some real challenges with organizations that aren't really in line with the approach or you've had to really twist some arms really sway some people to your way of thinking. Okay so success is it's a matter of a couple of things one is obviously being able to have all the right pieces in place and actually taking that business perspective and I'm working with a number of organizations who are taking that business perspective and driving it forward and these are multi-year engagements and a number of them are moving forward at a reasonably good pace the ability for them to actually move forward and perform successfully and so what I'm doing is I'm sort of carving off the best in terms of my view that are doing it the right way in order for them to move forward successfully you see a big difference in terms of where they're at today versus where they're going the data architectures if you look at I'll give you one organization about 12 years ago maybe about 14 years ago they completely revamped their technology and their data architecture and they came up with a relational database structure because they had been using a pretty clunky old 25 plus year old unstructured environment of file structures and so on they came up with a relational data model now they're what they did with that new application architecture and data architecture at the time and it wasn't perfect and it's gotten beat up over the years but they went from they took they stopped and they cleaned up a lot of technical debt that had been building for about a 25 or 30 year window they're in a better position today transformation wise to go to this next level because they took time over a decade ago to clean up some technical debt another organization very similar kind of organization has let that technical debt build for the past 30 plus years and where they're coming from limits their options in terms of where they want to go so instead of being able to build off a relational database and being able to do some really interesting sort of double scheming against the database for the new and old systems to get them they have to go through a complete transformation and synchronization which is a much much more difficult effort because you're backed into a corner and your expenditures and your level of effort and your risk in doing something like that is much much higher than if you're coming from a baseline that's a much better perspective so what I tell organizations is stop kicking the ball down the road to the next CIO or to the next decade because as you do that more and more you're going to end up driving your technical debt and backing yourself into a corner to the point where you're going to have to be boxed in and not be able to afford or to even maybe even accomplish some of these transformation exercises so what are some of your what's your advice for organizations who would say to you well that sounds great we'd like to do that but where do we find the resources to do that while also continuing to keep the business running right how do we find the resources versus keeping the business running well what you want to ideally do is meld those together so your business strategy should have some benefits associated with accomplishing the strategy so the question is well what happens if I still am siloing my customers five years from now what's the downside of that what's the strategic downside of having somebody be able to go to my competitor and when they type in their information it says welcome back Mr. Allrick we see here that you have three financial accounts and five insurance products with us what are you interested in today and as opposed to somebody on a phone saying please type in all your personal information starting from scratch because they have no idea that you're a current customer those are the businesses that are going to lose out so the main thing that people have to start doing today is stop thinking about the quarterly return and start thinking about five to ten years out from now kicking the ball down the road and ending up with a situation where you're going to drive the company into a corner that they're going to have to try to dearly buy their way back out of and not be able to and you would say that standards are critical I mean thinking architecturally about data regardless of the platform you're going to be using is essential to that it is essential and it's not just thinking architecturally about the data it's thinking architecturally about from a business and an IT architecture perspective and the hand and glove thing that goes together is that the business has an information perspective that needs to transform into the data architecture and data management and data quality that can be worked on collectively with the IT organization so that those two things are working together right now from my perspective the data people are trying to carry the ball on the IT side and they have no counterpart partner on the on the business side to work with them because the business has thrown everything over the wall but yes architecturally it's absolutely essential some really good advice there from Bill Ulrich thank you so much for joining us on theCUBE we hope to see you again next year or other events thanks for watching we'll be right back with our next guest here at the MIT CDO IQ symposium