Blog: Wayne Eckerson Subscribe to this blog's RSS feed!

Wayne Eckerson

Welcome to Wayne's World, my blog that illuminates the latest thinking about how to deliver insights from business data and celebrates out-of-the-box thinkers and doers in the business intelligence (BI), performance management and data warehousing (DW) fields. Tune in here if you want to keep abreast of the latest trends, techniques, and technologies in this dynamic industry.

About the author >

Wayne has been a thought leader in the business intelligence field since the early 1990s. He has conducted numerous research studies and is a noted speaker, blogger, and consultant. He is the author of two widely read books: Performance Dashboards: Measuring, Monitoring, and Managing Your Business (2005, 2010) and The Secrets of Analytical Leaders: Insights from Information Insiders (2012).

Wayne is currently director of BI Leadership Research, an education and research service run by TechTarget that provides objective, vendor neutral content to business intelligence (BI) professionals worldwide. Wayne’s consulting company, BI Leader Consulting, provides strategic planning, architectural reviews, internal workshops, and long-term mentoring to both user and vendor organizations. For many years, Wayne served as director of education and research at The Data Warehousing Institute (TDWI) where he oversaw the company’s content and training programs and chaired its BI Executive Summit. He can be reached by email at weckerson@techtarget.com.

February 2011 Archives

MC900149829.JPG

The purpose of business intelligence (BI) is to help organizations use information to make smart decisions. At a strategic level, BI is about making a business more intelligent. At a tactical level, it's about reporting and analysis.

BI professionals know better than anyone else that semantics are fickle. What's a customer? What's a sale? What's a product? Executives can wrangle for months before they agree on an exact definition of these household terms. And the same holds true for semantics within BI.

There has been a long succession of terms used to describe the reporting/analysis domain. (See figure 1.) Every decade, vendors with new technologies and experts with new theories conspire to create a new term to reinvigorate their products, ideas, and the field in general. Each new term creates a wave of hype and expectation, followed by some disenchantment as the organizations confront the harsh realities of implementing the BI flavor-of-the-day.

Figure 1. Evolution of BI Semantics
View image
Next week, I'll fill in the bottom half of this diagram and discuss trends in the BI vendor community.

1980s: Decision Support. Back in the 1980s, the industry's favored term was "decision support." But most "decision support" applications were custom built with hand code and cost a small fortune. This approach clearly didn't scale and couldn't support the aspirations of an emerging industry, and so the term eventually faded away.

1990s: Data Warehousing. In the early 1990s, Barry Devlin, Bill Inmon, and Ralph Kimball began writing about a new approach to reporting and analysis called "data warehousing" and the theory and term caught on. For the rest of the decade, IT professionals focused on getting data out of operational systems and into repositories optimized for query processing. But after the heavy lifting was done, IT professionals realized that simply building a data warehouse didn't guarantee that business people would use it.

2000s: Business Intelligence. So, in the early 2000s, IT professionals began focusing on making it easier for business users to access the data warehouse. They purchased desktop- and Web-based reporting and analysis tools and started talking about tools to make the business more intelligent. Soon, the term "business intelligence" became the industry watchword. (Note: I still use "business intelligence" to describe the entirety of the reporting/analysis domain because I believe it does the best job of describing the business purpose and value it has to offer.)

However, people quickly recognized that simply giving tools to business users doesn't guarantee that they'll use them or, if they do, find anything useful or act on what they've discovered. Soon, BI became shorthand for unwieldy reporting and analysis tools that often became expensive shelfware.

2005-2010: Performance Management. By the mid 2000s, the term business intelligence gave way to a new semantic upstart that focused on business outcomes. "Performance management" uses dashboards, scorecards, and planning tools align strategy with action and optimize performance at all levels of the organization. But executives soon recognized that defining metrics and targets that embody key objectives and goals is a top-down, slow-moving endeavor that is often subject to the vicissitudes of politics and bureaucracy.

2010s+: Analytics. Today, at the beginning of a new decade, a new term has emerged that emphasizes speed and agility and calls on organizations to move beyond monitoring performance to driving it. That term is "analytics."

Analytics initially referred to advanced statistical modeling using tools like SAS and SPSS. It gained preeminence thanks to an influential book written by Tom Davenport and Jeanne Harris titled "Competing on Analytics." Then, IBM began touting the power of analytics in television and magazine ads about the "Smarter Planet." Now, analytics refers to the entire domain of leveraging information to make smarter decisions. In other words, reporting and analysis.

