Practical Business Intelligence

I recently had the chance to sit down with Shawn Blevins who presented for SAP BusinessObjects at the ITA BI Roundtable in September. We called it the BI Tool Vendor Grudge Match.

Here’s what we talked about, with my commentary added …

Background

Jeff: Tell me a little about yourself, your background.

Shawn: I started out by having my own consulting company called IntelliThought in Tennessee. We had a tremendous SQL install for Eastmen Chemical and moved them off of AIX over to DB2. From there, I went over to Accenture for about 18 months but then Microsoft came calling. I was at Microsoft for almost five years as a SQL Server technology specialist when I started. I left to go over to the management side and started the solutions specialist community which was designed to build solutions using SQL Server as well as the other Microsoft products. A lot of BI solutions, a lot of business decision support systems. Then I went to Oracle and ran the application server sales group. It was BI solution building work under global sale services. I talk a lot about build-based BI systems, because I think that’s the mindset of the world when you’ve grown up with Microsoft and Oracle.

When I came to SAP, I began working on the BusinessObjects acquisition. We [at SAP] realized they were a vendor that truly had an end-to-end, productized, standardized platform that matched SAP’s productized ERP solution. It became evident to us what we needed to do–to get out of the BI tool business and buy someone that could provide full top-to-bottom standardization, metadata, and master data … to have them consume the key metrics out of our ERP platform and make them available to our customers. We’re not trying to buy additional vendors. We believe in a complementary partner approach. We made the announcement so we weren’t going to disrupt BusinessObjects or force any SAP technology in there.

So, I’ve come full circle from building it to making money on building it as a consultant to selling the vision “if you buy these tools, learn them, and build a lot of complex pieces, then eventually you’ll have a data warehouse” to where I’m at now. I’ve evolved to a focus on business execution instead of having to wait for execution while you go down into the IT/technical weeds and build a bunch of software. Using a platform like BusinessObjects, you can depend on a robust, full-featured reporting solution delivered by a company that sells the solution and its configuration and discussion of what’s the best way to implement the solution, rather than a toolbox you have to invest a bunch of additional work into.

Jeff’s Commentary: Even from my first impressions of / interaction with Shawn, it was clear to me that he was A) very experienced, B) very knowledgeable, and C) very charismatic. He certainly livened up the Grudge Match, and clearly brings a lot of enthusiasm to whatever he does. Shawn’s brief introduction of his career demonstrates that this is not his first bar-b-que. He’s worked for a number of big shops, been exposed to several competing philosophies in the sale and delivery of BI tools. And he’s implemented solutions for large and small companies in lots of contexts. This makes him an ideal candidate to have an opinion on where BI is going and on how to appropriately approach complex BI initiatives. I was eager to get his thoughts in this brief interview. For more about Shawn’s background, check him out on LinkedIn.

Considerations Before Launching a BI Initiative

Jeff: What is the number-one thing companies should consider before launching a BI initiative?

Shawn: The first thing is you need to do some CSI forensics. Sometimes BI can be a little like Monty Python and the Holy Grail … a lot of crusades, but what really became of all of it? What separates a successful, game-changing BI project or a BI initiative from the 647 that happened before? In my experience it comes down to two or three things. First, it comes down to integrity–not just of the products or approach or planning, but the integrity of the people that hold themselves to a certain level of commitment and excellence. Once that integrity begins to change into taste or a favorite tool, product or vendor, you’ve lost your integrity, and your initiative will begin to slide. You need to think about your CFO standing in front of your shareholders or a bunch of financial analysts, or even worse, standing in court having to explain why he missed his forecast or why information got out from under the business or why there wasn’t governance that prevented the fraud or misuse of customer information. Those are the kinds of things that override taste or preference or religion or background.

Most BI project initiatives need to be thinking like a CFO or a board member with the end in mind from the very beginning … putting the right outcomes out there at the onset of the project. This is because BI projects, more than any other projects, really play in to IT’s need to be cool and IT’s need to craft and build complex things. The key is to move from being an engineer (building things) to being more a strategic business leader (driving value). Think of it in terms of instead of being a field commander or somebody who crafts villages, you need to think of it like a Macarthur or general who says, “Where are we trying to go? What market share are we trying to take? In what ways can I empower this business to grow and acquire and merge?” To build those kinds of thoughts is what makes a BI project truly strategic. It also improves careers. But if you take the other approach–the “build something really cool” approach–then you’re quickly down to the weeds comparing vendor A and B and it becomes a game of taste.

