Jon Reed Interviews Naeem Hashmi, NetWeaver BI Expert

An Historical View of SAP Business Warehouse:
Jon Reed Looks Back on His Interview with NetWeaver BI Expert Naeem Hashmi

Jon Reed's Introduction, April 2008: I'm pleased to present, in its entirety, this classic interview with Naeem Hashmi of InfoFrameworks on the emergence of the SAP BW product (now called NetWeaver BI). At the time I sat down with Naeem for this detailed look at birth and evolution of BW, we were a long way from the BI of today. But in the years since, many things that Naeem predicted have come true.

Naeem himself remains a very influential voice in the SAP BI community. He has advised more clients on their Business Intelligence infrastructure than I could list here, and he continues to speak and publish on a range of IT architecture and SAP optimization topics.  

Hopefully down the read, we will get an update from Naeem on how he sees the market since this initial interview in 2001. Before you dive into the interview, you may be wondering how Naeem's predictions have turned out. The answer? He was right about many important trends, not the least of which was his belief that SAP should leverage their "in-memory" know-how to provide additional capabilities to BI. Of course, we now have a very important BI enhancement product that leverages this exact technology, known as the BI Accelerator

Of course, one change you will see is that in this interview, there are lots of references to "data warehousing," a term that is no longer trendy that SAP has distanced itself from. This is a sensible thing - the new term, "business intelligence," is a better reflection of the potential of NetWeaver BI to help businesses make better strategic decisions - without having to deal with the underlying complexity implied by the "data warehousing" catch phrase.

It's also easy to forget how important it was for SAP to get endorsements for its product from key BW thought leaders like Bill Inmon. SAP BW was really hurt in the early going by such criticism, but SAP responded to the criticism, and in this interview, you get the first quotes coming out from Bill Inmon on his increasing respect for BW. But now, as you can see from this 2005 PDF, Bill Inmon now sees BI as a solution that is good enough to be used by non-SAP customers as well - something Naeem also pointed to in the following interview.

Perhaps the thing I like most about this interview are the insights we get into Naeem's own background and how his career evolved. On, we like to focus on "SAP career best practices" whenever possible, and if you read this interview, you will get a sense of how Naeem has managed to position himself as an important contributor and consultant in the SAP market space while retaining his own style and independence. To me, that's a great accomplishment and it's one of the reasons I look to Naeem not just for market insight but for a model on how to be successful in the SAP ecosystem while running your own company.

With that said, enjoy the interview, and I'm sure we'll hear more from Naeem down the road.

An In-Depth Interview with Naeem Hashmi, BW Author and Expert
Part One
May 21, 2001

Anyone who has a stake in SAP has a stake in SAP's Business Information Warehouse (BW). What was once a few cubes of business content for enhanced reporting capability has now become the foundation of SAP's entire e-business strategy, not to mention the data infrastructure for the entire SAP product line. But if BW is wide in scope, it is also widely misunderstood. Initially dismissed by many data warehouse experts, BW is now turning the corner and establishing its credibility as the foremost data warehouse solution for SAP customers. Since BW is potentially tied to virtually every aspect of the SAP applications suite, SAP consultants are wise to take the time to get a handle on how BW might fit into their own particular skill sets. To help us in our quest to understand this mysterious but powerful product, we turned to a true BW technologist and asked him to drill down into the BW solution and give us a clear sense of today's BW market.

Naeem Hashmi might be the foremost expert on BW that isn't holed up somewhere in Walldorf, Germany. Hashmi is the author of Business Information Warehouse for SAP, the first (and still the only) book on SAP BW. He has worked with BW since its inception, when he was Technical Director at Digital/Compaq. Hashmi collaborated with SAP during the early releases of BW, and he has continued to work with SAP and a range of other third party vendors on BW product development and integration. He speaks internationally on business intelligence, data warehousing, and ERP information architectures, and his articles on these subjects are hard to miss in the industry press.

Recently, we had the opportunity to sit down with Naeem Hashmi and conduct an in-depth discussion on the BW product and marketplace. Hashmi sees BW as a visionary product that brings together traditionally autonomous data management initiatives into one comprehensive solution that's ideal for the real-time demands of e-business. He's not afraid to go out on a limb and challenge the data warehousing experts to rethink their approach and take another look at BW. At the same time, Hashmi is equally willing to challenge SAP to continue to develop BW into the full realization of its potential.

In this landmark interview, Naeem Hashmi covers just about every critical issue in the BW marketplace, from BW architecture and implementation issues to the latest version releases and product innovations. Our discussion delves into the technical guts of the BW system, and Hashmi explains how BW resolves some of the classic data warehousing problems and allows BW users to focus on business solutions, rather than data extraction headaches. After we get a handle on the product itself, Hashmi analyzes BW's battle for market acceptance and answers the long-awaited question we all want to know: why haven't we seen that much-anticipated surge in BW sales and project activity?  

As the interview unfolds, get the answer to that question, and in the process we get a clear sense of Hashmi's deep commitment to BW. By the end of our talk, we leave with a true understanding of how the BW solution, in its ultimate incarnation, will be a force to contend with - not just as the foundation of e-business for R/3 customers, but as an innovative business intelligence and data management architecture that even the most skeptical data warehouse experts may one day come to admire.

Hashmi is currently the Chief Research Officer for Information Frameworks, his own consulting company. He is available for short term strategic e-Business Intelligence consulting engagements, industry talks and seminars, and third party product evaluation.

Jon Reed: Naeem, most people we run into in BW come from an SAP background, but you seem to come from a data warehousing background.

Naeem Hashmi: Not only data warehousing. My overall background includes information architecture, enterprise application integration, product development and engineering. So my background covers more than data warehousing - it also includes object-oriented technologies, database technologies, and client-server and distributed systems expertise. It's a broad background, but heavily focused in academia and manufacturing, mostly discrete manufacturing. I can apply the same concepts pretty quickly in process industries and health industries. I'm not really a business or functional expert from an SAP business applications perspective. I understand that but I'm more technical in my focus. When technology, integration, deployment architectures, or performance issues come up, I usually have something to say about it. :)

Reed: Did you get your first exposure to SAP Business Warehouse when you were at Compaq/Digital?

Hashmi: BW came to Digital because of me. I was at Digital in the corporate information architecture group. I was one of the information architects there - this was in the 1991-92 timeframe. Digital was going through the "Applications Renewal" strategy. SAP was one of the major applications that was part of that renewal strategy. The objective was to get rid of legacy applications or redundant applications that were customized fifty different times for fifty different global installations. We used to spend billions of dollars maintaining the exact same application over and over for different plants. So the goal of Applications Renewal strategy was to cut down redundant IT work by streamlining the business processes and adopting a universal technology framework.

I was chartered, from the technology side, to analyze how the SAP reference model and technology framework could fit into the Digital Information and Business architecture - primarily with the goal of integrating and replacing legacy applications. So we worked with the businesspeople to compile reference data used by Digital globally and then we looked at how that data could be mapped and managed within the R/3 system. On top of that, we looked at how we could integrate this reference data with the legacy systems. I was working with two other people to select the database technology for SAP R/3 as well - to decide what type of back-end database engine we should be using. So we started with a very broad look at the business models that we wanted to deploy, then we compared that with the technical architecture of R/3 and proposed deployment models. It was a huge, corporate wide effort. From that perspective, I got engaged into SAP R/3.

