Enterprise Resource Planning

What is the scenario in India when it comes to SLA management?

We believe that the adoption of formal SLAs is fairly limited in India. SLA formulation and management requires IT and multiple business stakeholders to accept a single version of the truth, in terms of the data that drives the metrics. This is typically a fairly resource-intensive task that involves aggregating data from multiple application repositories, databases, infrastructure management systems, configuration management databases and service desks. The cost is at least in the order of tens of thousands of dollars, and in many cases above the U.S.$100,000 mark.

A company would take up such a resource-intensive project only if sufficient scale exists and/or if the awareness of the need for IT maturity is high – these conditions are rare in India. Even globally, formalized internal SLAs are more important to the very large enterprise than any other kind of company (this does not include service providers of all kinds, because SLAs are the core of their business).
When defining an SLA with a service provider, what are the key parameters to be specified?

That really depends on the provided service. Any infrastructure management (including outsourced help desk) sort of service would have SLAs that cover incident response time (including tasks such as adds, moves and changes), mean time to repair, availability (such as network and email availability) and how these variables trend over time. A lot of work usually gets done before parties can agree about defining the right metric and context for each (such as, which event would define incident closure?), segmenting types of events (based on severity), periodicity of monitoring, data collection and aggregation procedure, rules defining penalties and the escalation procedure.

When the service involves application hosting, SLAs would be related to uptime (availability), which is qualified by factors such as the number of concurrent users to be expected. Performance is a little more difficult to define. Ideally, performance should be measured in terms of end-user experience, but sometimes measuring end-user experience involves hard-to-scale tasks such as installing agents on end users' desktops, and with the growth of mobile users, it's hard to control the endpoint and the network, complicating matters.
What are the aspects to keep in mind when it comes to managing an SLA?

SLAs are not substitutes for a good partner relationship and governance procedures. Therefore, a broader management scope would still be necessary. Inordinate effort to make the SLA absolutely watertight isn't necessary, particularly when the internal IT organization involved. Select the SLA that best represents the end user's actual experience, while being realistic about what the expectations should be. So, application availability makes much more sense than server uptime does.

It needs to be appreciated that SLAs can be met only under certain given conditions – for example, if the average user's Web experience is to remain above the threshold, strong URL filtering is required to ensure that Web usage is in accordance with policy, and requests for exceptions should be carefully managed. At a high level, there isn't much that is arguable about the right SLAs. However, collecting and aggregating metrics is usually quite tough. Data typically resides in multiple databases, infrastructure management systems and possibly multiple service desk solutions. Building connectors to these data sources, aggregating them and developing dashboards for reporting are all resource-intensive tasks.

Tools don't do much here – the professional services' costs typically equal the average SLA management tool's licensing costs (a 1-to-1 ratio). Hiring an expert who is familiar with the metrics that work in terms of securing buy-in (and truly representing the business' interests) and hiring the IT talent to build the data connectors is much more important than any tool-related considerations.
How can IT teams leverage the various features offered by SLA management tools?

SLA management tool vendors offer value in multiple ways. First of all, they know which metrics to select. They also know where to look for data necessary to build metrics that IT and business would monitor as part of the SLA.

Vendors have the necessary tool knowledge to build connectors to the data. They also provide mechanisms such as rules engines that ease the process of aggregating the data to build metrics to be monitored. Dashboards are usually provided to aggregate and present the metrics in an automated way, which provide automated alerting services, analytics, etc., and in effect, create a single system of records that everybody can agree on. So, it's less about tool features and more about competence that the SLA management tool provider brings to the table.
Somak Roy, managing analyst at Butler Group, Datamonitor India, gives his views on service-level agreement (SLA) management.

Was there debate within PeopleSoft that it might be a bit shortsighted not to give steady-as-you-go maintenance?

Other than from me? You had development lining up on the side of, 'Absolutely hold to these support polices.' The consulting group wants to sell upgrade services. The development organization only wants to support a limited number of product lines, and there are practical reasons for that. They can't technically support 10 lines forever. In general, they were just incensed it accreted life to releases that they wanted to see retired.
Isn't this a problem for all software?

Everyone has to carry forward their baggage, and a backwards compatibility. Very rarely do you come out with a brand new release that has no connection, in technology, to what you had before, because then you open up the whole competitive realm. 'Well, hell, if your new product isn't really an upgrade, it's a migration, then I might as well look at everybody's else's if I am going to move to a migration.'
How have companies managed this problem before your software maintenance businesses existed?

They thought they could basically use the stick to beat customers forward by threatening them. You've seen that with Oracle. Siebel is the same way -- basically, if you don't upgrade, we're going to pull your support, you'll rue the day, you'll get nothing from us, and we'll still charge you the full amount.
What are the reasons your customers opt for third-party software maintenance?

