Given the growth of both Apptio and ServiceNow, it’s not surprising that some IT leaders are wondering if they should do both at the same time, or get one in place before starting the other. I recently sat down with Lance Warner, Senior Architect and Director of IT Infrastructure at First American Financial Corporation, who explained why they started Technology Business Management (TBM) without waiting for a Configuration Management Database (CMDB), or service definitions and how Apptio helped both to accelerate their ServiceNow journey.
PARALLEL AND COMPLEMENTARY TRACKS
Dave: I understand First American put Apptio in place before ServiceNow. In hindsight, do you wish you had done it in reverse?
Lance: It wouldn’t have been practical for us to wait for ServiceNow to be implemented before starting with Apptio. Now, would I have liked to have a CMDB already in place for TBM? Sure, it would have been nice to go to one place and just download the asset data. But realistically, that isn't the way it works. We needed TBM to accelerate having a CMDB. Otherwise I think it would have taken forever. The success of the CMDB was put on this very important path so that we could continue with TBM.
Dave: What do you tell other companies thinking about doing ServiceNow as a way to get their data cleaned up for Apptio?
Lance: I really think that you need to start TBM wherever you're at (with your data). I wouldn't hold off doing TBM while waiting for your asset data to be cleaned up in a CMDB. In fact, we did the opposite. We used Apptio to kickstart our CMDB.
Dave: What data were you pulling into Apptio that eventually seeded the ServiceNow CMDB?
Lance: We had a bunch of individual asset files. There were three or four major asset data sources including Altiris (discovery and asset management) and spreadsheets being managed by different groups. So we brought all of that together in Apptio and that's where we did our first consolidation and all of the joins in our asset and application data. That's what we used to seed the ServiceNow CMDB.
Dave: And what could you see as you merged the different asset datasets in Apptio?
Lance: We could see “this is Server 27 and it belongs to application 1, and this is Server 28 and it doesn’t have a known application…” We just pulled in as much information as the groups had at that time to really understand where our gaps were and then see the cost impact of those data gaps.
Dave: And that was valuable?
Lance: Yeah, we made it work. Some people would say "We're not ready to do this, we know our asset data is not clean enough.” We said "We get it, just give us the data and we'll figure out exactly where we are." And you know what? It got us off the ground and it worked fine. Now, it was a lot of work (for me) to collect those (different IT asset) files and get them up-to-date every month and make sure someone didn't change a column name. When we got the ServiceNow CMDB, then we said, "Okay, now this is the system of record for asset and application information."
ACCELERATING THE CMDB
Dave: In my previous lives with BMC, HP and CA, I saw a wide variety of CI types and attributes and relationships. It could be pretty daunting to agree on where to start. Was there much direction as to which ones were most important for your ServiceNow CMDB?
Lance: Yeah, sure, there's direction from everyone, right? Like, which ones are most important to Dave? You'll say, "Well, this one is definitely most important." And go talk to the other guy over there, he’ll say, "Well, this one's definitely most important." Talk to the development team, they'll say, "Well, I need to know what environment it is. Is this my stage environment? Is this the integration environment?" They really care about that because it determines what development build they deploy. Then you talk to the server ops guy, he's going to say, "No, it’s most important to know which OS is on there."
So from a TBM perspective we said, "These mappings are what's most important to a business view" because now we know what these servers are costing us approximately, and to not know what application or service or business unit is consuming it can be costing us real money. And by this future date, any server that we don't have mapped to an application or service, we're going to shut down and we're going to save the company so much money per year. And you know which data the Business got behind and supported and which we got filled out first? It was that mapping information.
And that helped both the operations and TBM teams because we moved out of this whole technical world into more customer-focused, business-focused questions, like “where is our money being spent” and “how much are these applications costing us?”
Dave: Since you've had both systems up and integrated for a while now, do you continue to see TBM driving data improvements into the service management arena?
Lance: Absolutely. We can see in Apptio where the CMDB data is getting better, that our number of unmapped servers went down by X percent and X dollars, that more of our applications have granular server costs underneath them.
CHANGING OUT THE ASSET DATA SOURCE
Dave: What was it like to switch from loading Apptio with asset data from Altiris and all those spreadsheets to a feed from the ServiceNow CMDB?
Lance: We just mapped the old asset fields to the new CMDB fields so we didn't have to rebuild the reports or change the model in Apptio. For example, in Apptio at that time, we used "Server Name" with a space, and in the ServiceNow CMDB they called it "ServerName" with no space. So little things like that. No big deal. It took a couple of hours to do all the re-mapping. Mostly, we got new data ([fields]) that just added to what we already had.
Dave: And then once the new mapping was done...
Lance: It's done. No more change was necessary. Data from ServiceNow just flowed through the model and to the reports.
USING TICKET DATA
Dave: When ServiceNow was up and running did you bring ticket ([incident and change]) data into Apptio?
Lance: No, it came much later.
Dave: And you used tickets in Apptio to understand application support?
Lance: Right. The application support team can see cost and performance KPIs together. So, this is internal information for the support management team to optimize where their resource time is being spent. They see that division X gets so many more level 2 calls and that costs us this much more and here's how that rolls up to applications and services.
Dave: Do you use tickets to allocate costs for chargeback?
Lance: No, we don’t want to incent the wrong behavior. We don’t want to discourage end-users in the business from using the service desk. For us, service desk is a warranty service, it's something you just get and something you just pay for.
Dave: So app support is treated like a flat, fixed fee that just comes with an app service?
Lance: That's right.
Dave: But then internally, within app dev, you’re using those metrics to better allocate resources?
Lance: That's right. "Hey, look – we’re spending 60% more on Dave's app than on Lance's app because he's coding it in a non-standard way, or he's not using QA, and here’s the financial impact to the business." If we see that our level 3 service desk guys are constantly supporting application 1, then we would take the cost of that and go back to the application owner and ask them to get problem management involved. Or maybe we tell the application service owner that their support service costs are going to go up, so they can make the right service quality vs. coding speed vs. cost decision.
DEFINING & PRICING SERVICES
Dave: Should you have your services all defined in a system like ServiceNow before starting TBM?
Lance: We had a team working on identifying our services about a year or two before we moved to TBM, and they were still vetting and finalizing what those service names were going to be when we started TBM. But we took it and said, "This is good enough." And we took that and just started, and it changed a little bit since we started, but I absolutely don't think it's a required thing to start TBM. I don't think it's a necessity or prerequisite to get going because, even if it changes midstream, you can change it in TBM.
But I think the key here is speaking to the business and showing them that you're managing IT more like a business and you have costs now associated, more than just GL costs. You now have identified these high-level IT services and here's approximately how much each one of those services costs. And we're going to continue to refine this as we move forward and finalize these IT services.
Dave: And if you were to try to define your services for the first time, is there a reason you might try it from a costing and business standpoint first before you try to define those services in a CMDB or in a service catalog?
Lance: Absolutely. I'll tell you exactly why. It's because, as IT people, we have a tendency to geek out and we want to come up with 50,000 variations. “Well, my stuff is unique and I need my own service.” Well, the business doesn't think like that. They're not thinking about all the speeds and feeds, and every possible service name. They can see we have desktop computers that we take care of for them, we have servers, and it helps reel some of that stuff in. Having TBM in place helps some of the analysis paralysis that we have a tendency to get stuck in.
Dave: Do you guys publish a service request catalog through ServiceNow?
Lance: Yeah, absolutely.
Dave: Are there prices on those?
Lance: There are.
Dave: And were the prices there from the beginning or did they get added later?
Lance: No, they got added later. And where did they get those prices?
Dave: I would imagine . . . Wait, are you turning the tables on me?
Lance: I'm trying to help you see the light, so it all starts to make sense. How are you going to make a service catalog with pricing, if you don't know what it costs? You want to start with a rate sheet? Great. Where is that going to be seeded from? Are you going to pick a capital expense? Hmm... What about all that labor and stuff that goes into that? Oh, Apptio has that! Now I know why identifying service assets as small, medium, large, extra-large when I was collecting those service assets was so important. Now, I can put it in my catalog and say, "You want a small server? No problem - $150 a month."
Dave: Like choosing medium instead of large servers?
Lance: Exactly. So, everybody in IT runs into particular users or divisions or groups that tend to want more than they really need. Well, when they start seeing how much that really costs, they start thinking twice about it.
Dave: Did you model in variable costs as part of that analysis?
Lance: Yeah, absolutely. Service owners understand variable costs, so they can provide the business with pricing that factors in the incremental cost for having that larger server or extra gig of solid state storage.