Reed: And prior to that?

Hashmi: Prior to that, I was working as a principal engineer in Digital's Center for Integration Technologies. We developed a next-generation, object-oriented CIM product and manufacturing reference architecture that we deployed globally. This CIM product was called DecShop. It was a shop floor data management system for manufacturing environments that tracked manufacturing processes all the way from component manufacturing through order processing and invoicing. It was a closed-loop system, and even today's best manufacturing systems, including SAP, are not as sophisticated as this product that we had developed. We managed transactional information as well - we built a global, enterprise-wide data warehouse which was based on business events. We had an almost-real time "self-describing message" system, where you can define the kind of information you need to exchange on the fly. Now, almost fifteen years later, it's a "hot new technology" called XML.

So getting back to the SAP side, I was doing all the technical design work, looking under the hood of R/3. At the time, SAP did not have a Tax verification system, so I was assigned to integrate a third party Tax system with R/3 in 1994. So I was looking under the hood, not only at R/3 Basis technologies, but at the rest of the business applications models as well. I was also a member of a team that designed all of Digital's business instances within R/3 and developed a global R/3 deployment strategy. We also designed and implemented an enterprise-wide ERP/Legacy application integration architecture. In 1995, we went live with R/3 for one business unit. At that time, we also had a lot of data warehouses at Digital. Just like any older, larger global company, we had a range of information sets to manage - some were legal, some were statutory, some were archival, some were operational, some were mostly integration hubs for that matter. So from a decision support perspective, I was looking at how to exploit R/3 technologies to build an information delivery system.

Reed: And how did that come to be?

Hashmi: In 1995, we came up with several strategies and started exploiting SAP's Basis technology to build a separate instance for reporting. In April 1996, I spoke at a DCI conference in San Jose on "How to Exploit SAP R/3 from an Information Management, Data Warehousing and Reporting Perspective." Then I spoke on the same topic at the ASUG meeting in Boston in late 1996. At this meeting, the SAP product management also shared their vision of a project called the "Reporting Server - A stand alone reporting Instance." From then on, I worked with original SAP BW engineering team, as well as with the senior product management team of the SAP New Dimension products, to determine how BW should be designed in order to resolve enterprise wide information management technical issues. In late 1997/early 1998, we installed the first lab version of BW 1.0E.

Digital was one of the first six customers to install the BW system, and I was the first one to install BW and get it up and running at Digital in January of 1998. At that time, there was no business content in BW, so you did everything yourself - you built everything from scratch. At that same time that I was doing the initial BW work at Digital, I was also working on the enterprise-wide integration work for Compaq and Digital - that work was not limited to internal application integration, it also involved our consulting, sales and marketing teams. I used to help them sell our enterprise-wide integration and business intelligence solution. I used to explain our integration and solution deployment strategy to our customers' decision-makers, and break it down to the technical level for their technical people.

Reed: So how have you seen the BW product evolve?

Hashmi: The way the BW product has evolved is really amazing. I have worked on product development with other vendors, including Oracle , but I've never seen anything like what SAP has done with BW in such a short time. The first version was 1.0P (the "P" meaning "Pilot"), and then came 1.0E ("Early Customer" version), then 1.01, then 1.2A, then 1.2B, followed by 2.0A, 2.0B, 2.1C and now 3.0A. The product has come a long way: when you look at the overall data warehousing products available in the market now and look at where the SAP product is today, BW has no peer. The richness of the SAP BW product is amazing.

The main key is BW's Basis infrastructure - that is main foundation for the success of BW. Other companies may provide tools, but by the time you go to this vendor and that vendor and find all the tools you need for your data warehouse, you have a hodge-podge of tools and technologies with different licenses, technologies, and architectures - you spend too much of your time just setting up the environment and learning several tools and technologies. To add to that, products continue to appear and disappear in the data warehouse industry, so you're always playing catch up and asking vendors, "What's next?"

So a major strength of BW is its robust, "single vendor" infrastructure. Another strength is the way SAP positions BW. Most people think of BW just as a data warehouse, but BW is not really a data warehouse - it is an infrastructure. On top of that infrastructure, you have a sound information delivery system, several analytical applications, and data-interconnect hubs. BW is also part of SAP's APO, SEM, and CRM solutions. BW is now a part of the SAP infrastructure, very much like Basis technology. There is a big difference between a Business Intelligence solution and the BW infrastructure - BW is both of these things, so when you talk about BW you have to specify what BW really means to you. That's why whenever I speak, talk, or write about BW I always specify what BW really means, because it all depends on the context. In the typical data warehousing world, there is really no equivalent to BW.

An In-Depth Interview with Naeem Hashmi, BW Author and Expert
Part Two
June 4, 2001

In part two of our discussion, we take a closer look at what makes the BW architecture unique amidst a crowded market of data warehouse vendors. We also take a closer look at the state of the product in its latest release, and Hashmi relays how BW fits into SAP's data management structure and e-business product line.

Jon Reed: What makes BW special compared to other vendors' products?

Naeem Hashmi: The two critical factors that make BW unique are: 1) BW as an infrastructure and 2) BW as a rich set of business intelligence applications. When BW is used as an information hub for all e-business application components, that makes BW part of the overall infrastructure, based on SAP Basis technologies. So regardless of whether you're using BW in conjunction with SAP-CRM, APO, SEM, R/3, or as a data warehouse for business intelligence initiatives, you don't have to be retrained for individual applications each time, because you're always using the same Basis technology for the data operations, management, delivery and security.

Of course, the business content might be different in each application, and there are slightly different optimization characteristics for each application, but that's not like starting each application from scratch and hand-coding everything. You don't have to train in VB and other development applications; you don't have to train in Oracle designer and Oracle enterprise manager; and you don't have to worry about integrating all those pieces and vendors together. If you don't have a complete data warehousing solution like BW, you have to train several teams to do many different things and pull them all together.

That's one of the great things I see in overall industry trends: the exploitation of the same infrastructure for the business operations as well as the data warehousing or business intelligence operations. And BW is really ahead of the game in terms of those trends. When people talk about data infrastructures, they're usually talking about platforms - databases, networks, and hardware. But to me, infrastructure is much more than that: it's change management, operations support, security, version control, and deployment management. ERP data warehousing includes all of that and more. Remember, simply extracting data out of an ERP application is not ERP data warehousing, because in that case you're not able to leverage the same infrastructure that OLTP and the other business applications use.
Reed: That's exactly what you said in your book - you made that point very strongly early on. You wrote that "Simply extracting data from an ERP application package is not data warehousing. An ERP data warehouse supports a collection of integrated applications to report, analyze, and control business events across the enterprise."

Hashmi: All leveraging the same infrastructure.

Reed: And you think BW is going a long way toward achieving that vision.