Jeff’s Commentary: First, I’m impressed about Shawn’s ability to weave a Python reference into the interview. Second, I couldn’t agree more with him on the content of his response. He uses words like “commitment” and “integrity” to describe the building blocks necessary for a successful BI initiative, where I use words like “intentionality” and “discipline.” At the end of the day, we’re talking about the same thing: It’s not necessarily about the product; it’s about the people, processes, policies, standards, data involved. All these things require integrity–Shawn’s word–if you’re going to be successful.

His point about alignment between the Business and IT is also crucial. The days of business guys being ignorant to technology and having it work like magic are over. So are the days when the IT guys didn’t need to understand and speak the language of the business. Successful BI requires a close partnership between business and technology leaders, including technologists who can imagine themselves in the shoes of the CFO in Shawn’s proverbial board meeting.

Most Common Mistake

Jeff: What is the most common mistake you encounter in a company’s thinking when approaching BI?

Shawn: It’s the idea that we’re one interface away from greatness, or that we’re one data schema away from greatness, or that we’re going to build something amazing that’s going to achieve greatness. Or, perhaps thinking that your company has very unique needs. This betrays that you don’t really understand business, especially the competition, works.

The fact is if you go into anyone’s kitchen and you open the utensil drawer there’s going to be a knife, a fork, a spoon, etc, because that’s what we all eat with. Maybe there’s a chopstick in a few of them, but the key is that you can use common tools and eat just about any kind of food. So people need to standardize tools and then they can think about what kinds of food their customer eats. Whether you’re buying your food at the market or growing it yourself, regardless of sourcing, you need to think about the delivery. The same is true of technology. You need a standardized way of delivering data, because it’s the standardization that drives adoption and use. It’s not how cool you are or how in depth or complex the data models need to be.

The reason Excel is everywhere is because people know how to use it. Even though there may be a million sources behind it people dump it all in a spreadsheet and manipulate it themselves. The way you stop that is … you don’t stop that. You give them better and richer tools and make them more independent and self-servicing so they can continue to do what they were doing but in a way that doesn’t break or isn’t stringently tied to standardized data models or data schemas. You have to empower them, but empower them in a standardized, easy to use way. If you miss that, or if you think you’re going to create or craft something new and unique, then what you’ve effectively done at that point is cut off the end user’s ability to act. They have to learn what’s in your mind and how you built the data model or how you built the system. So use a knife or fork and spoon and concentrate on a consistent, standardized way to deliver it.

Jeff’s Commentary: This section is also basically focused on not getting the cart before the horse. BI is not a technology, it’s a disciplined approach to data. I love his “one interface away from greatness.” There are lots of companies out there that believe they’re one tech purchase away from perfect efficiency and data-driven clairvoyance. That’s a lie, plain and simple, and I love that Shawn calls it out.

I would also add to Shawn’s call for standardization – a call for simplicity. Enter one of my mantras: If your BI report or dashboard is not mind-numbingly intuitive, then it will not reach its potential.

Future of Business Intelligence

Jeff: What’s the big thing to look out for in the BI space in the next 5 years?

Shawn: The first thing is that you should be thinking about inter-business BI. This is a whole new market. What I mean is that you have tools in your company for reporting and forecasting and I have tools in my company for reporting and forecasting, but we need to think more like Microsoft and Wal-Mart. For example, the Wal-Mart model is: “I (Wal-Mart) will guarantee that I’ll buy these widgets from you (mom-and-pop widget manufacturer) at a nickel a piece, but you have to: a) make five million of them, and b) you have to have them here by Tuesday. If you do all that, I’ll buy them for a nickel a piece.”

Imagine if that model went across all business and we all agreed to that you’ll ship these in 2.5 days and you’ll do it in less than six minutes to pack and ship. If there was some way to sit in the middle and have a reporting tool and a forecasting tool that managed SLAs to contracts and agreements between companies, it would be amazingly valuable. You’re going to see a standardization in that SLA-type KPI reporting between multiple business entities. The first vendor who can say from the perspective of the cloud that the two companies have these expectations and are performing these KPI’s against a set of inter-company SLAs, will rule the field. That’s where you’re going to see the BI industry going.