2015+? In the future, perhaps we'll complete the circle and call our domain "decision support" once again. But whatever the term, the value is undeniable and enduring: using information to make better decisions is perhaps the last great frontier of sustainable competitive advantage.


Posted February 22, 2011 7:07 AM
Permalink | No Comments |

It's been awhile since I've had the opportunity to examine Informatica as a company and its entire product portfolio, which has blossomed into a broad-based data integration platform. After spending a day with company executives in Menlo Park, CA this week and learning about the company's business and technology strategy, I am bullish on Informatica.

Business Strategy

From a business perspective, the numbers speak for themselves. With $650 million in annual revenues, Informatica has grown revenues at a healthy clip (20% CAGR for the past five years) and maintained high operating margins (20%+ during the past 10 quarters and 31% in the most recent quarter), well above the industry average. And it believes it can continue to grow license revenue 20% a year for the foreseeable future.

Financial analysts repeatedly ask me "Who will buy Informatica?" At this point, the better question is "Who will Informatica buy?" and "Will Informatica expand beyond its core data integration market?"

Informatica has already made about a half-dozen strategic acquisitions in recent years, expanding its portfolio with data quality, master data management, B2B data exchange, messaging, lifecycle management, and complex event processing. CEO Sohaib Abbasi believes there are still many potential growth opportunities in the data integration market. His response to the above questions: "There is no need for us to consider ourselves anything other than a data integration vendor."

The Cloud. For one, Informatica sees the Cloud as a huge growth market for the company. Informatica made an early bet on the Cloud in 2007, and it's already paying dividends. Informatica has 1,300 companies using its Informatica Cloud service, which is a lightweight version of its on-premises, data quality and data integration software. Most Informatica Cloud customers are small- and medium-sized businesses (SMB) and three-quarters are new customers. Informatica believes there is significant upsell opportunity with this new customer base.

"Given the potential growth of the Cloud, we believe we are in the same position Oracle was in 1982 right before the relational database market took off," said Abbasi.

Future Investments. Beyond the Cloud, Informatica sees significant new data integration opportunities in the emerging markets for mobile computing and social networking. James Markarian, Informatica's chief technology officer, hinted that Informatica may deliver end-user applications that exploit these new deployment channels beyond offering core data integration services. In addition, Markarian mentioned other areas of potential investment, including Hadoop, search, semantics, security, workflow, Edge computing, and business process management.

Technology Trends

Integration. On the technology side, I was impressed with the degree to which Informatica is integrating the products in its portfolio. The mantra is design once and deploy anywhere. For example, one customer, Smith and Nephew, built rules in Informatica's data quality product, and then reused the same rules when it purchased and deployed Informatica's MDM product. With reusable rules, customers can safeguard their earlier investments as they expand their Informatica footprint.

Self-Service DI. I was also intrigued by its desire to improve business-IT collaboration and promote "self service data integration." Last year, it deployed Informatica Analyst, a browser-based application that makes it possible for business analysts to profile data sets and create data quality rules. It will soon expand Informatica Analyst to support data mapping. Informatica Cloud also empowers business analysts to move and transform data using a very friendly, wizard-driven interface.

Self service is great in theory, but almost always falters in reality, unless there is sufficient governance to ensure that end-user development doesn't spiral out of control and wreak havoc with information consistency and manageability. So, I was very happy to see that both products had sufficient controls (e.g., role-based access control and audit trails) to manage end-user involvement without restricting their ability to create new objects and rules.

More importantly, I saw the early germination of governance mechanisms that enable a business analyst and IT developer to collaborate on data integration tasks, eliminating a large amount of back-and-forth and miscommunication that currently hampers and slows down data integration work. For example, Informatica Analyst makes it possible for business analysts to create "specifications" for data quality rules (and soon data mappings), test the output, and then pass to IT developers to flesh out in virtual tables.
The developers, in turn, pass their work back to the business analyst to evaluate and test before anything is produced. Essentially, Informatica Analyst is the basis for a good prototyping environment.

It would be ideal if Informatica added workflow to both the Informatica Analyst and Informatica Cloud products to further cement the ties between analyst and developer and foster a true collaborative and managed environment for creating data integration objects. It also would be nice to take these objects and turn them into services available to other users with appropriate permissions and other applications in the Informatica portfolio. This shouldn't be too hard.

Summary

While Informatica has some strong competition in the data integration from behemoths such as IBM, Oracle, and SAP, as well as a host of small, nimble vendors, such as SnapLogic, Jitterbit, Boomi, Denodo, Kapow, Pentaho, Expressor, DataFlux, and Pervasive, the company is in a strong market position. Perhaps Informatica's greatest asset is not its products, but its people and processes. It has a capable, stable management team that has had little turnover compared to other Silicon Valley firms. And its disciplined, focused approach to the market means it has resisted the temptation to pursue new opportunities outside its core competency and take shortcuts on the path to growth.