Hashmi: It's there now. The main thing to keep in mind is the implication of using the same infrastructure for OLTP and Business Intelligence. If you're using RFC on R/3, you can use the same RFC technology with BW. If you're using BAPIs, you can use the same mechanism for the BAPIs. The parameters and the methods will be different, but the overall concepts are the same - you don't have to re-train anyone, you just need to know what content you need to exchange. You have a similar process working on the CRM, SEM, or APO side. In BW 3.0, there will be a capability to integrate Microsoft Analysis Services as one of the objects within BW. Right now, BW uses relational technologies. You build a Cube star schema within that environment.

Reed: An InfoCube structure.

Hashmi: Right, it's called ROLAP (Relational Online Analytical Processing). What happens is that ROLAPs are somewhat slower, but they can handle fairly large data volumes. Then there is true multi-dimensional analysis, what they call MOLAP, like Microsoft Analysis Services, Oracle Express, or Hyperion. MOLAPs use a pure, multi-dimensional structures using a proprietary database technology - they're not relational. Therefore, MOLAPs are much faster, but they run out of speed very quickly when the InfoCube grows too large. So there are pros and cons to each approach. But what happens in BW 3.0 is that if someone is running BW on Microsoft's SQL Server, they can also exploit, within that BW instance, Microsoft's Analysis Services to build the MOLAP cubes, so there's options there in terms of what kinds of cubes you need to build. In some cases, you can go with MOLAP and BW will load faster and perform faster queries. This way, you can have more flexibility in terms of your data structures.

But there's more SAP can do to improve performance. In the February 2001 edition of Intelligent ERP magazine, I wrote an article called "In-Memory Databases." SAP has in-memory database technology that they call "LiveCache." SAP needs to exploit LiveCache for BW, since business-to-business situations happen almost in a real time. Right now, LiveCache is only used within APO. SAP needs to exploit that technology within BW. Once SAP does this, the BW technology framework will be very robust and ideal for e-business. In-Memory Databases such as TimesTen are used by other high performance e-business web sites.

Reed: Can you give us an example?

Hashmi: Anytime you log onto Yahoo or other high-traffic web sites, you will see that they have millions of users. All individuals have their own personalization data, and it is accessed in real time using TimesTen's In-Memory database. So SAP needs to exploit that technology for the Workplace Portal, because that's the area within where people log on and there is a need for profile management and user customizations. Similar functionality is needed on the backend side for application-to-application integration, such as when you need to exchange data with a customer via the SAP-CRM application. An in-memory database component within BW will be a great asset for these kinds of business-to-business and business-to-customer real time data exchange repositories. We're not there yet on that issue, but when you look at the three year history of BW and how the product has evolved, it's amazing. I've been in the product development groups for a long time and I've never seen this kind of advances in functionality.

As I've noted, the three main areas of innovation that set BW apart from other data warehouse solutions are: first, it's a complete infrastructure, not just a data repository; second, it's an e-business hub for the entire enterprise; and, finally, SAP is taking a very different strategy in terms of data warehousing than traditional data warehouse hubs. In the IT industry, there are three architectures that are very well known in the information management space at the enterprise level for large companies. One used to be called the TA1 , which came from Digital in the late seventies.

Then came the TA2 technical architecture. The TA2 concept involved a left side and right side data management environments. On the left side was the data collection piece and the right side was the data reporting piece, the data access. All the services that were designed to share data back and forth operated within that two-sided data structure. Then there was a separation between the data collection piece and the data access piece. It was not a "closed loop" environment. The data access piece became the data warehouse environment. All the traditional data warehouse models developed by data warehouse gurus like Bill Inmon evolved from TA1 and TA2 models, meaning there was a separation between decision support and the transactional system. The reporting and data warehouses were part of the after--the-fact process, and they would do reporting and analysis and that's it. There was no closed-loop feedback to its transaction systems.

SAP has changed that model. It's not the afterthought or after-the-fact approach. When you're doing the business model for e-business, you have to have all the real-time information and business intelligence as part of your business model, so you have to have a very closed, tight loop environment. Business intelligence is the hub that sits in the center of rest of the applications for the business processes. It doesn't mean that it has to be one central database like Bill Inmon states. It can be very much like a Lotus Notes type environment, where the document flows according to a business workflow model - the document flows where it needs to go. So that's what SAP BW is. It's not necessarily designed for a traditional data warehouse environment, where you have to have a huge database and everything sits there and you have to rely on that one database. SAP BW is designed to be distributed business intelligence environment.

Reed: And there's one other aspect to BW that you've noted before: the importance of what you've called an "extraprise data warehouse," where you can have a free flow of information between your company and its customers and business partners.

Hashmi: Right. Even now, people are using an extraprise approach, but only for a small amount of data. For example, when I need to look at my last bank statement, I don't go into my paper file folder, I log onto my bank's web site and review the statement online. Vendors can do the same thing for product inventories, and soon customers will be poking into individual companies' data warehouses for their own past transaction histories. There will also be comparison shopping analytics, so that you can compare your own shopping history between, say, Barnes & Noble and

There will be a lot of these kinds of analytics out there, and soon we should see some Business Intelligence (BI) ASPs come along. I wrote about this in the September 2000 Intelligent ERP Magazine, in an article called "BI for Sale." I've been advising some of the largest ASPs to design their BI services. In the "BI for Sale" article, I outlined several issues that must be addressed. There are some legal issues to consider, but most of the issues are cultural.

Getting back to SAP, for distributed e-business applications, you need a robust, proven and distributed infrastructure. Typically, you end up selecting many tools and technologies from several vendors to implement and deploy e-business applications. SAP technology framework provides a single solid foundation to implement and deploy traditional as well as extraprise-wide application. Many data warehousing vendors provide spot applications, you can buy them if you're only doing one thing and you're not looking for that niche vendor to give you a complete architecture or total solution. If you're just trying to solve one or two specific business problems, you can go that multi-vendor route - each vendor has its own strengths and weaknesses. It depends how a user wants to exploit the technology. But if you're looking for a vendor with a complete data warehouse architecture and solution along with rest of the business-critical applications, in my opinion SAP doesn't have any real competition out there right now.

An In-Depth Interview with Naeem Hashmi, BW Author and Expert
Part Three
June 18, 2001

In part three of our discussion, we take a closer look at the current state of the BW product, starting with its advantages as an information architecture. Hashmi explains how BW's "one vendor" architecture helps users focus on business problems instead of technical headaches. Then Hashmi gives us an overview of the upcoming release of BW, version 3.0, and tells us about some of the major enhancements we can expect in this release.

Reed: In this day and age, you're not just looking for internal Business Intelligence solutions. You also want to be able to collaborate and share information with partners and suppliers. Do you believe that BW is a viable solution for this kind of "Extraprise Data Warehouse"?

Hashmi: Actually, the BW infrastructure is already there. When I talk to people, I say, "Look at your overall information flow model." This goes back to the Lotus Notes workflow model I mentioned before. You need to define the business workflow. One of the benefits of ERP solutions is that when you define ERP business processes, you're defining all business checkpoints. At that time, you can project what types of information have to be exchanged that require intelligent actions.

