Inside the BPA Group at Forrester, we conducted a little experiment. I suggested that we should collaborate on a piece about the Pega acquisition of Chordiant. What followed was a large number of email exchanges. I drew the short straw in bringing all these thoughts together into a coherent whole. I prepared a document for Forrester clients to explore the acquisition in detail (probably getting through the editing process next week some time), and this blog post is culled from that document. So while the blog post bears my name, it reflects the collective opinions of Connie Moore, Bill Band, Natalie Petouhoff, John Rymer, Clay Richardson, Craig Le Claire and James Kobielus. Of course, I have put my own interpretation on it too.
Pega definitely wants to be in the customer experience/customer service business, and they want to get there by having a very strong BPM offering. It is not that they are moving away from BPM in favor of Customer Experience – they’re just strengthening their hand in CRM (or CPM as they would call it), more forcefully making the connection. We already knew this, but the Chordiant deal just reinforced that point (see related research doc from Bill Band in 2005 !!). This is not a new direction or change in direction for Pega, it is a strong move that takes them faster in the direction they were already going.
From a product point of view, Pega are adding/strengthening their hand – Choridant’s marketing automation and predictive analytics seem to be of greatest interest. Of course, Pega also values the engineering talent that Chordiant has, and will redirect those people over time to work on integrating these capabilities into the BPM offering. They were also interested in the vertical industry and functional expertise that Chordiant had to offer.
CIO job tenure is now averaging 4.6 years, according to the Society for Information Management. That’s up – way up -- from the 2-3 year average that we saw just a few years ago. How do you explain the lengthening time in job? Is it just because CIOs are better at their jobs than CEOs or CFOs who have higher churn rates? Probably not.
My guess is that the post dot-com bust and post 9/11 recession triggered CIOs to hunker down and be a bit more risk-adverse. They stayed put for a few years, then facing the more recent economic slump, stayed put even longer. They stayed busy doing what they unfortunately are known for -- helping with enterprise cost cutting. More reactive, more cost conscious, and less innovative CIOs are less likely to take risks and less likely to be fired for risk-taking.
But I suspect the trend towards longer tenure is rapidly coming to an end. The CIOs I speak with are eagerly waking up to tackle innovation and new investments in 2010. And we’re seeing more and more ex-consultant hot shots and business execs from elsewhere in the company recently hired on to “fix IT” join the CIO ranks. More proactive, innovative, and impactful CIOs are more likely to follow ambitious career paths – or (if your a glass-half-empty kind of guy or girl) get fired for risk-taking.
Microsoft announced on Friday that it will stop selling new Select licenses from 1 July, 2011. Customers with existing agreements can renew them for another 36 months, as per their agreements, but the replacement Select Plus program is likely to be a better option. Microsoft launched Select Plus on 1 July 2008, and I wrote at the time that it was an improvement on the basic Select structure: Microsoft Simplifies Its Volume Licensing.
However, Microsoft's pricing team struggled to persuade its LARs to promote Select Plus over the more familiar Select agreement, and customer adoption was disappointing. So the decision to drop the older program makes sense for Microsoft, because it will force its channel partners to embrace the new model. And its no bad thing for buyers - you've one less choice to make, and there's little negative impact.
The biggest advantage of Select Plus for sourcing managers is that they no longer need to submit a three-year spending forecast - this is extremely difficult for central teams buying on behalf of autonomous business units that won't havent planned Microsoft technology adoption that far out. Instead, pricing works like an airline loyalty program, on the current and previous years' actual transactions, as the figure below from my report illustrates. My report explains some more advantages, such as the flexibility to opt tactically for software assurance on individual purchases.
Hopefully you’ve all read SAP’s co-CEO’s open letter to you (http://ceos.blogs-sap.com), and also some of the great responses such as this one: http://bit.ly/b5foPD . With all these open letters flying around, I thought I’d write a slightly different one. Unlike most of my fellow commentators, I’m not going to tell SAP how to run its business. Instead, I’m going to give you, its customers, a suggestion on how you can cut the cost of your SAP environment. You ready? The answer is “buy less stuff from them”.
Actually, it is not as facile as it sounds. Many companies that I speak with automatically favour their incumbent vendors for new projects, while their IT vendor managers complain to me about their negotiation impotence. You won’t be able to get the contractual protection you need, such as limits on CPI maintenance increases, unless you make them a condition of future purchases. Large software companies such as IBM, Oracle and SAP focus predominantly on license sales. It wasn’t customers’ unhappiness, resulting from the Enterprise Support blunder, that caused SAP to fire its CEO and rethink its approach. It was the fact that you showed that unhappiness by voting with your purchase orders, delaying projects, going to competing vendors, and causing SAP’s license revenue to plummet. When Jim and Bill promise to “accelerate the pace of the innovation we deliver to you”, the d word is a euphemism for ‘sell’.
The SAP services market is undergoing significant change: provider consolidation, changes in pricing models, new delivery options, and cloud-based deployment. At the same time, firms are entering 2010 with an eye to growth and business strategy enablement, after significant focus on cost-cutting during the recession. Firms struggle with finding the best services provider for their SAP project and the best delivery, pricing, and deployment models to ensure value, ROI, and success in achieving business goals,. Increasingly, firms are also considering Cloud and SaaS delivery models.
SAP users wondering about the latest trends in SAP services – from pricing models to multi-sourcing to cloud – are welcome to join us for an interactive session next Thursday March 25th. Moderated by Forrester’s George Lawrie, Bill Martorelli, Euan Davis, Stefan Ried and I will lead an interactive discussion around:
- SAP services provider landscape. The market has undergone significant consolidation, with major acquisitions by firms like PwC (BearingPoint), Xerox(ACS), and Dell(Perot) as well as numerous smaller acquisitions. Leading India-based firms have rapidly built their strategy consulting capabilities and now challenge the MNCs in higher value project work.
- Offshore delivery. Offshore ratios have grown extremely high. Implementation and project work is commonly 60% or more offshore; support and maintenance work surpasses 90%. Firms’ offshore strategy is broadening beyond India into geographies such as Latin America, China, and Philippines.
- Outsourcing and AMS work. Firms weigh the trade-offs between single-sourcing their project across implementation, AMS, and hosting versus using multiple providers. Firms also struggle with pricing models and SLAs, with many firms exploring outcome-based pricing models that shift risk to their provide. Outcome-based pricing also provides a potential foundation for innovation and savings beyond labor arbitrage.
Fast Access To Data Is The Primary Purpose Of Caching
Developers have always used data caching to improve application performance. (CPU registers are data caches!) The closer the data is to the application code, the faster the application will run because you avoid the access latency caused by disk and/or network. Local caching is fastest because you cache the data in the same memory as the code itself. Need to render a drop-down list faster? Read the list from the database once, and then cache it in a Java HashMap. Need to avoid the performance-sapping disk trashing of an SQL call to repeatedly render a personalized user’s Web page? Cache the user profile and the rendered page fragments in the user session.
Although local caching is fine for Web applications that run on one or two application servers, it is insufficient if any or all of the following conditions apply:
The data is too big to fit in the application server memory space.
Cached data is updated and shared by users across multiple application servers.
User requests, and therefore user sessions, are not bound to a particular application server.
Failover is required without data loss.
To overcome these scaling challenges, application architects often give up on caching and instead turn to the clustering features provided by relational database management systems (RDBMSes). The problem: It is often at the expense of performance and can be very costly to scale up. So, how can firms get improved performance along with scale and fault tolerance?
Elastic Caching Platforms Balance Performance With Scalability And Availability
In my recent interviews with IT services providers on the topic of innovation, one of the key findings was the many different ways in which innovation can be categorized. Some companies view innovation as simply an extension of their traditional R&D capabilities, others view their innovation as a way to prove their thought leadership, still others view innovation largely as a strategic marketing imperative. Sometimes, it’s a combination of these factors.
One interview that stood out was with Lem Lasher, the Chief Innovation Officer (and Global Business Services President) at CSC, who described to me a deep and holistic approach to transforming CSC’s innovation capabilities. Three things that stood out at me about Lem’s approach:
With Forrester’s new blogging platform in place, I have the opportunity to launch a series of blogs about tech economics. What do I mean by tech economics? To me, tech economics first means how the larger economy and the tech sector interact. I am interested both in how economic conditions impact the demand for technology goods and services and how business and government purchases of these tech goods and services affect the economy as a whole and the industries and firms in the economy. Second, tech economics is about the revenue of tech vendors, both what they are reporting in the present and past and what we expect those revenues will be based on future purchases by their business and government customers.
My published research on the US and global IT market outlook, industry, regional, and country IT purchase trends, big trends like Smart Computing, and the ePurchasing software market (which I also cover) will continue to be my platform for addressing tech economics. However, I want to use this blog to talk about four focused aspects of the tech market: 1) tech data sources; 2) tech industry definitions; 3) tech market developments; and 4) tech market dynamics. Let’s call these the 4Ds of tech economics, and each will have its own strand of comments and observations.
D1: Tech data sources will be of most use to the data geeks like me in tech vendors. These are folks who use my numbers in their own forecasts of the market for their firm and its products. These blogs will talk about the data sources that I use in building my tech market sizing and forecasts, issues and questions about these data sources, and how the data geeks can leverage them. I will share some (but not all!) of our secret sauce for our forecasts, and I hope you will share some of yours so we can all get better.
Sikka made two comments that indicate how he's thinking about the NetWeaver portfolio.
1. In response to my question about whether SAP is concerned that Oracle's ownership of Java will put it at a disadvantage, Sikka started by highlighting SAP's work on Java performance, but then noted the availability of good open-source Java software to support the requirements of SAP customers.