Question: How do you execute a complete rewrite of the worlds leading reporting tool to ensure it's viable for another 20 years?
Answer: Very carefully.
The Crystal Reports codebase has proven to be very reliable and valuable to our customers over the last 19 years since we released version 1. I'm sure there's code in there today that was first released in that original version back in 1992 for 16-bit Windows.
However this is software, and development standards evolve, get better, and help developers be more productive. Products stuck on older code bases cannot keep up with new entrants on more modern and productive code bases. These products simply fade away as they fail to keep up with the rate of innovation that's possible with more modern development standards.
We are determined not to let that happen with SAP Crystal Reports.
The 'Small Ball' Strategy
So over the last 7 years, we've been effectively building 2 versions of SAP Crystal Reports - the C++ stack with all the bells and whistles that's sold to our valued customers, while investing in our 'next gen' stack. We used a strategy I called 'small-ball' - in reference to how baseball teams can be effective using singles, stolen bases, and bunts. We wanted to avoid a risky big-bang migration where we might get something to market early, but spend the next 3 years issuing service packs to address issues instead of innovating.
With small-ball, we used smaller releases like SAP Crystal Reports for Eclipse and the Crystal Reports Viewer to validate our engineering, learn from real-world experience, and always move forward toward that goal of bringing next generation Crystal Reports to market.
Now that our next gen product (SAP Crystal Reports for enterprise) is surfacing publically on blogs and in products like BI 4.0, I thought it was time to share some of the interesting roadmap decisions that have happened behind the scenes.
The Evolution of Next-Gen Crystal Reports
The next-gen stack is based on Java, and got its start in 2004 with the Java Runtime Component (JRC) that was part of version 10. At that time, it was a simple runtime engine to execute reports authored with CR 10.
In 2006 we built on that base and created Crystal Reports for Eclipse 1.0. This took the JRC and added a basic report design tool. It was this release where we adopted the SWT programming model in Eclipse for our next get stack, and the fabulous Eclipse plugin architecture. We got the confidence that we could efficiently build a report designer using this technology.
In 2008 we delivered CR for Eclipse 2.0, adding editable preview. We also delivered the Crystal Reports Viewer as a free download. This was a key milestone as we got confidence that we can render RPT files just as accurately in the next gen stack as we do in the C++ stack. We used these products to improve the performance and compatibility aspects of the next gen stack.
SAP Crystal Reports in SAP BusinessObjects BI 4.0
Finally we had the confidence in the next gen stack that we could make the jump to our paying products. In the design stage of the BI 4.0 release, we knew that the jump from CR for Eclipse 2.0 to a product that does everything that CR 2008 does for both the volume and enteprise market was too big. So we focused on the needs of Enterprise customers because we have a better ability to service them through our maintenance offerings. Plus there's a natural way to narrow the scope of the release if we're going to focus on enterprise-only solutions. We'd limit data access in the BI 4.0 release to Universes only. This would allow our developers to focus on creating great Universe based data access and correcting a longstanding weakness in Crystal Reports. Direct to data access would not be going away - we'd still have Crystal Reports 2011 for that, plus we'd plan to restore it on the next gen stack in a point release.
Along the way we got important validation of our early design choice of SWT/Eclipse as the platform for our next gen stack, as the new Information Design Tool (for editing next gen Universes) also adopted the same architecture.
Now that BI 4.0 is done (from a development perspective - it's still in rampup as I write this), we can look ahead to 4.1 and 4.2 where we will be addressing the compromises we had to make in 4.0. In these forthcoing point releases, we'll be building direct to data access, public APIs, and creating a scalable runtime engine solution that will allow for deployments outside of the BI Platform 4.x.
If you're a volume customer (ie... purchase through resellers or our eStore) and looking at CR 2011 you're probably a bit disappointed that there isn't more. The reason isn't because we don't place a priority on volume customers - it's actually the opposite.
The volume market is the most demanding market there is. Volume customers expect great, intuitive usability, APIs, and fast component runtime deployments without having to go through a big enterprise sales cycle, or pay for annual maintenance. In the volume business, there isn't a small army of friendly account executives and solutions consultants to talk through product issues. The product must work the first time. Its for these reasons that we're starting this rollout with server software that's commonly used by larger customers.
The 4.x platform will be the platform of continuous innovation of the next gen stack. Major features will be added with each point release, and we will deliver next gen technology to the volume market using this 4.x platform as a foundation. Initially, customers of the BI Platform 4.0, Edge BI 4.0, and SAP Crystal Server 2011 will have access to the next gen report design tool - called 'Crystal Reports for enterprise'.
If you want a taste of the innovation this modernization will provide, check out this great video by our user experience team on the Smart Guidelines feature in the next gen design tool.
I know that things look a little weird right now - with 2 Crystal Reports products in the 4.0 stack - one called SAP Crystal Reports 2011 and the next gen product called SAP Crystal Reports for enteprise. Be assured this is a temporary situation.
Once we've met the key volume requirements to the next gen tool - like direct to data access, a component runtime engine, and an API - we plan to release next gen Crystal Reports to all our channels and direct 100% of our efforts to innovating on this modern platform for your benefit. We expect that this release will include an extended beta program to ensure its success.
Once it's GA, we'll then revert to using the next-gen stack as the single version of Crystal Reports for simplicity and clarity. Whether next-gen Crystal Reports is Crystal Reports 2012 or 2013, I can't say for sure now.
If we can execute on this (and I have no doubt that we can), we'll have pulled off a rare feat in software - renewing the underlying technology of a market leading product, so we're not just the oldest and best known reporting tool, but also the most modern and innovative.