They do it for different reasons. The small customers were making the move, because it was right after the dot-com meltdown. Prior to that, people were very optimistic, thinking they would be growing 10 times their size. They went in and bought PeopleSoft; it was the Rolls-Royce of HR systems and finance. So now they're stuck with the Rolls-Royce. They love it; they don't want to get rid of it. But they can't afford to keep it. So, a lot of those people, by switching to third-party maintenance, actually were able to keep the software they loved at price points they could afford.
Why did you leave TomorrowNow after the acquisition by SAP?

I left three months after the SAP acquisition; as an entrepreneur I needed to be on to my next thing. I actually was going to go build a software company, but after looking at it, I couldn't stay away from the maintenance stream. When you've got a 90% profit margin, it's just too hard to resist. And TomorrowNow didn't even take 1% of the market. As soon as Oracle announced its acquisition of Siebel, I decided to launch Rimini Street and offer the first third-party alternative into Siebel space.
Oracle must love you, especially given its suit against SAP -- targeted at TomorrowNow.

Oh yeah. I announced Rimini Street at OracleWorld 2005 and I think the words were, 'He's back.' As soon as my noncompetes expired with PeopleSoft and J.D. Edwards products, we introduced those at Rimini Street, too. So now you have two companies -- the captured, SAP-TomorrowNow and our independent Rimini Street -- and we are the only two really credible companies in the industry.
The Oracle lawsuit against TomorrowNow is notable for its strong language -- "corporate theft on a grand scale." Some analysts said that one of the aims of the lawsuit was to scare companies off using third-party maintenance.

Just to give you that color from the lawsuit -- it hasn't deterred the business. The lawsuit actually opened up business -- because some people didn't even know there was a choice. A lot of people read the lawsuit and said, 'My God, Merck and Honeywell, and all these large companies using third-party support.' And instead of saying, 'Wow, look what happened here!' The issue really is, 'Holy gee, am I the only guy paying full price?'
What about maintenance of SAP software at Rimini?

I have a noncompete that expires in January. Let's just say, we're looking with interest at the SAP market. With 30,000 customers, who wouldn't be? They recognize what is good for the goose is good for the gander. You can't complain and say you want Oracle to open up and allow third parties more access and think that is not going to boomerang back on you. They know this is about open access.
AMR analyst Jim Shepherd makes the argument that because everything is changing -- the software platform, the underlying components, your company's business -- that the software needs to be continuously updated.

That's not what we're hearing from clients. They have incredibly stable platforms that they feel like they can run their business on for 10 years. And, in fact, if you look at the recent enhancements from the PeopleSoft product line, it is akin to heated and cooling cup holders -- they're really cool, but it doesn't help me pay my employee any faster.
Who do you go to when you make your pitch? The CEO, the CIO -- who is most receptive to your message?

It's gotta be the CIO and the CFO. The reason is, this is a lot like outsourcing. You're not going to go pitch the IT team how great it is to send your jobs to Infosys. When we come in, how much excitement is there to tell a team, 'Hey, we've got some great news for you -- you guys are going to drive the same car for the next five to seven years instead of that new one you were hoping to play with.' A lot of IT folks do want the excitement of getting new tools and new technology to play with -- and that is part of the fun of it.

Our decision is very much a cost-driven decision, so it is very often the CFO or the CIO who says, 'I'm the guy who has to go before the board and justify we need to spend $2 million on an upgrade when we did it just three years ago, and I can't put down on paper how that money is going to be returned to us in benefits.'

What about people who have just upgraded to the newest version of software -- are they off-limits?

We used to work primarily with more retired or retiring-level versions of the software. Today, 30% to 40% of our business is on the latest versions of the software, so it is people who literally go and do the next upgrade and say, 'You know what, we are done for the next decade. And all that money we bank over the next decade? We will then do a capital expense because a whole new version of software is coming.' In 2015, '17, as late as 2018, you'll see a mature Fusion product against a mature NetWeaver product from SAP, hell Microsoft will probably be offering a full enterprise-level product at the rate they are investing. Rather than play the upgrade game every two or three years that doesn't necessarily yield results but ties up the entire IT team, costs a fortune, instead we're going to make a generational change.
How long should a company hold on to a software product?

We have more customers than ever looking for five- and 10-year guarantees for support. No one makes this change for a six-month change; it is not worth it.

Let us know what you think about the story; email: Linda Tucci, Senior News Writer

It doesn't take much to get Seth Ravin badmouthing big software companies. Ravin co-founded TomorrowNow, which he sold to SAP, and eventually went on to found Rimini Street Inc., an independent provider of enterprise software support services for Siebel Systems Inc., PeopleSoft Inc. and J.D. Edwards & Co. licensees. The companies share the same aim: make software last longer. Ravin's idea of software maintenance evolved from his work at PeopleSoft in the late 1990s. He was in charge of getting 4,000-plus customers through Y2K. The board authorized Ravin to quietly sell customers a Y2K package of support -- on top of their regular maintenance support -- so they could stay on their older releases.