This is similar to Lotus Notes where you're doing the document workflow and appropriate actions. During ERP solution implementation, you define the enterprise-wide workflow: what kind of information do you need to share with your partners and at what point? If you're looking at an order fulfillment process, you might shoot a request through the SAP-APO system for parts availability, and look into the SAP-CRM system for past customer behavior. You might have a different objective - you might want to cross-sell to the customer as well and see what other products might be relevant to their profile.

All this is done using the same technology framework and the same user interface. At this time, one of the best things about BW is that most of the technical data headaches that you used to spend months, sometimes years, trying to resolve are already hammered out, and you think mostly at the business level and resolve your business problems. When you go with BW, you no longer have to worry about or learn SQL, or how SQL works, or how certain database tables are created and managed. Moreover you don't have to worry about all those complex data extraction issues. With BW, usually you don't have to think about any of that, things just flow. Whereas traditionally, about sixty percent of data warehouse operations is getting the data out of data sources.

Reed: But BW is different.

Hashmi: In BW, that sixty percent of the challenge is basically gone, and you spend that time resolving your business problems. Too many times, when people look at implementing BW, they start from scratch, trying to define star schemas and data structures. But you don't need to do that! When I talk to companies who are considering BW, I tell them, "When you call the utility company or the electric company, do you ask them how they store the data inside their database? No. You simply tell them, %91I need this service, I need this performance, I need 24 hours a day service etc.' - and that's it. Who cares how you store information as long as you can get it out when you need it? As long as you have some APIs that allow you to get at the information you need, then who cares? Why re-invent the same wheel that SAP has hammered out many times? There's always some fine tuning involved, it's never 100% solution there out of the box, but 50 to 70 percent of the work is done."

About two years ago, I was speaking at an ASUG conference, and I told the group about some very interesting research on BW and Traditional DW projects. I was looking at all the BW questions over SAP's OSS notes system, and then I looked at the questions raised at the data warehouse list server run by the DW industry overall. And I pointed out that when you're looking at the BW list server, most of the questions are "How should I get this patch?" or "What type of business content is there?" or "How should I customize this InfoCube to get this application?" or "How can I improve performance?"

But when I went to the data warehouse list server, most of the questions were: "How should I select this tool?" or "Does someone know this vendor?" or "How should I define this schema?" or "How should I copy this database?" or "How should I define security?" So the questions were very low-level, indicating that companies are spending as much as seventy to eighty percent of their time just on defining the technical infrastructure, never really addressing the real business issues. BW clients can turn their attention to the business issues at hand without getting bogged down in too many technical data extraction issues.

Reed: Let's talk about the latest release of BW. What's in the works and what's available for customers now?

Hashmi: The latest version of BW is 3.0A. BW 2.1C is the latest customer release available. BW 3.0A is scheduled for first customer shipment later this year.

Reed: Is 2.1C a major new release or more of a bug patch for 2.0B?

Hashmi: It is a bug patch for 2.0B, and it also has additional business content from the e-analytics perspective. Those are the major features. 2.0B also has a few more tools for web development and web enablement, but it's not a major new functionality.
Reed: SAP seems to be increasing the amount of InfoCubes with pre-defined business content with each release. From our understanding, there were around fifteen InfoCubes in version 1.2, and there were 45-50 in version 2.0. Most of the standard InfoCubes dealt with data in the cores SAP modules of FI, HR, and SD. Do you know if SAP is planning on adding more InfoCubes in more areas for 3.0?

Hashmi: I am sure SAP will add more business content in BW 3.0. It is an ongoing process. The exact details of new business content in BW 3.0 (InfoCubes, ODS or Documents) is still being worked out. Today, several ASUG teams are engaged in defining and prioritizing what should be included in BW 3.0. Later on, the SAP BW Product management team will make an official list of content scheduled for BW 3.0A.

Reed: You mentioned one major functionality addition coming in 3.0 - integration with Microsoft Analysis Services. Are there any other innovations in 3.0 you're anticipating?

Hashmi: There are several major areas of improvement: one is data warehouse management - there will be XML integration, so that if a customer needs access to internal BW data, there is an XML-enabled solution. Another major feature is that in release 3.0, you can extract data from BW for archiving. Or if you want, you can also move R/3 archived data back into BW for reporting. There will also be enhanced data monitoring capabilities for troubleshooting and the avoidance of duplicate data. You will also be able to monitor data over the web as well. There are also a lot of new features on the performance side. The ODS performance will be improved, there will be improved flat file uploads, and there will be more sophisticated methods to filter out data. The other feature is the integration piece I talked about before, using Microsoft Analysis Services, but you can only use this feature if you're running BW on Microsoft SQL Server.

Another new development in BW 3.0 version is the %91hub and spoke model' that will allow companies to deploy robust centralized data warehouses, if desired. One significant feature to note in BW 3.0 is that SAP will provide a tight integration with a 3rd party ETL product from Ascential Software called %91Data Stage'. This will enable customers to load data from non-SAP data sources in BW, similar to Acta, Informatica and other SAP BW Staging BAPI certified 3rd party ETL tools.

Reed: Is one of the major goals of BW to take over the reporting aspects of R/3?

Hashmi: It's very unrealistic to say that there will never be any reporting done on the OLTP side. On the R/3 side, there will always be some real-time operational reporting. SAP's plan for BW is that companies should go with BW for all their near-real-time reporting, as well as their data analysis and historical reporting needs. This way, SAP does not have to keep on enhancing SIS, LIS, and all these R/3 reporting systems. To the best of my knowledge, that is what the R/3 reporting strategy is.

An In-Depth Interview with Naeem Hashmi, BW Author and Expert
Part Four
July 2, 2001

In part four of our discussion, we look at how the latest version of BW is holding up in terms of performance and functionality. Hashmi gives us his take on the state of BW web reporting, the use of the Internet Transaction Server, XML, and whether BW can handle terabyte-level amounts of data. In Hashmi's view, measuring BW performance involves dealing with user issues and expectations as well as managing many different types of data. In the next edition of the interview, we'll turn our attention to how BW is faring in the market and how it is facing up to the criticisms posed by data warehousing experts.

Jon Reed: And how is BW doing in terms of dynamic, web-enabled reporting?

Naeem Hashmi: You can do dynamic web reporting now. The development piece of it is not that fancy compared to other web application development tools, and there are some steps involved to publish web reports, but SAP is gradually streamlining the web publishing process, and with 3.0 it will be even more efficient.

Reed: Now when we talk about web reporting in BW, that's all utilizing the Internet Transaction Server, right?


Hashmi: Yes, BW uses the ITS as the engine for web-based reporting. In future versions of BW, ITS may be replaced with the SAP Web Application Server.

Reed: And one benefit would be that users who don't even have R/3 installed on their system can use web-based reporting for their reporting needs.

Hashmi: Once again, ITS is part of a common infrastructure. So whether you're working in R/3, or BW, or APO, or CRM, using ITS you can connect with all of them. You can mix and match, and merge BW web reports (via URLs) in corporate web sites. That's a very powerful option.

Reed: With all this robust functionality, it's amazing that every SAP installation doesn't have this stuff running.