Jeff’s Commentary: I think Shawn’s insight here is very good. I’m also seeing calls for truly federated data warehouse models, and these are far less standardized or vetted than traditional models. Data governance, master data strategies, data warehouse architectures, and much more will ultimately have to evolve to support multiple, distributed businesses working together.

Closing Statements

Jeff: Would you like to make any kind of closing statement?

Shawn: I want everyone to know I am incredibly impressed with both the people involved at Capstone and folks from the ITA. I’m impressed with the focus and intensity you guys put toward this. This is the right pursuit, this is the right conversation because IT itself is changing. There’s a great movie called Tucker and it has Jeff Bridges in it, where he’s a guy in a garage who built a Tucker automobile. Now you cut to the big three automakers but they are now struggling because Toyota and Honda are killing them. They’re not struggling because they don’t make good cars but the perception is if you want standardized, reliable quality, you want a Toyota or a Lexus. They’re struggling because of the perception of complexity and the risk of not knowing what you’re doing. Similarly, there’s a shift happening in IT quality. The people in the room that are asking hard questions are focused on that shift and what’s the right thing to do for their company.

Jeff’s Commentary: Thank you so much to Shawn for his kind words and for being willing to chat with me on the record. I appreciated his passion and insight both at the Grudge Match and afterwards in this interview.

Two more terms that have crossed my radar recently … again …  I know this will shock you, but I thought I’d opine to set some expectations / dispel some myth …

What is “Open Access to Data”?

Open access does NOT mean that everyone has access to everything, or that necessarily any one person has access to everything (from a business user perspective). Here’s a definition that will make some of you squirm.

Open access: All users in an organization are granted access to all data in the organization through a defined, intentional, repeatable process, in accordance to their individual role and prioritized need for that data.

So, it’s not giving everyone access to everything, it’s giving everyone access to the RIGHT things to improve their job over time. And remember that this is more evolutionary than revolutionary in healthy organizations. Those who target a big bang frequently end up with a bum fizzle. The early-and-continual delivery of value is far preferable, in both the short and long terms.

What is “Self-Service Data”?

Industry pundits hopped up on the buzz of business intelligence throw around the term self-service with impunity, hoping that BI will deliver to them some magic universe in which every conceivable reporting or analytic requirement can be accounted for by a “self-service portal” front end to the wonder of the data warehouse. The truth is that no such indefinite and infinite vision to the horizon is possible. Even in the most ideal world, you will never experience a 100% self-service environment.

Here’s what BI will not do for you in this realm …

There are too many people in your organization devoting too many hours to manually massaging and manipulating data in response to totally unpredictable (seemingly random) requests for aggregated, cross-referenced, or other newly-contextualized data sets. BI does promise that over time, these manual efforts will be replaced with a uniform data model, capable of fielding ever-broadening, increasingly complex knowledge requests from the data. This will free up your data/statistical research experts to be more strategic and attend to a higher-order of complexity, but the demand for them will not go away. Success means making these resources more strategic over time, not eliminating them.

What BI will not do for you …

Alchemy, card tricks, cold fusion, or other magic reliant on some illusive silver bullet. BI is more about discipline and intentionality than any form of magic. No overnight miraculous change of any kind will occur.

Summary

Don’t deal in all-or-nothing scenarios! Companies expecting it to take 3 months (or even 3 years) to go from 100% manual ad-hoc request management to 100% total automation of all reporting are going to learn to live with disappointment … the hard way. Ask yourself, “What would you give to gain 20% automation per year at the cost of creating 10% new demand for higher-order higher-complexity higher-value ad-hoc requests (which drive more manual request management and therefore drive new requirements of the BI environment)?”

This is a far more realistic scenario.

Post 2 in a series of 4, in which I share my thoughts on how our vendors did at the BI Tool Vendor Grudge Match last week, and on the details of their presentations. You might also check out my summary post earlier this week on PBI.

Company: SAP BusinessObjects
Presenter: Shawn Blevins, Global Group Director
At SAP: 5 years
In BI: 15 years
Gift selected: Capstone Hat

Using the banking system of late, Shawn said, “It’s not enough to provide volumous access to information, and expect good decision-making to happen as a result.” AMEN!!! This was the best statement made during the presentations made at the Grudge Match. I agree 10,000%.  I feel like SAP focused more on the solution of BI than on a product, and while that was a little off topic (per se) for a Tool Vendor Grudge Match, it still “made my heart happy.”