Posted February 11, 2011 6:55 AM
Permalink | 3 Comments |

There has been a lot written and spoken about Business Intelligence Competency Centers (BICC). I'm not sure much of it has been accurate or helpful.

Most experts define the BICC as an overlay on top of an existing BI team, a hallmark of a wholly mature BI organization. Perhaps I'm naive, but I define a BICC simply as a corporate BI team.

Business Perceptions

Unique Discipline. That actually is a big statement. By forming and funding a BI team, company executives acknowledge that BI is a unique competency that is critical to the business and should be managed by specialists trained in BI concepts and techniques. In other words, there is a recognition that BI is a distinct discipline within IT, and that you can't throw run-of-the-mill IT analysts into a BI project and expect to succeed.

A Program, Not a Project. The formation of a corporate BI team--or BICC--also signifies that executives understand that BI is a program, not an IT project. It's not something you do once and forget about. They recognize that BI requires ongoing care and nurturing because it delivers an ongoing series of applications built on a scalable, extensible data management infrastructure that continuously adapts to changing business needs. It's a journey not a destination.

Business-Driven BI

That being said there are successful BICCs and not so successful ones. The hallmark of a successful BICC is that the business knows that it "owns" the BI function, not IT. It encourages the business to set priorities, define enhancements, and assume accountability for deliverables. In a highly functional BICC, the business gets involved and stays involved; it knows it only reaps what it sows.

So how does a BICC do this? Does it practice dark arts and mind control? The answer is far more mundane. The first and foremost task of every BICC is to recruit business people to participate on governance committees that define the direction, shape, and speed of BI development.

Executive Committee. The Executive Committee consists of business sponsors who provide funding, prioritize development, lead political interference, and help identify and recruit subject matter experts to serve on the BI Working Committee. In the beginning, a BICC may only have one sponsor; but over time, as it builds out applications serving other groups, it will and should acquire other sponsors.

Working Committee. The Working Committee is comprised of Super Users in each department. Super Users are the tech-savvy business people who gravitate to the BI technology when it is introduced and quickly become the go-to guys in each department to obtain information and build ad hoc reports. The Working Committee provides input on the data warehouse data model and semantic layer, and it helps select tools and submits requests for enhancements.

Super User Alliance. Super Users play a critical role in the success of any BICC. They are the eyes and ears of the BICC in each department. Unfortunately, Super Users are often at odds with the BI team because they are the people who build renegade spreadmarts that undermine information consistency. But rather than try to control the behavior of Super Users, successful BICCs actively recruit them to be surrogate members of the BICC. By putting the "fox in the henhouse," the BICC creates a business-driven BI program that stays close to the needs and wants of the business.

Business Recruits. Whenever possible, successful BICC's recruit Super Users and even high-level business executives to serve on the business team. What better way to make the BICC business-driven than by recruiting business people to drive the solutions? Fortunately, there are many business executives and Super Users who are eager to make the transition. Managing the delivery of Information technology offers challenges that appeal to many business professionals.

Best Practices and Standards

Internally, the primary responsibility of a BICC is to establish and document best practices for delivering BI functionality. This ranges from software development methods and project management processes to technical standards for naming database elements and handling ETL errors. Ultimately, these standards--the intellectual property of the BICC--will be critical in disseminating BI capabilities throughout the organization.

Distributed Development. Eventually, a BICC becomes the victim of its own success. It becomes a bottleneck to getting things done. Unless it distributes projects and development work to departments and business units, it will not move quickly enough to meet business requirements. However, it's critical for a BICC to establish standards before it disseminates BI development. Otherwise, you get BI chaos: lots of BI reports and data marts but no single version of the truth. Many organizations never recover from BI chaos.

Provision Data or Deliver Solutions?

Some experts believe BICCs should simply provision data; that is, build the data warehouse, data marts, and semantic layer and let the business departments build their own reports and applications. I believe it's critical for the BICC to also deliver business applications. Otherwise, they risk being viewed as a back-office function and cost-center that is easily outsourced. By partnering with the business to deliver critical business solutions, the BI team improves its business IQ and becomes viewed as a strategic partner, not a cost center.

Departmental Dashboards. To that end, BICCs should build a standard report or dashboard for each department that, if designed right, meets 60% to 80% of the information needs of casual users in that department. These aren't simple reports that a Super User can build alone; they require highly trained BI specialists working alongside Super Users to get right. The other 20% to 40% of business users' information needs can be met by Super Users building ad hoc reports and views on behalf of their colleagues.