Hashmi: That's true. In the past, there were a lot of issues with the licensing, in terms of how much you charge for web users and how much you charge when people are logging on and off the system. In the beginning, a lot of people got turned off from ITS because of the licensing costs. But I think SAP is changing its strategy in terms of ITS licensing.

Reed: So all in all, BW's diverse reporting capabilities can really ease the burden on an R/3 system.

Hashmi: Definitely. The way I see it is that the integration between BW and OLTP is based on your business needs. For example, if you have historical information in BW and current information in R/3, right now you can use a report-to-report interface called "drill down." Basically, you have two reports, and you pass parameters from one report to the other, and through RFC you execute the report on the server side. That drill down capability is available in 2.0B - it's sort of a basic way of jumping from one report to another. SAP has learned a lot about web applications product development, and so the web publishing methods now in BW 2.0B are interim solutions.

This interim approach really works because in data warehouse reporting, the project never ends, because people's needs and requirements constantly change. So you try to get something out there that people can use now. It is different than when you're releasing a key transactional feature in R/3, such as order processing, where ninety percent of the time you're doing the exact same thing. That's why XML is really great on the R/3 side, because you can define structures very quickly to move data in and out. On the data warehousing side, XML is really not as great, because you need to move large packets of data - sometimes as large as a megabyte in size - and XML is better for smaller packets of operational data, and data structures that change after almost every navigation step.

Reed: There seems to be a market perception that BW doesn't have the size and scalability to compete with an Oracle-type data warehouse solution that can handle terabyte-level data issues. What's your take on this?

Hashmi: I would say yes and no; it all depends on the perspective. In my book, I talk about performance characteristics. Just because you can handle a large volume of simultaneous users doesn't mean it's a scaleable system. For example, you could have a multi-terabyte database and thousands of BW users issuing the same types of queries over and over again, and you won't have a performance problem. In this case, the queried data is stored in the buffer, and subsequent data requests retrieve data from buffer over and over again for operational reporting. But you can have a terabyte size database, with just a few BW users doing extensive analysis, and it can kill the BW system.

So complexity and scalability depends not only on the number of users and the size of the database, it also depends on the nature of the analysis one is doing and how the data has to move around. So going back to your question about whether BW is scaleable or not, again, if you're looking up data for general purpose reporting and ad-hoc reporting, BW can go to the terabyte level easily today. When BW supported only the InfoCubes, which was the case for the 1.2B release, then the performance was not as good, because when InfoCubes are larger, they are harder to work with no matter what database you are using on the back end.

Reed: So BW is not as dependent on InfoCubes at this point.

Hashmi: Correct. Now when you use BW, you can construct flat tables, called ODS objects, in addition to InfoCubes. These flat tables can literally add or partition large database tables the way you do in a pure database environment. The only real performance issue has to do with the user interface - the Bex analyzer is the killer there. The reason for the problem is that Bex is based on Excel. So if you have a huge Oracle database and an Excel front-end, or a huge SQL Server database and an Excel front end, then you have a challenge, because Excel is cell-centric. So it requires a lot of memory management and cell management. When the data is moved in and out, it requires some programming to manage it. So if the user interface is a cell-based application like Microsoft Excel, then that is the bottleneck there in terms of performance.

In my book, I mentioned that when people speak of performance, each person has a different view. For the end-user, if the query is not processed properly in a reasonable time or the results are not displayed to them, then they call it "poor performance." In reality, that poor performance could be the result of a memory shortage or a slow CPU, or a poor graphics card in the end user's workstation, but to the end-user the data warehouse performance is poor. :) That's why in the book I have strategic radar charts to look at different aspects of performance characteristics - those issues are also addressed in Chapter 16 of the book. SAP BW has provided several mechanisms to improve performance. It all depends on how you design the application. The deployment architecture is the key. If you want to design a successful, flexible, high performance application, you really need to think through the design.

An In-Depth Interview with Naeem Hashmi, BW Author and Expert
Part Five
July 16, 2001

In part five of our discussion, we take a hard look at BW's struggle for market acceptance. Hashmi tells us about a very significant PR achievement for BW: the increasing level of endorsement from Bill Inmon, the father of data warehousing, who is now giving BW support after his initial strong skepticism. We go on to a broader analysis of BW's marketing challenges, and Hashmi outlines the cultural and organizational issues that must be conquered for BW to gain broad market acceptance. We also get Jon Reed's take on how cultural obstacles have affected the BW staffing market. Then Hashmi outlines how BW is currently positioned by SAP within the solution, as well as the relevance of InfoCubes to the BW of the future.

Jon Reed: How do you feel about the level of market acceptance of BW among SAP clients? Up to this point, the market for BW has not been as explosive as one might have expected, given the deep functionality and possibilities with the product, although there have obviously been some successful implementations. What is your take on the level of BW market acceptance?

Naeem Hashmi: The major problem that BW ran into was that the traditional data warehouse leaders like Bill Inmon and other did not really understand BW architecture and its role in the enterprise applications environment. They wrote papers and went out and gave talks that were very critical of whether the ERP vendors can truly provide DW solutions, especially SAP. These are the same experts that major companies invite to consult with them on data warehousing strategies. I was the only one in the industry who spoke at DCI, ERP World and the Data Warehouse Institute events (starting way back in April 1997) to educate data warehouse community on BW and how BW is to become the Corporate Information Factory by year 2001. And the facts are now in.

Up until November 2000, most of the comments from data warehouse gurus were still pretty critical of BW. Today, Bill Inmon's views towards BW have changed drastically. Traditionally, when data warehouse people talk about a business intelligence solution, they often talk about it in terms of the database environment. Anytime people think of data warehouses, they think of database issues - they don't go beyond the database level into business solutions; they don't really look at how information flows into the rest of the business processes in a integrated fashion.

Reed: Tell us more about Bill Inmon's change in perspective on BW.

Hashmi: It was only recently that Bill Inmon, the father of data warehousing, spoke favorably about BW. In a November 2000 interview on the TV at the BW Congress in Hamburg, Inmon was asked "What are your impressions on the SAP solutions approach and how do you see SAP's development since 2 years back when SAP entered in this market?"

Bill answered, "First off I have to say that I have been very favorably impressed with the notion that SAP indeed is building solutions. I am not aware of any company out there that has a true solutions approach. There are other companies that have tools and have a lot of the components, but in terms of all the way going to the operational environment to the collection, to the integration, extraction of information and then usage of the information, I guess I have to say that from a solutions standpoint, I am very favorably impressed with what I saw this week from SAP in their solutions approach."

Inmon further stated in his interview that SAP "has taken a very different approach from day one - a solutions approach." But even then, he could not state that BW is ideal for enterprise data warehousing, he still sees it as a limited analytical environment sitting on top of SAP R/3 only.
I worked with a well-known data warehousing recruiter for many years, and she made me very aware of the intense criticism for the first releases of BW coming from the most famous and respected data warehouse practitioners, Bill Inmon included. It's quite a surprise to hear that he is now making positive comments about BW, although I'm not sure I understand what he means by a "solutions approach" %96 aren't all data warehouse projects solutions-oriented?