He says “Context” is what is missing from BI today, which is exactly in line with what we’ve talked about over and over: turning “data” into “actionable knowledge assets.” It takes more than just context and getting context takes a lot of people, process, policy, data, and technology, but he’s definitely on the right track … especially for a vendor presentation.

“The problem is not BI and it’s not the tools, it’s that we’re [backwards] in the way we think.”

Love the analogy to the airplane he uses. BI should provide automation in the way that most of the time the plane flies itself while the pilot reads. Only when something happens that the computer can’t deal with does the average pilot kick in with all his expertise. Also, he referred to the black box … full of information, but it’s a little late when you’re “fishing it out of the lake.” Great stuff. Analogies are your friend in helping lay people navigate the complexity in concept that is BI.

The “Excel drug” …  beautiful … Shawn claims that BusinessObjects will help get your business users into Excel rehab, so that they’re less likely to break off pieces of data and create new data sources, and more likely to use the system to get what they need from data that remains connected to the single source of truth in the enterprise data warehouse.

He claims that SAP is “other vendor neutral” … that it’ll work with whatever you have in house. This is a tall order. “Why go with the market leader?” he asks. “More support for a wider set of architectures, worldwide services and support, a bigger ecosystem, etc. We work with everybody.” His point is that BusinessObjects is designed to sit in front of any solid foundation of data in the backend. To an extent, of course, I agree with what he’s saying, but there are definitely pitfalls associated with the BusinessObjects product that he’s glossing over. It certainly does not support every complex query you could conceive of in the independent way he’s describing, for example. Also, BusinessObjects has a tendency to silo your data in universes. As long as the universe is truly universal (which it almost never is), then you’re fine. But end up with 100 universes, one for each department (a common destination for firms that build “bottom-up”, btw), and you’re in big trouble. Integrating those universes is definitely not the seamless fun that he’s making the product out to be.

So, not perfect by any means (what is?), but definitely a great presentation, exactly on target conceptually, and SAP does have a very powerful, very significant product.

Overall, I grade this presentation:  A

Part 1 of 2:

Part 2 of 2:

The days of locking a bunch of smart people in a room until they understand and deliver on a static set of narrow requirements has been over for a while now. But if there was ever any doubt, the cross-functional, politically charged, somewhat esoteric requirements of business intelligence should put an end to the debate. And if that doesn’t do it for you, how about the insane number of BI projects that fail every year due to lack of communication and coordination between IT and the business.  (Need to read more?  Try here or here or timeless truths from a few years back, here.)

I would suggest that one reason why so many BI efforts fall short (or outright miserably fail) is that they are approached fundamentally wrongly. In my mind, all the articles cited are saying similar things: there was too much “lock smart guys in a room” and too little “collaboration between IT and the business.”

*pounds table*

I want process agility.

I want continual interaction with the end user community, business requirement drivers, and project stakeholders.

I want more communication, milestone sign-offs, RAD modeling, and the like.

Maybe you could get away with writing your Visual C++ app in a vacuum 12 or 13 years ago, but those days are long gone. If you don’t put the business guy on the development team (he’s called the Product Owner … feel the Agile software development love … see also here and here), make cross-functional business teams responsible for the requirements, the priorities and the data (read: governance), and develop software incrementally in short iterations, then I submit hitting the fast-moving target of the organization’s requirements for BI will be next to impossible.

“The world is changed. I feel it in the water. I feel it in the earth. I smell it in the air. Much that once was is lost, for none now live who remember it.”

This is the opening line of J.R.R. Tolkien’s The Fellowship of the Ring. It’s also a great way to describe the state of the IT universe. These changes are significant, and have not only served as a driver for the need for Business Intelligence as a science, but have greatly impacted the way BI must be implemented in an organization for it to reach its maximum potential.

Globalization, the maturity of the web, commoditization of ERP and CRM systems (among others), struggling economies, and the like have resulted in many different changes. Today I’m focused on the impact these and other forces have had on requirements management … particularly as related to your BI initiative. The truth is that gathering, understanding, managing, and implementing on business requirements these days just isn’t the same (read: isn’t as easy) as it used to be. And I thought it’d be valuable to throw out a few of the pitfalls out there, and throw out a suggestion or two on how to navigate them.

