Wednesday, February 11, 2009

How to Choose Between Cognos and WebFOCUS?

A Google searcher from New Jersey arrived at my blog with the question, "What are the differences between Cognos and WebFOCUS?"

Perhaps a good way to begin answering his or her question is to look at the vendors' histories.

Cognos (which started as Quasar) and Information Builders (IBI), the software vendor of the WebFOCUS BI product, have similar origins in the 1970s and then, after a decade or two, experienced a major divergence from each other. Both began as providers of next-generation application development tools hoping to replace the common 3GLs, such as COBOL and PL/1.

Cognos' PowerHouse suite offered tools such as QUIZ for report writing, QUICK for screens, and QTP for batch transaction processing. IBI created the FOCUS language which had facilities similar to those found in Powerhouse, but they also included their own proprietary database structure.

Cognos focused their PowerHouse tools on the midrange market (HP3000, VAX, and AS/400) while IBI went after the mainframes and then expanded to almost every platform imaginable (Tandem and Wang included). IBI also invested heavily in building data adapters to access the various types of data structures.

In the 1980s both Cognos and IBI investigated the artificial intelligence (AI expert system) software market which did not materialize. In 1986, Cognos went public; IBI never did.

When Cognos and IBI tried to move their app dev products to the Wintel platform, they struggled. In the 1990s, both companies released app dev product enhancements to support the new Internet.

The major split between Cognos and IBI came late in the 20th century when Cognos started to make a break with its app dev past. Basically shedding its old PowerHouse midrange tools, Cognos focused instead on new end-user Business Intelligence products running on client-server architectures.

In the early 1990s, Cognos introduced Impromptu for report writing and PowerPlay and a multi-dimensional cube structure for OLAP (online analytical processing). Cognos recently has reworked their BI products for the web, releasing Cognos 8 with new browser-based Studio tools (Report Studio, Analysis Studio, Query Studio, and Metric Studio).

In 2000, Business Week magazine named Cognos one of the Top 100 IT companies in the world, standing right in line behind a different powerhouse -- Microsoft. Cognos grew by acquisitions, buying up vendors of complimentary BI products and applications. Their annual revenues skyrocketed to over $1 billion. In January of 2008, IBM acquired Cognos with plans to double that sales figure.

Bringing in about $300 million each year, IBI remains privately-held with the same owners. Even with a small organization, however, IBI provides top-notch technical support and consistently ranks high for customer service.