Hashmi: That's true. That's what was interesting about Inmon's comments. I would have enjoyed asking him some additional questions for clarification, but I got some of those questions answered recently by him in a published white paper on BW. It is interesting how all this came about. Bill Inmon has a book called the Corporate Information Factory (CIF) that defines basic architectural principles on how companies should manage information. In January 2001, I gave a couple of presentations at the SAP-Microsoft executives conference, and I talked about how business intelligence becomes the hub of e-business, and I also talked about Inmon's Corporate Information Factory - which by the way, is an architecture and not a product, and how it (the CIF) can be mapped in BW. That's the true value of BW. Inmon's Corporate Information Factory is just a vision, just an architecture, whereas BW is an implementation of that architecture and vision. So I have been really curious to see if Inmon would acknowledge how closely BW resembles to his own ideal information architecture.

Then last month (May 2001), Inmon published a new white paper titled "SAP and the Corporate Information Factory," in which he concludes, "No other vendor has the same reach across all the environments in a comprehensive manner. Some vendors have software. Other vendors have hardware. But in terms of forming a complete picture across the entire corporate information factory landscape, no other vendor can compete. (This white paper is now available at See pages 11-12.)

This is good news for BW adaptation at large. And then in June at an interview at the SAP annual event, SAPPHIRE 2001 in Orlando, Inmon stated that SAP BW is a true solution to implement his vision of the Corporate Information Factory. (Listen to Bill Inmon's interview at the web site. Select "Tune in to SAPPHIRE Orlando Replays," and go to "Expert Panel: Business Intelligence and Corporate Value." You may need to register with SAP to view this panel. Registration is free.) I feel that Inmon's positive views toward SAP BW will have an electrifying effect on its popularity as a mainstream %91implement-able CIF' for the New New Economy.

Reed: For Bill Inmon to come around like this is a huge feat for BW - it seems like a major step in positioning BW the right way in the marketplace. Do you think that SAP is at all to blame for the market misconceptions that BW has faced?

Hashmi: SAP has not succeeded in educating the traditional data warehouse community about BW, and so they (the DW community) have been reluctant to embrace the BW product. I would also blame SAP for launching BW without the right team of consultants to implement BW solutions. Most of the early BW consultants were SAP functional consultants - they didn't have overall enterprise-wide reporting/analysis knowledge about how information flows. To them, BW was nothing more than a financial reporting or SIS reporting tool and that's all. They just wanted to see one separate box, where they could offload SIS or LIS reporting tasks - nothing more, nothing less. So BW was simply presented as a new R/3 reporting environment, not an overall enterprise data warehouse.

Along those lines, I remember visiting an early BW customer, and they had 83% of the business running on SAP R/3. They were looking at BW, Informatica, Acta, and other tools, trying to put together a total data warehouse solution, and a so-called BW consultant sat down with them and said "Why do you even need ODS? Why don't you build everything in an InfoCube?" But you can't build everything in a cube. They (the BW Consultants) didn't have any overall vision of how the rest of the company uses information for the rest of their business processes, other than FI (management) reporting.

Once again I come back to two key factors that have made things harder for BW. One was the lack of knowledge or acceptance of SAP's approach to data warehousing from the data warehouse community. To me, this reaction was really based on fear - it's a natural response to something that is different than what you know. These folks just wanted to keep their own approach going, they had their own drumbeat and they were sticking with it. And on the SAP side, many of the R/3 people kept beating their drums for their own approach, which was usually focused on R/3-like reporting. The customers got caught in the middle, and they were not given a clear sense of what BW could really do for them.

Hashmi: The other challenge is that when you talk about a traditional IT environment, you talk about data issues - data ownership issues. If I'm a VP of Finance or VP of Manufacturing, I own all the data in my vertical area. So if I have my own reporting environment, I don't want to give away my data. When we tried to implement R/3 in our company, we had the same issue - if you're going to implement R/3 successfully, you have to have a stewardship approach to the data in your area.

Reed: How can business leaders take a "stewardship approach"?

Hashmi: You have to look at your data not as your own, but as an information entity that you must manage and share with the whole enterprise - like an asset. The same issue comes up within the data-warehousing environment. When you're building an enterprise-wide data warehouse, you have to bring data in at one place and share it, and there is the perception by the heads of finance, manufacturing, and other areas that when they share their data they will lose control of it. Many times, they've built up their own highly customized environment, and when they look at BW functionality, they say, "It doesn't do this report, or this one, or this one," and they're not looking at the bigger picture.

Reed: It sounds as though BW has an uphill battle in terms of market acceptance.

Hashmi: It's not going to be a "Big Bang" experience, that's for sure. There's a lot of education to do and a lot of cultural issues to be resolved. For those readers who are interested in these aspects of BW, I go into these cultural issues in my article called "Mix it Up," published in the Intelligent ERP magazine. That's one of the things that SAP did not really realize - in the data warehousing community, the ownership of data is a very sensitive issue.

This topic reminds me of a large company I ran across recently, where some of the data warehouse people were posting criticism of BW to a data warehousing discussion forum, pointing out functions that BW could not perform. But the CIO and CEO had already committed to a number of SAP's e-business products, such as APO and SEM, which involve the use of BW. So the executives' decision to go with BW has been relayed to the data warehouse people, but they've already built their own custom solution and they're very attached to it, so they're dragging their feet. That's always the case with any new application - that's just human nature. But with data warehousing, each manager has built their own custom solution, so the issues are even more complex.

Reed: In your book, you went so far as to say that in terms of a successful data warehousing implementation, the cultural issues are more critical than the technical issues. That's an interesting viewpoint, because I don't think that's how a lot of people in SAP perceive the challenge. On the staffing side, whenever we talk to BW consultants who are waiting for the market to break out, the emphasis of the discussions has always been "When is BW going to take off?" And you look at it mostly in terms of the new functionality that companies are waiting for, so you decide that BW is just not ready yet. Then SAP announces that a new version of SAP is coming out, and you get a group of BW consultants together again, because this version is finally going to be the one that takes off. Each time, the emphasis is always on the functionality gap. The idea has been: "Once the functionality gap is bridged, then we're going to see an explosion of demand for BW."

That's the perception on the staffing side, so there's been all these mini-market explosions prior to each release, as consultants scrambled to position themselves for a market that never really happened. It's been a real roller coaster ride for BW consultants so far, with more lows than highs for most of them. I expect another one of these mini-explosions right before version 3.0 comes out. But what you're saying is that it might be a mistake to perceive the success of BW simply in terms of technical and business functionality. On the client side, there's all kinds of issues going on, not just technical issues.

Shifting gears a bit, won't the BW market expand as SAP companies are "gently" pushed into BW because they take on another New Dimension initiative, such as CRM or APO, which is heavily dependent on the InfoCube structure?

Hashmi: SAP does not call these products New Dimension anymore as far as I know. What happens now is that you have the option to buy a mySAP license. When you buy the mySAP license, BW is already shipped with it. The other products that used to be called New Dimension can be purchased separately when you choose to buy them. You can use BW just for CRM; you don't have to use it for your data warehousing or reporting, although that's also possible. You can also use BW for APO only. Or you can have a stand-alone BW system for SEM. In terms of SAP's new strategy, whenever you buy, it ships with BW, so the end result is that just about every SAP customer will end up using BW for something.

Reed: Well, they'll use BW for at least one piece of what they want to do, but that doesn't necessarily mean that companies are leveraging BW to the full extent they could for real, enterprise-wide and extraprise data management.

Hashmi: Right, and as I stated earlier, companies still have to work on a lot of cultural and organizational issues in order to take full advantage of BW. Often this means retooling the data warehouse environment. In the traditional data warehouse environment, the data collection side and the data reporting/access side have almost no relationship, except for the exchange of flat data files. Each side considers itself separate and has its own schedule and priorities. But to take advantage of data warehousing in an SAP environment, BW has to be part of the workflow and part of the business configuration on the R/3 side, and the scheduling of reporting must also take place on the BW side. It requires a lot more collaboration and teamwork. The ERP technology platform forces these groups to work together as a team, sometimes for the first time, in order to have a successful data warehouse implementation. And that's where you run into all the cultural issues.

Reed: Is the InfoCube structure going to continue to be a crucial part of BW?

Hashmi: It is one part of BW. InfoCubes have been an important part of the reporting environment since the early releases of BW. But the main thing that it is coming up is the non-cube environment. Eventually, InfoCubes will comprise about fifty percent of BW, and the rest of BW will involve non-cube data structures. InfoCube structures are primarily designed for numerical analysis. But in a traditional data warehouse environment, you have a lot of non-numerical objects, such as multi-media objects. So in BW 2.0B, there are new business document services, and in 3.0, there is even tighter integration of these services with R/3.

An In-Depth Interview with Naeem Hashmi, BW Author and Expert
Part Six
July 30, 2001

In part six of our interview, we cover a range of important topics. Hashmi begins by telling us why any hopes that the BW market will explode in a "Big Bang" are misguided. Then, we move on to learn about a fascinating client that is actually running BW but not SAP R/3. We talk a bit about the BW consulting market and how people can get involved. Hashmi also assesses the competitiveness of SAP's BW analytics. Then he tells us more about how his BW book is structured and how the book project came together. We end this week's discussion with Hashmi telling us more about his own role in the BW market.

Jon Reed: So looking at the BW market in a broader view, you're not waiting for the market to explode when version 3.0 comes out. You look at market acceptance of BW as a gradual thing, requiring an almost evangelical approach on the part of those who know what it can do for an R/3 client.

Naeem Hashmi: Right. There is no Big Bang. If you have a small company, you can take a Big Bang approach to BW in some cases. But large companies have a huge number of existing systems, and it's not just the technology that you have to deal with - you also need to deal with existing DW sponsors, cultural issues and training end users as well. One challenge I've seen with large SAP companies looking at BW is that they compare one aspect of BW with the best-of-breed tool or point application that they are currently using, which might be built using Business Objects, Cognos, Informatica, etc. And when they compare the point application with BW, they say, "We don't see those kinds of sexy things in BW Bex, so we don't want to go in that direction."

Then there's the issue of training. When you deploy BW, you have to commit to some retraining in order to gain end-user acceptance. You really have to carefully think through how you want to deploy your BW first project, where you want to be flexible, and which direction you want to go.

There's a lot of politics involved. Politics is an issue that goes along with implementing any new technology, and BW is no exception. Technology is not really the major issue; the major issue is getting BW accepted by your existing DW organization. The two areas within your organization where you have the most work to do are with the data warehouse community and the OLTP community. They both have to come to some kind of common agreement. And when you do rollout BW, the rollout should not be a Big Bang but in phases. You have very diverse end-users in large companies, and it takes a while to get everybody on the same page. It is interesting to note that there are some companies that have implemented BW that do not have an R/3 system.
That's an intriguing development.

Hashmi: Yes it is. The companies that took this route were global companies that had a lot of multi-currency and multi-language issues, and they also had Y2K issues to deal with. They were looking for a data warehouse solution, and BW was Y2K compliant. So they went with BW! They used third party tools to develop the end user reporting environment. But for the base infrastructure and the technology framework, they used BW. And they were all very successful. In fact, some of them are now going the SEM and R/3 route. One of these companies is actually now implementing an R/3 system, after already implementing BW.

Reed: So BW has reached the point where it can potentially be marketed as a stand-alone product to non-SAP customers

Hashmi: Yes, SAP does not currently do that, but the interest will be growing since Bill Inmon now changed his views in support of BW. Early on, SAP called BW an SAP reporting server and that perception has stuck with BW. In fact, when you look inside SAP and BW, when you look underneath, all the BW objects are pre-fixed by "RS," which stands for Reporting Server, which was the original project name that was then changed to BIW, and later to BW.

Reed: So for SAP BW consultants, or for those consultants who want to move into BW, it's a tricky situation, because there's not a ton of BW work out there right now, but there are interesting projects on the horizon. It seems like you can approach BW from a range of areas within R/3 and extend your skills.

Hashmi: True. You can address BW from several angles - from the R/3 reporting side, the CRM side, the SEM side, and from many other directions. The main thing is that you have to have a good understanding of what BW is - it's an infrastructure, just like the Basis technology. I tell SAP consultants who are trying to get into BW to think of it as Basis-type training. You can then apply the same lessons as you move into a business content development and reporting environment, or an APO environment, or any other area of SAP that is supported by BW.

Reed: So you can come into BW from the functional side, defining the business content that's going to be used, and you can also come into BW from the Basis side, setting up the infrastructure. What about ABAP skills and BW?

Hashmi: Well, there's some customization work in ABAP, but not a lot.

Reed: What about your own consulting work? Do you still work on BW projects in the field, along with your publishing and speaking engagements?

Hashmi: Yes. Right now, I'm the Chief Technology Officer for Information Frameworks, my own company. I still do some strategic consulting and higher-level product, information architectures and technology assessment. I also like to educate people on the BW project, and sometimes I'll take on a two or three week assignment to advise companies on their BW project.. Sometimes I help product vendors to integrate their e-business products with the BW framework.

Reed: Is SAP doing a good job with BW analytical tools, or do you need to turn to third party vendors if you want good BW analytics?

Hashmi: SAP is doing very well. They have covered just about all the bases. When you're talking about analytical applications, no vendor can provide a 100% solution. Each company is different, and you have to provide your own business patch. In SAP BW, there are business analytics for most business operations. When you need to do custom analytics, SAP provides templates that get you 50-60% there, and from there you can enhance them further for whatever purpose you have in mind. With analytics, it all depends on what your company is trying to use business intelligence. For example, in the case of e-analytics, if you're looking for click stream analysis, you can use BW click stream analytics. BW's click stream analysis is not really that robust, but if you want to see the click stream analysis along with the rest of your business processes, no one can give you as much useful data as SAP BW e-analytics.

So it all depends on the kind of click stream analysis you want to do. For point click stream analysis of your web site, you can buy click stream analysis services for as low as $25 a month right now. And you'll get all kinds of data analysis in terms of individual web site visitors - how long they stayed, which pages they visited, and when they returned to your site. But that data is not related to your overall business processes.

On the other hand, if you want the entire scheme - how often did this visitor select your product, which products did they look at, how often did they place an order, how long did it take to fulfill the order, how long did it take for the product to be delivered, was the customer happy with the order - then BW click stream analysis and e-analytics will be a big payoff for you. So you have to know that business value you want to get out of it. If you want to analyze data throughout the customer information lifecycle, BW e-analytics are pretty compelling.

Reed: Let's talk about your book, Business Information Warehouse for SAP. When did the book come out?

Hashmi: It came out in early September 2000.

Reed: The book is not just about SAP Business Information Warehouse, it also covers a lot of the issues we've discussed in this interview.

Hashmi: That's right, the book also covers the business intelligence, data warehouse, cultural, technical, and integration issues. On the second page of the introduction, there's a reader profile map that tells you how to take advantage of the book based on your background.

Reed: How did the book come about? Did you approach Prima Publishing or did they approach you?

Hashmi: They approached me. In April of 1999 in Atlanta, I was speaking at ERP World. After my talk, I saw two people sitting in the corner of the room and they didn't leave. So I went up to them and said, "Either you are completely confused by the presentation and you don't know how to get out of here, or you have a special question you don't want to ask in front of everyone else." And these people, who turned out to be from Prima, told me, "We want you to write a book on BW." It turns out that they liked how I was able to bring the business and technology issues together, and that's what they were looking for in the book. In July of 1999, I sent them a proposal and I got permission from SAP to do the book, but I had more trouble getting Compaq to sign off on the project.

Basically, in the midst of all the changes and downsizing activities in Compaq, a BW book was not something that was a direct benefit to the company. I left Compaq in December of 1999 and started to write the book. At first, I wanted to make the book very technical, but Prima really wanted the first BW book to be broader, addressing the wide range of issues involved, and that was fine with me.

Leaving Compaq opened up some great opportunities for me. I had already been working with SAP on BW 2.0A architecture work, and I was advising SAP to architect ODS. Since I was now available for consulting, HP asked for advice on their BW 2.0A and 2.0B pilots. I spent a few more months doing BW consulting work for a few big companies, and then I took time off to write the book. In late August of 2000, the book came out. Since then, it has been doing very well.

Reed: So do readers find that your book is still relevant, even though BW has changed a lot since last August?

Hashmi: Yes. I still do get email from readers almost every other day on how the book has helped them in understanding BW. I also get feedback on updating screen shots for BW 2.0 as well. This book does provide a good understanding of challenges facing the data warehousing industry and how SAP BW addresses such challenges. Then this book gives a good BW walkthrough from installation to defining BW objects, data loads, third party product integrations, BW 2.0 ODS, and data access and reporting. This is the only book where you will find every thing you wanted to know about BW in one place in an organized fashion. There are enough technical and non-technical notes in the book to keep starter and seasoned BW consultants interested. The CD carries good information on DW sources and BW Lotus ScreenCam movies to provide you visual BW walkthroughs. I hope you will find this book interesting as well!

Reed: I do! :) And it's still the only BW book on the market.

