Lassoing Eels - Building a Coordinated Oracle Reporting Strategy

Why is it so hard to pull all the Oracle reporting (and non-Oracle) tools together and use them in a coordinated way across all user and organisational requirements?

I would suggest there are four competing forces challenging the IT department, as it tries to unscramble reporting:

  • Visual/people requirements.
  • Business architecture.
  • Technology options.
  • Investment model.

These forces then lead to the following disconnects:

  • Can’t ask for investment without understanding what is possible.
  • Can’t deliver trust without a common understanding.
  • Can’t get a common understanding with pictures alone.
  • Must involve the users for buy-in but they need to understand context.
  • Hard to build a POC and a strategic platform.

Ok, so…

Your CIO has just had a visit from Oracle and says that we must implement Exalytics and BI Applications and that he has been told it’s a simple installation.

  • How much is it going to cost?
  • When can we be live?

Key users in the strategic planning office have just seen a demo of Tableau or similar and know this is the right solution. They’ve told us we just need a server and we can be up and running. When can we have a server?

We have so many reporting solutions, no one knows which answers to believe! We really need to get a grip!

We’ve spent how much on that Data Warehouse (DW)? You are just going to have to do what you can with this money, otherwise we will need to make some IT staff redundant to pay for this.

It’s key to understand the momentum in your organisation before seeking funds to start a new work package.

Business Architecture – some of you will have come across The Open Group Architecture Framework (TOGAF) an appallingly named approach to business design that is really pretty useful – our Enterprise Architects (EAs if we have them) are busy modelling the business and information architectures of the organisation. How do we align what we are doing with their perspectives? Can two projects run in parallel?

And Oracle doesn’t make it easy either.

Given you will have a number of Oracle and partner salespeople on your doorstep selling you the virtues of each, where do you begin?

  • Should you invest a significant sum for prebuilt content, or can you install Endeca and be up and running in a few hours?

And then there are all the non-Oracle products like EIS and Insight Software, Qlikview and Tableau.