Indeed, as word of the special program spread, enthusiasm reached fever pitch. By 1999, Ravin had customers left and right willing to pay him more than regular maintenance fees, so they wouldn't have to upgrade. Not long after, he left PeopleSoft to join former colleague Andrew Nelson, who had a little consulting business, TomorrowNow.

Why did you decide to add the CIO track to this year's show?

Instead of just having the vendors up there, talking about their strategies in a vacuum, when we involve the CIOs, we are able to add some reality into the mix.

They are able to give feedback, saying 'You know what? That iteration of a dual-license model really wouldn't work in our case and here's why,' or 'The reason why we're not using open source applications is x, y and z, but if you solved those problems, then we would be happy to buy them.' So it made the conversation that much richer.
Are there companies that just shouldn't use open source?

It depends. For example, if the company has Windows running everywhere and wants to use Microsoft SharePoint, it probably wouldn't make much sense given how SharePoint integrates with [Internet Authentication Service], with their database, with the range of things Microsoft offers. It probably wouldn't make much sense for them to go out and find an open source content management system like Mambo or some other alternative. But for companies that have a mixed environment, then absolutely, open source should appeal to them. Generally speaking, I think the answer is that open source does measure up and they should at least give it a look. The great thing about open source is that you can try [it] before you buy [it] and if it proves to be weak or not fitting for the company's needs, delete it and no money [is] lost. Time lost, but no money lost.
Should SMBs do things differently than enterprises?

I think they should look at open source differently, definitely, because a company like Fidelity [Investments], which has a $2 billion a year IT budget, can obviously afford to tweak the code if they need to or play around with open source in a more experimental fashion. SMB buyers need to look at companies like SpikeSource and others that take a lot of the complexity out of using open source. I definitely think that they need to be looking for an integrator or an [enterprise application integration]-type vendor to make the open source adoption curve much easier for them.
Is there a major trend that you wanted to make sure was included in this year's show?

It was four years ago when we saw the rise of the first wave of open source at the operating system level. A few years later, we're now in the middle of the second wave of middleware infrastructure; databases with MySQL and JBoss proving themselves and doing quite well financially.

We are now on the cusp of the third wave and this is probably the biggest trend that'll be covered at this year's event, and that is the rise of open source applications. What's interesting about this third wave is we're no longer in the realm of successful open source projects that grow up to be enterprises, like Red Hat and Novell. Instead, what we're having is commercial entities, from the beginning, creating excellent code and choosing to release it as open source. It's just changing the way enterprises think about software and think about buying software, and I think that's a huge trend that will just continue and affect every single vendor in the world. There just won't be any vendor that can withstand the pricing and distribution pressure that open source will have going forward.
So you're talking about these waves. What does the future of open source look like?

I think [the third wave] is going to be the big trend for the next five years. I think it's going to be the next five years at least as we see these new Bohemians and as we watch large established vendors try to turn their ships around and become like more open source companies. That's not to say that Oracle is going to open up its code tomorrow. All of this has little to do with source code itself and more to do with the idea of pricing on a subscription basis, and having a lower cost structure and distributing through the Internet rather with big, direct sales forces.
What are three things that every CIO should be able to tell their CEO or CFO about open source?

I think they should be able to intelligently talk through real legal risks and opportunities around open source.

I think they need to be able to address TCO. It's shocking. Forrester [Research] did a report on TCO studies and found that most enterprises don't actually have any clear idea of how much any of their software costs them. They don't have the ability to compare what open source would cost them vis-À-vis their closed source counterparts because they don't really know what their close sourced counterparts are currently costing them in terms of manpower, etc. So I think the other thing that they need to be able to intelligently discuss is personalized TCO for their enterprise, have a grip on how much it actually costs them to deploy the software they have now.

The third thing would be migration costs. What would it cost to move from what they're currently on? As open source becomes more and more of an issue that the Wall Street Journal and The New York Times, etc., cover, the CIO needs to be able to answer the TCO and legal issues that surround it. [Because] the CEO is going to be reading about it all the time, going back to the CIO asking, 'Hey, I've heard about this. It looks big, JP Morgan is behind it, Putnam [Investments] is behind it, what are we doing with it and why aren't we doing more?'

For more information on OSBC and this year's show, visit their Web site.

This year's Open Source Business Conference (OSBC), being held in Boston next month, is different from past years in that there is now a track for CIOs. Why? According to Matt Asay, conference director and director of Novell's Linux Business Office and Open Source Review Board, it's because open source has arrived -- in the executive suites. Asay recently took some time to discuss with SearchCIO.com what CIOs should know about open source.

CIO and vice president of strategic planning at Headwaters Inc., talks about his misfires and direct hits when he develops new services for the business -- talking to...

modules that were not in my near-term planning horizon. Third, I did not need to take advantage of quarter-end pricing to get the desired discounts. Once, I missed my...