Requirements in the BI universe are:

… Hard to Nail Down

The truth is that business owners don’t really know what they want. I think this has always been true, but the complexity and abstract nature of much of BI has made an already difficult problem worse. With traditional IT projects, gathering requirements was about getting a business leader to tell you what a single piece of technology had to do for them in a very limited domain to make a very specific source of pain go away. Gathering requirements in the modern era for which BI is the solution is about asking that same manager (and his boss, and his boss, and managers / bosses in 5 other departments) to tell you what report or dashboard they want from data they didn’t even know the company collects to help them do something they already do better or mitigate some vague sense of pain that they can’t define. BI is still typically just too “out there” for many business leaders to give IT leaders succinct requirements. And let’s face it, BI’s still pretty “out there” for a lot of IT folks too, so that doesn’t help.

… Cross-functional

Business Intelligence, if on the path to meet its full potential, is not implementing one manager’s or department’s or group’s requirements; it’s attempting to implement the requirements of the entire business. So, now you have to get a bunch of business leaders–who may or may not talk, may or may not know what each other do, may or may not be willing to share IT bandwidth or priorities, may or may not have coinciding schedules to make a meeting, etc–into a room together, and get them to understand and agree on what a single system can do for them.  Ugh.

… Politically Charged

Enterprise-wide BI inherently means there are a lot of cooks in the kitchen, and it’s a given that each will have their own agenda. This is a natural outcome of the cross-functional reality of BI requirements. But it’s more than that. The business processes that are typically on deck for becoming a part of the BI initiative–for a widget company, the “sell widget” process, or for an association, the “new member joins” process, or for a group of investment bankers, the “risk assessed” process–are the most core processes in the business. They are the most important processes, have typically been around the longest, “enjoy” the most scrutiny, have the most people believing they know best how to do them, engender the most heated debate, and are surrounded by the most safeguards / people unwilling to change the way things are. This makes them pretty hard to deal with and makes gathering requirements about changing them a non-trivial activity. Who has the authority to order the change? Who really knows what’s best? How do you get all the cooks in your BI kitchen to agree on which spices to use (or sometimes even what to call the spices)? The fact is that they very things that make these processes so hard to work with are exactly the things that puts them in the in cross-hairs for your BI initiative in the first place. Thus, hard by definition.

… Constantly Changing

Of all the changes the reality of our times has wrought upon business, perhaps the pace of change is the most significant. It’s not just that things are different, it’s that they keep changing. And the incredible agility with which these changes must be addressed in order for BI (or IT in general for that matter) to demonstrate crucial value to the business is staggering.

… Typically Shrouded in Eroded Credibility

The fact is that too many attempts at BI (or other “killer app” concepts billed as “silver bullets”) have been made in too many organizations without understanding that there is a right and a wrong way to change. (I’ve got another post brewing on this topic.) First, stop billing BI (or the data warehouse or CRM or ERP or Web 2.0 or cloud computing or whatever else might get you excited this week) as the magic answer to anything. It’s not. These are tools in the toolbox of the business; nothing more. They will not turn the world rosy or solve world hunger. And they certainly won’t without incredible cost and intentionality and discipline. No wonder IT’s credibility has been tarnished in the eyes of the business. Information technology geniuses have spent far too much time selling the next cool thing, and far too little time listening to the needs of the business and investing in learning to think like their systems’ stakeholders. As a result, initiatives have cost too much for too long, delivered too little too late, and have generally lowered the trust the business has in IT to advance the mission of the business (which is what IT’s role is in the first place).

So, now what?

Here’s the bottom line … Talk less, even listen less, and observe more. And for Pete’s sake, embrace the reality that technology is not going to solve the problem. Good people following good processes and practices are.

If it’s not you, get someone in your shop with a trained eye, and spend time with the business users. Observe the way the organization works and doesn’t work. Really get to know the pain of the person / people who will be using that report or dashboard you think you should create. Understand the vision, mission, strategic goals, and key performance indicators of the organization. If you can’t articulate the following key elements for a BI software component, then you aren’t ready to build it:

• How this component will help achieve the goals of the organization?
• Who needs to understand the value of the component and the unit of measure in which they measure value?
• What is the pain that this component will alleviate and who is feeling it?
• Where does their pain fit in the overall priorities of the organization?
• What is it going to cost the organization to build and not to build this component?
• Who are the people who have the most to gain and who have the most to lose if you build this component?
• Who are the people who are the most skeptical that you can deliver value with this new IT wonder?