Visual/people requirements. Users want reports in minutes. They have seen the demos from Tableau, so they know it’s ‘really easy’!

  • They want them on mobile devices.
  • Different users want exactly what they had before that they trust and don’t need to do any work to (no filters and slicing – “just give me the numbers I need in a Spreadsheet”.
  • A 3rd group wants to play with data, from both inside and outside the organisation. They’re often a bit technical but they certainly want to uncover interesting new insights. They may be used to complicated predictive modelling or forecasting cubes. Should we force them all down one route for consistency and to cut down on the excel cottage industry, or is there a way we can retain some control and governance, yet still give them what they need to do their jobs?

Technology options. I’ve already listed a myriad of Oracle reporting options and then add in all those non-Oracle options that are used, or liked by your people, and you can see where the title evolved from. How can we control the deployment of the many technology options? How can we visually demonstrate the possible, so people can be inspired, while at the same time managing expectations?

Understand where everything fits together. Research the actual (not perceived costs) including:

  • Implementation.
  • Configuration.
  • Training.
  • Skills transfer.

Where does Cloud Analytics fit?

It’s new to market but looks like a good way to start. It’s without the fuss of installations and management. It doesn’t include certain elements like BIP, Maps, Essbase and Smartview (Excel) but definitely includes Mobile.

Discoverer is in the departure lounge, but beware the Operating System. Take a look at options for migrating to OBI, it may not be as hard or expensive as you think!

Engineered systems don’t really fit within a user dimension (aside from being fast – always good).

Sometimes the only option you have is to mix and match your reporting tools, usually because you already have some tools in use. Work with what you have; build a coordinated strategy; know strengths and weaknesses; create a timeline to move to a consistent and coordinated environment.

Investment model. Most (perhaps all) organisations say they want better reporting, but it can be very hard persuading a Financial Director of the value of a new investment. Most of this is down to past failures, where reporting projects promised so much and delivered so little. Some of it is down to the constant demand for data, which means there is no time left to think about the data.

What can we do to break the cycle and encourage appropriate investment?

“The need for analytics does not match most organisations’ skill requirements; vendor hype for cloud-based BI is not reflected in revenue and customer adoption; and there is a struggle between centralised and decentralised organisational models of BI delivery.”
Gartner, 2012

What I am suggesting here is not a formal methodology, rather an accumulation of experience and slightly left-field thinking.

I recently heard that a thought leader sometimes needs to dance on his (or her own) for a long time before people join in. Maybe I’m dancing now?

There is no getting away from the need for a solid information architecture. Anyone who has heard me speak in the last couple of years, will know this as my mantra. I do not believe it is possible to deliver a good analytics solution without understanding not only what the business data means, but also where is owned, stored and manipulated.

EAs are often accused of delivering only pictures, and there is a danger, hence we need to build a plan that includes the other 3 dimensions.

Determining the distinct end user communities and speaking to them about their visualisation requirements at a high level will help to formulate a visualisation requirements plan.

Understanding the technology options…

 …may be the next step? Definitely before asking for the users’ detailed requirements. A series of demonstrations of what might be possible with different options to different user communities.

It is worth explaining the different economic scales for instance between OBI and BI Applications. For the prebuilt BI Apps, don’t demo out of the box! Demonstrate against your data! It will make a big difference to the users. Your partner should be able to do this with around 5 days investment, so not a big ask in the scheme of things.

Next, you need to drill into more detail with the business users about their requirements. Now they have seen the software options. This will determine the scope of their needs and will, in turn, inform the business case on build versus buy.

Taking the case to the decision-makers is the next step, and it is vital to show them what they are getting, with options and phasing. Also, it is important to show them what happens if they don’t go down the strategic route. It may be teaching some of your grannies, but surprising how often reporting does not get to the top table.

You could take two routes from here.

My preferred route would be to build and deploy near-vanilla prebuilt apps, perhaps including Hyperion, as this is the fastest way to business value. If you are brave, and if you have the executive buy-in, buy the Oracle prebuilt apps across the board, so that you have a strong, fully supported and growing platform (with Oracle’s own investment) across your entire organisational spectrum.

Even if you don’t have Oracle apps in some areas, it is much easier to repurpose ETL from a non-Oracle source app, than to build a BI App from scratch if the scope warrants that. Remember that the cost to build out a reasonably thorough Extract, Transform and Load (ETL) Data Warehouse (DW) from Oracle (or non-Oracle) apps could be significant.

One university I have worked with has taken around two years to deploy a reasonably simple custom OBI solution and that’s not down to the skills of the developers.

Ask the users using the solution what bits they would like to extend as a Phase 2 activity. You won’t be able to retire all old reports until P2 has been completed. This is the approach Network Rail took.

An alternative approach, should the business benefits of prebuilt analytics not stack up, would be to design from scratch. To do this DON’T start by designing a data warehouse. Make sure you already have an information arch and then model that as a DW. This will ensure you have full traceability back to the end users. Then you can unleash the DW specialists, who can work with vanilla OBI, to build out a structured DW with a solid presentation layer.

Either way, you get as fast as practical to a part-complete BI solution, with prioritised requirements and timeboxed agile delivery.

Where there is no natural fit between the end users needs and the OBI outputs, for instance with information discovery or predictive analytics, consider the ‘edge’ BI products in the Oracle stack or indeed non-Oracle products.

Where you already have for instance Tableau licences, don’t necessarily throw it away – instead point it at the DW, rather than the individual datasets it would currently use. That way the users keep their beloved tool, but the organisation can still implement a strategic platform.

How easy is that?

Not very, clearly! Get some advice from people who understand projects, not just technology. Don’t underestimate change management; get users involved as early as you can; manage expectations; train frequently whether in classrooms or with easy to use self-study such as UPK; test how people are using the solution continually and keep evolving! As soon as the investment dries up, the solution is bound to fall, over time, into disrepair. But if you’re happy to throw investment into managing your source systems, why not into your reporting systems?

Conclusion

  • Deploy under the radar and then ask – “What can’t you do?”
  • Get an understanding, in context, of any prebuilt content – 5 days Proof Of Concept.
  • Don’t believe all the hype, see for yourself!
  • Build for ‘perpetual beta’, productionise with a business case.
  • Drive for strategy, deploy in stages.
Share This