A big part of my research agenda for this year is productization. Many app dev teams see productization as a way to innovate better, achieve more sustainable results at a lower cost, deal with some of the tough challenges downstream, and in general lead a happier and more productive life. The allure of productization varies across different types of organization, as do the approaches. Therefore, to do the product justice, we're going to look at five different settings in which app dev teams are striving to productize their work:
Companies that have customer-facing applications on their websites. The classic example is online banking, but there are plenty of others. Some of these applications are tools for existing customers, while others are mechanisms for interactive marketing.
IT departments. In this case, productization is a way to improve the long-term return on technology investments, by treating them as products and assigning them a product owner.
Services companies. Productization may reduce inefficiencies in developing and delivering offerings, as well as marketing and selling them.
Embedded software. The ubiquity of software as a component of a larger product (car, medical device, etc.) creates new challenges in defining what the product is, and where software development fits into it. That's one reason why PTC, a product lifecycle management (PLM) vendor, was interested in acquiring MKS. (Other than their shared interest in TLAs.)
SAP BusinessObjects (BO) 4.0 suite is here. It’s been in the ramp-up phase since last fall; according to our sources, SAP plans to announce its general availability sometime in May, possibly at Sapphire. It’s about a year late (SAP first told Forrester that it planned to roll it out in the spring of 2010, so I wanted to include it in the latest edition of the Forrester Wave™ for enterprise BI platforms but couldn’t), and the big question is: Was it worth the wait? In my humble opinion, yes, it was! Here are seven major reasons to upgrade or to consider SAP BI if you haven’t done so before:
BO Universe (semantic layer) can now be sourced from multiple databases, overcoming a major obstacle of previous versions.
Universe can now access MOLAP (cubes from Microsoft Analysis Services, Essbase, Mondrian, etc.) data sources directly via MDX without having to “flatten them out” first. In prior versions, Universe could only access SQL sources.
There’s now a more common look and feel to individual BI products, including Crystal, WebI, Explorer, and Analysis (former BEx). This is another step in the right direction to unify SAP BI products, but it’s still not a complete solution. It will be a while before all SAP BI products are fully and seamlessly integrated, as well as other BI tools/platforms that grew more organically.
All SAP BI tools, including Xcelsius (Dashboards in 4.0), that did not have access to BO Universe now do.
There’s now a tighter integration with BW via direct exposure of BW metadata (BEx queries and InfoProviders) to all BO tools.
In the midst of all the buzz in the CRM space about “social” and “mobile” CRM spotlighted in my recent reports, I am observing another important trend. There is a convergence of customer relationship management (CRM) and business process management suite (BPMS) solutions to support better customer experiences and deeper customer engagement.
Our research shows that only 10% of companies deliver outstanding customer experiences. The laggards have a choice: They can either continue to whistle while passing the graveyard, or make a bold, sweeping stroke by focusing on deeper engagement with their customers. How? By taking a hard look at business processes that traverse organizational silos, bringing the back office closer to the front office while transforming strategic cross-functional processes.
Customer service managers in particular struggle to balance customer experience and cost: siloed communication channels, impersonal service, and an inability to enforce company processes or meet regulatory compliance negatively affect satisfaction and increase costs.
To resolve this dilemma, there is continued interest in traditional “record-centric” CRM solutions, but I also see more adoption of “process-centric” BPMS solutions. In fact, the characteristics of these two are converging in the latest releases from the respective vendors.
Traditional application servers such as WebSphere, WebLogic, and JBoss are dinosaurs tiptoeing through a meteor storm. Sure, IBM, Oracle, and Red Hat still have growing revenue in these brands, but the smart money should look for better ways to develop, deploy, and manage apps. The reason: cloud computing.
The availability of elastic cloud infrastructure means that you can conserve capital by avoiding huge hardware investments, deploy applications faster, and pay for only those infrastructure resources you need at a given time. Sound good? Yes. Of course there are myriad problems such as security and availability concerns (especially with the recent Amazon mishap) and others. The problem I want to discuss is that of application elasticity. Forrester defines application elasticity as:
The ability of an application to automatically adjust the infrastructure resources it uses to accommodate varied workloads and priorities while maintaining availability and performance.
There’s a huge graveyard of failed customer service software implementations, and still others are on life support due to the basic fact that they are not usable. Think of the world we live in, with products and services from Amazon, Apple, Google, Facebook, and the like:
Intuitive user interfaces that don’t require training to be able to use them
Predictive type-ahead where suggested topics are displayed in a dropdown menu to help users autocomplete their search terms
Aggregation of content from different sources, all linked together so that it adds value to the user
Cloud computing will bring demand for elastic application platforms.
Promises that cloud computing can save money and reduce time-to-market by automatically scaling applications (either up or down) oversimplify what it takes to develop application architectures to achieve these benefits of elastic scaling. Few of today's business applications are designed for elastic scaling, and most of those few involve complex coding unfamiliar to most enterprise developers. A new generation of application platforms for elastic applications is arriving to help remove this barrier to realizing cloud's benefits. Elastic application platforms (EAPs) will reduce the art of elastic architectures to the science of a platform.
EAPs provide tools, frameworks, and services that automate many of the more complex aspects of elasticity. These include all the runtime services needed to manage elastic applications, full instrumentation for monitoring workloads and maintaining agreed-upon service levels, cloud provisioning, and, as appropriate, metering and billing systems. EAPs will make it normal for enterprise developers to deliver elastic applications — something that is decidedly not the norm today.
Forrester defines an elastic application platform as:
An application platform that automates elasticity of application transactions, services, and data, delivering high availability and performance using elastic resources.
We see organizations moving toward EAPs by extending their current web architectures, following one or more of four paths:
A new business model is emerging, and it depends heavily on software development. Many companies are dropping many of the traditional barriers between product development and customers. Without investing in software development, these efforts, no matter how well-intentioned, will have a better chance of failing than succeeding.
The simplest term I can concoct for this business model is "the transparent company." There are other defining characteristics of this corporate strategy, such as confidence in the ability to execute, and a very different sort of relationship with customers. However, as companies have been decidedly opaque to their customers, any transparency is a striking detail in itself. Hence the term "transparent company."
Wave Hello To The Engineer Fixing Your Bug
Here's an example of what I mean. I don't have to be a customer of Atlassian to know what issues Atlassian's engineers will fix in the next release of their wiki product, Confluence. That information is publicly available at this link. Diving into an issue at random — I chose "Database deadlock during initialisation of plugins in sql server" because it sounded fairly dire — I can see which engineer is working on this issue, Don Willis. I can even see the daily activity stream for Don Willis as he works on this issue and other projects.
It wasn’t that long ago that packaged apps ruled the application delivery landscape and custom development was decidedly the second choice. Today, the decision is not so cut and dried, as firms struggle to find the right balance between the quick time-to-market of packages and the competitive distinction custom development can create. In the midst of this shift, a new option — rent (SaaS) — is gaining traction. Most enterprises already support a mix of packaged and custom applications — but with fast adaptation, customer experience, and process integration the top priority for most enterprises, do firms need a different mix of custom, packaged, and SaaS apps to maximize customer value?
Next month at Forrester’s IT Forum in Las Vegas, a panel of experts will debate the pros and cons of custom-developed applications and packaged applications in our Application Development & Delivery track. Attendees will have a chance to vote on the future of applications. But we decided the debate was too juicy to sit on it for another month. So, on April 25, from 2 to 3 p.m. ET, Forrester will host a Tweet Jam — using the hashtag #ITF11 — to answer the question:
“Which is better at delivering customer value: packaged or custom applications? Why?”
We asked our panelists to get the discussion started, and here is what they had to say:
I am not talking about The Donald here, thankfully. I am talking about how fervently impatient users are when it comes to website and mobile app response time. You can design a brilliant, luxurious, and intuitively interactive user experience, but if it doesn't perform well — as in response time — then the users will hate it. They don't want to wait. Why should they? They will just go somewhere else. Your job is to design and implement user experiences that are lovable and that performance spectacularly.
Application Performance Management Starts During UX Design
Forrester defines performance as:
The speed with which an application performs a function that meets business requirements and user expectations.
To insure speedy application performance, organizations should start application performance management (APM) during the application design process. Too few user experience (UX) designers understand the performance implications of their designs. But, application architects must also help UX design professionals by finding clever ways to:
The lines are blurring between software and services — with the rise of cloud computing, that trend has accelerated faster than ever. But customers aren’t just looking at cloud business models, such as software-as-a-service (SaaS), when they want more flexibility in the way they license and use software. While in 2008 upfront perpetual software licenses (capex) made up more than 80% of a company’s software license spending, this percentage will drop to about 70% in 2011. The other 30% will consist of different, more flexible licensing models, including financing, subscription services, dynamic pricing, risk sharing, or used license models.
Forrester is currently digging deeper into the different software licensing models, their current status in the market, as well as their benefits and challenges. We kindly ask companies that are selling software and/or software related services to participate in our ~20-minute Online Forrester Research Software Licensing Survey, letting us know about current and future licensing strategies. Of course, all answers are optional and will be kept strictly confidential. We will only use anonymous, aggregated data in our upcoming research report, and interested participants can get a consolidated upfront summary of the survey results if they chose to enter an optional email address in the survey.