Summary

Although some may think a BICC is an overlay on top of a BI team, to me it is the BI team done right. And you don't have to wait until you're a mature BI organization to implement a BICC; if you have formed a BI team, you already have a BICC!

To deliver a successful BICC, all you need to do is: 1) ensure the business continues to own and drive the BI function 2) establish best practices for delivering BI functionality, and 3) work side by side with Super Users to build departmental applications that meet 60-80% of business user requirements.

Of course, this is easier said than done. Please tell me if I have it right or wrong, and share your experiences if they can help others!


Posted February 8, 2011 8:58 AM
Permalink | 2 Comments |

I had the pleasure this week of talking about performance dashboards and analytics to more than 100 CFOs and financial managers at CFO Magazine's Corporate Performance Management Conference in New York City. They were a terrific audience: highly engaged with great questions and many were taking copious notes. Many were from mid-size companies. The dashboard topic was so popular that the event organizers scheduled a second three-hour workshop to accommodate demand.

I normally talk about business intelligence (BI) to IT audiences, so it was refreshing to address a business audience. Not surprisingly, they came at the topic from a slightly different perspective. Here's a sample of what they were thinking about:

  • Scorecards. The CFOs were more interested in scorecards than I anticipated. Since there are entire conferences devoted to scorecards (e.g. Palladium and the Balanced Scorecard Collaborative), which have largely attracted a financial audience, I thought that this would be old news to them. But I was wrong. They were particularly interested in how to cascade metrics throughout an organization and across scorecard environments.
  • Metrics. Not surprisingly, many found it challenging to create metrics in the first place. Most found that "the business" couldn't decide what it wanted or achieve consensus among various departmental heads. We talked about the challenges of "top-down" metrics-driven BI versus bottom-up ad hoc BI, and the tradeoffs of each approach.
  • The "Business." Since I've always considered finance to be part of the "business" it was surprising to hear finance refer to the "business" as a group separate from them. But, then it dawned on me that finance, like IT, is a shared service that is desperately trying to move from the back-office to the front-office and deliver more value to the business. Many CFOs in the audience have astutely recognized that providing consistent information and metrics via a dashboard is a great way to add value.
  • Project Management. The CFOs didn't have much perspective on how to organize a dashboard project. They didn't realize that you need a steering committee (e.g. sponsors), KPI team (e.g., subject matter experts plus one IT person) and a development team, and that the team doesn't disband after the project ends (i.e. project versus program management.)
  • Two to Tango. They also seemed to recognize that the business is the primary reason for failed BI projects not the IT team. If the business says it wants a new dashboard but the sponsor doesn't devote enough time to see the project through or free up the time of key subject matter experts to work with the BI team, the project can't succeed. Performance dashboards must be business owned and business-driven to succeed.
  • Requirements. Many CFOs also didn't realize that you need to development requirements (i.e., define metrics) before purchasing a tool. They admit that many projects they've been involved in have put the "cart before the horse" so to speak.
  • Technology. Not surprisingly, the CFOs had little understanding of the tools and architecture required to drive various types of dashboards. I don't talk much about dashboard technology and architectures to IT audiences because they know most of it already. But it's all new to the business, even basic things like how the data gets into a dashboard screen.
  • Build Once, Deploy Many Times. Perhaps the biggest revelation for many business people was the notion that you build a dashboard once and configure the views based on user roles and permissions. They didn't understand that one dashboard could consist of separate and distinct views for sales, marketing, finance, etc. and that within each of those views, the data could vary based on your level in the organization and permissions.
  • Change Management. Most recognized change management as a huge issue. Most had experienced internal resistance to new performance measurements and were eager to share stories and swap ideas for ensuring adoption.

What I Learned

I learned a few things, too. First, three hours is not enough time to address all the topics that business people need to learn to have a working knowledge of performance dashboards. Thankfully, I covered the most important topics in my book, "Performance Dashboards: Measuring, Monitoring, and Managing Your Business" which just came out in its second edition.

Second, I realized I have a lot to offer a business audience. Although I've been addressing IT audiences for the past 22 years, the way I present information resonates better with a business audience. It's not that I avoid technical issues; rather, I place technology in a business and process context and provide pragmatic examples and advice so people can apply the information back in the office.

Hopefully, I'll be delivering more business-oriented presentations in the coming months and years!


Posted February 2, 2011 11:23 AM
Permalink | 1 Comment |