Also, get some processes and tools in place to help your cross-functional, politically-minded requirements drivers to collaborate effectively. On the tools side, companies like Balanced Insight and 37signals can help with that. On the services side (assessment, advisory services, etc), so can companies like Capstone (my company).

Last, there’s the myriad best practices that are beyond the scope of this post, but which I’m sure we’ll discuss here over the life of this blog. Some examples off the top of my head: start small, build iteratively and incrementally, interact frequently with the users / stakeholders, deliver value early and often, target detractors with quick wins, embrace the 80-20 rule, don’t wait for data to be perfect before you expose it, learn to love the phased rollout, start with bedrock data and radiate outward from there, avoid silos in your data warehouse, always get sign-off on project milestones, and the list goes on.  If there isn’t a blog entry out here on every one of these concepts in the next 6 months, then I’ll be a monkey’s uncle. So, stay tuned.

Yes, this is more than you needed to know to whip out a VB system or an ASP.NET app in days gone by. But that’s to be expected. If the complexity of the requirements has skyrocketed, why would the process to deliver on them not be more complex as well? Don’t long for the good old days (where they really?). The potential power and value offered by BI and other IT constructs in the modern era is just as significant (if not more) than those of 10-20 years ago. They just require a new way of thinking.

Introduction

The goal of Business Intelligence (or “BI”) should be to assist business in maximizing the value of their data.  Whether companies know it or not, their data is one of their most valuable assets for strategic and operational decision-making.  When done right, BI has the potential to deliver highly relevant, highly targeted applications, reports, and dashboards, designed to maximize an organization’s ability to gain specific, actionable knowledge from their corporate data. That means valuable tools like statistical analysis and predictive analytics, and cross-referencing data from different departments to mine for trends. Valuable stuff!  When done wrong, BI has the power to create organizational, political and technical debacles of Biblical proportions.  Not good.

So, how do you navigate the minefield of complex topics like Business Intelligence?  What about important supporting topics like data warehousing, data governance, data stewardship, etc?  How do you make sure that the decisions your organization is making are the best possible ones – data driven, insightful, and packed with value for your business?

In this edition, we’ll take a slightly different approach in discussing BI best practices.  Let’s talk about a few of the things you really shouldn’t do, if you want your Business Intelligence initiative to succeed.

Bad Idea #1:  Pick the Technology First

Myth: The technology is the hard part

Many see Business Intelligence or Data Warehousing as technology problems.  They get budget and approval, do lots of research, have vendors give demos and promise endless mentoring … all in the industrious (if misguided) attempt to “buy” Business Intelligence.

Unfortunately, BI is not, and likely won’t be soon, a technology platform.  It doesn’t come shrink-wrapped … at any price.  It can’t be bought from anybody like you’d buy a copy of Windows from Best Buy.  BI is a new way of thinking, best practices molded by nearly two decades of successes and failures, architectural paradigms for data and software, changes to your organization, overcoming political hurdles, and much more.  The truth is that the technology is actually the (comparatively) easy part.

Here are some hurdles I’d recommend overcoming before you even talk about the technology you’ll use to undergird your efforts…

• Securing executive commitment (including funding)
• Building consensus among business functions (and conforming data dimensions)
• Establishing effective data and IT governance
• Developing a change control management plan to control scope and growth
• Accurately defining requirements
• Figuring out how the system will be supported after it’s built
• Etc, etc, etc

So, let me suggest that there is an order of priority to focus on when launching a BI initiative or project:

1. The Plan – What exactly are you trying to accomplish, and how does it support the organization’s KPI’s?
2. The People – Who is going to accomplish your plan?  What roles will they play?
3. The Process – How will this awesome plan be accomplished?
4. The Technology – Now that you have all this in place, let’s talk about what tech you’ll use to support the plan, the people and the process.

Read More

Visit Capstone’s web site to continue this article…

Article Index

Introduction
Bad Idea #1: Pick the Technology First
Bad Idea #2: Acting on a Wrong View of the Data Warehouse
Bad Idea #3: Ignore the Political Landscape
Bad Idea #4: Leave out Critical Support Functions
Bad Idea #5: Don’t Address the Question of Data Ownership
Conclusion