Hashmi: Recently SAP Simplicity Group in Palo Alto published a guide on "BW Reporting." This book is a simply an extension of Chapter 11 of my book. I'm considering doing some specialized data warehouse and data management books for specific vertical markets.

Reed: It seems like you have really thrived by moving on from a large company and working as an independent voice in the BW market.

Hashmi: Yes, when you're an independent practitioner, you don't have to abide by a company's policies. It's not that companies don't want to speak openly, they do, but they have alliances with many vendors, and they don't want to come across as favoring one way over another until they go through legal clearances. As an independent practitioner, I also get the chance to talk about technologies from other vendors as well. However, I do not write or speak about the products, technologies and vendors until I do %91hands-on-work' on their technologies and solutions first.

Reed: All in all, it seems like you're better cut out for an independent thinker and analyst role.

Hashmi: Actually, I don't really think of myself as an analyst. I'm mostly a practitioner and an architect. I try to differentiate myself from a traditional role as an analyst, even though I'm sometimes referred to as an "analyst." An IT analyst's (traditional) role is really in terms of a research and information compiler, and I'm really more of a practitioner - a hands-on "doer" from architecture to deployment. When the industry calls me an analyst, I say "no I'm not." (laughs). I tell them, "Call me a practitioner, because that is much more what I am."