The WebFOCUS product, based on the FOCUS 4GL, is truly an enterprise BI tool, able to run on almost any platform and access virtually every data structure. In February of 2001, IBI split out the nuts and bolts of their underlying integration layer, offering it as a separate product under the name iWay Software. Reworking the valuable data adapters to be accessible by SQL (IBM's Structured Query Language) instead of the FOCUS 4GL, IBI created another source of revenue outside of their traditional BI customers.

The Cognos 8 Studios are easy-to-use browser-based tools designed for end users and developers of BI solutions. Providing easy front-ends, however, typically means that some hard work must be done on the back-end. A reporting repository of properly structured data along with multi-dimensional cubes is needed before the end users can start playing. Because of this, Cognos is best suited for an environment with relational data repositories running on a centralized server.

WebFOCUS, on the other hand, is more suited for IT technicians to use to build BI applications. The underlying 4GL has powerful tools for complex reporting and analysis. With WebFOCUS, developers can get "under-the-covers" and manipulate the source application logic, something not possible with most BI tools.

[2010 January comment: of course, Information Builders is working hard to provide easy end-user query and analysis features.  See their InfoAssist product.]

As an example, WebFOCUS developers can build row-oriented financial statements, multi-step logical processing, and highly dynamic self-building logic; you would not do this with Cognos. Unlike any other BI product, WebFOCUS can access data scattered across the enterprise on various platforms, pulling things together from different locations to be displayed in the same report output. You still have data locked away in IDMS, IMS, Total, VSAM, Datacom, NonStop SQL, or Model 204? No problem with WebFOCUS.

Those are technical differences. Another consideration is the availability of resources. If you search the Monster job board, you will see close to 900 postings for Cognos people and only about a dozen for WebFOCUS. Because of large differences in customer base and market demand, there are more experienced Cognos developers available.

Which BI product is right for you?

Well, if you have an end-user community needing to build their own reports and queries with minimal outside assistance, and you have an IT database team that could easily create a reporting repository, you should consider Cognos.

On the other hand, if you have a complex environment with several different platforms and databases, and you have an IT development staff that could easily create web applications, you would lean toward WebFOCUS.

Good centralized reporting repository, go with Cognos. Lots of disparate data and some available application developers, go with WebFOCUS.

[An interesting development occurred in January 2010, when IBM began selling WebFOCUS as a web-based BI product for System z DB2 data warehouses.  Why would IBM choose WebFOCUS instead of their own IBM Cognos product which also runs on the z platform?  See more information here.]

Of course, I have given a simplistic answer to a complicated question. If you want to talk in more detail, contact me.

Monday, February 9, 2009

Business Intelligence and Finance

Carl Weinschenk is addressing Business Intelligence topics from the viewpoint of those in Finance. You can get on-demand access to his printed material and podcasts at "The IT-Finance Connection" website or have information delivered to you by registering for his bi-weekly newsletters.

As an example of his IT-Finance topics, see the podcast of Gordon Burnes, the VP of Marketing for OpenPages, explaining why the current financial crisis provides good reason for adding a BI layer to your risk management and compliance systems.

Click here to visit The IT-Finance Connection.

Sunday, February 8, 2009

Why Use Reporting Repositories for Business Intelligence?

I regularly review web statistics with interest to see how Google searches route people to my blog. One person from Indiana came looking for reasons why you should use a data mart. The searcher was probably disappointed since the answer was not really there as advertised. I feel bad, so let me fix that and add some content -- perhaps he or she will return.

Rather than use industry business intelligence terms pregnant with political meaning like Data Warehousing and Data Marts, I am using "Reporting Repository," which I hope is free from bias.

While there are proponents for doing reporting directly against the operational systems' data (see another blog for some information), it is generally speaking just not a good idea. The main argument is that operational data has live, real-time information. But there is a long list of disadvantages.

Instead of using operational data for reporting purposes, you should provide your end users with a centralized, shared copy created especially for BI: a Reporting Repository.

With this term, I mean that the operational and external data feeds have been restructured and stored in a way to make end-user reporting as simple and easy as possible. In addition to changing the data structure, the organization has added an abstract layer (master data management, hierarchies, and so forth) as well as a metadata layer.

A team of technical specialists must bear the burden of understanding the complex data one time while creating the reporting repository and the necessary integration processes. Otherwise, the end users are yoked everyday with the burden of trying to write reports against the complex operational data (which is not meant for reporting).

Here are some reasons you should not use operational data for your end-user reporting:
  • Because of critical nature, operational system must be isolated and protected
  • Data is structured for ease of data maintenance, not reporting
  • Since not designed for end-user reporting, there is rarely documentation for doing that
  • Typically, operational system does not physically store all data (uses business rules inside application code)
  • Typically, operational system does not store historical data (only a snapshot of current situation)
  • Typically, operational system does not have an abstract layer for end-user reporting
  • Typically, operational system does not have a metadata layer for end-user reporting
  • Typically, operational data not accessible by common BI tools

Reporting Repositories provide a corresponding solution to each of those operational data problems:
  • Intentionally designed for access with considerations for security, performance, etc.
  • Data is structured for ease of reporting
  • Intentionally designed and documented for end-user user
  • Either physically stores calculated columns or exposes virtual columns
  • Captures historical information for auditing, comparisons, trending
  • Provides abstract layer to provide context for understanding information
  • Provides metadata layer to provide explanations for accessing and using information
  • Designed to be accessed by BI tools

But what are you going to put in your Reporting Repository? Well, you will figure out the design and content based on the needs of your business decision makers. If you want to build an enterprise repository to serve any and all reporting purposes, you are looking at a Data Warehouse (Bill Inmon approach). If you go with a very specific repository for a unique purpose, you are considering the Data Mart (Ralph Kimball).

Here are the steps for designing your Reporting Repository:
  • Your decision maker needs to take important business action
  • Which requires specific information.
  • Decision maker also needs specific method of interacting with the information (information delivery or interactive, on-demand access)
  • Which determines the proper storage of information in the repository
  • Which determines the requirements for integration with operational systems
  • Which determines the requirements for capturing and storing data within the operational systems


If you came here through Google looking for answers to your BI questions, I hope this helped. If you have any questions, please contact me.

About Me

My Photo

Summary:

With over 20 years of industry experience, Doug Lautzenheiser has provided business intelligence services for well-known organizations such as Procter & Gamble, JPMorgan Chase, Omnicare, Wendy’s International, the State of Indiana, and the State of Oklahoma. ComputerWorld recognized one of Doug's projects with honors for innovative use of technology.  Doug is a featured blogger on BI software at Smart Data Collective.

With his broad knowledge of technologies, business processes, and industry best practices, Doug provides client value by performing strategic advisory services; leading tactical BI application development projects; and enabling dramatic reductions in time, cost, and risks through his unique automated BI consolidation application.

Doug has hands-on experience with a variety of enterprise applications. He is degreed summa cum laude in Information Systems from the University of Cincinnati. An experienced trainer and mentor, Doug has provided educational services to organizations such as National Semiconductor, Ford Motor Company, Northwest Airlines, Principal Financial Group, and Target Stores. Doug is the General Manager of Partner Intelligence.

Talk to Doug before manually performing a large BI initiative. Doug will show you how other smart companies saved time and money by following proven methodologies and automating BI processes instead of letting somebody "wing it" with a manual approach.

Specialties:

B2B software vendor leadership. BI implementations, standardization, and consolidation; data warehousing; WebFOCUS; iWay; BI vendors (Cognos, Business Objects/Crystal Reports, Microstrategy, Actuate, Hyperion/Brio, SAS); ERP; and full SDLC.