An In-Depth Interview with Naeem Hashmi, BW Author and Expert
Part Seven
August 6, 2001

In the concluding part of our interview, Hashmi has some suggestions for BW product development that SAP should focus on. We wrap up our interview with a few final thoughts from Hashmi on skill areas that consultants might want to focus on as we wait for the BW market to unfold.

Jon Reed: Do you have any vision for the future of BW that we haven't talked about?

Naeem Hashmi: I think the next phase in e-business is mobile integration. When you talk about mobile integration, you're talking about making your solutions reliable, easier, thinner, and lighter. In the beginning, when you develop a product, you bring along a lot of baggage. Right now, in the BW infrastructure, there is too much baggage coming from the R/3 side that needs to be thinned out to capitalize on the possibilities for mobile integration. BW has a mobile agent that simply spits out the HTML document, but it's not really very useful yet. SAP's mobile functionality is okay for salespeople, but even salespeople need to get down to the document level. Once you get into the proposal development stage, you can't do it all on the cell phone navigating tiny devices window by window. Mobile devices are also still lacking in functionality. You need better mobile devices; mobile technology is still evolving.

The other thing SAP needs to do is to improve document management, what people call "unstructured information." Recently I read somewhere that more than 70% of information is document-based information. SAP has a Knowledge Warehouse, but it's not ready for primetime yet. I'd like to see a very solid, unstructured information management system from SAP, where you could do a lot of good, content-based searching as part of your information management search engine.

What happens is that when you come in from the business side, a lot of documents need to be shared within the company. SAP does not really have an outstanding document management system. They have IDOCs, but that's really for transactional documents, not really for documents with unstructured information. And you really need to be able to search and index non-structured information.

Reed: You want to turn that unstructured information into real intellectual capital the organization can use.

Hashmi: Right. I feel that SAP still needs to spend some energy in these areas.

Reed: Any last comments on BW?

Hashmi: If you're working on an R/3 side and they start to implement BW, you'll need to wear slightly different hats. BW is a hybrid between a traditional data warehouse environment and an ERP business application. It (BW) is also a hub of your e-business information flow strategy. One way or the other, BW is here to stay. Most SAP customers will end up using BW, if not today, than six months or a year down the road. So for people looking to brush up on their skills, this is a good time to brush up on the BW technology and infrastructure, as well as basic data warehousing concepts. In fact, when BW first came out, I wanted to do some courses in BW for data warehouse consultants, and also some data warehouse courses for SAP consultants, so this way people could understand both sides. At that time, we couldn't go forward, but I will be offering such seminars in upcoming Data Warehouse Institute conferences and other forums.

Reed: Naeem, thanks very much for the time and energy you have devoted to this interview. I'm sure everyone who has read this article has taken something new away from it in terms of their understanding of BW and how they might be able to get involved.

Hashmi: Thank you, I look forward to hearing what readers have to say.