Examining the ongoing challenges of delivering high-quality, value-added ERP services in Higher Education.


Friday, September 14, 2012

The Complicated Skillset for Modern BI

The requisite skills for success in Enterprise IT are constantly evolving. But whereas once upon a time this evolution might have followed linear / predictable paths with a sub-discipline (programmers: COBOL to Java; DBAs: VSAM to RDBMS; App Developer: Oracle Forms to OAF) today we confront increasing ambiguity around the very definition of the world "developer" and an ever-more-porous membrane between sub-specializations under the broad IT umbrella. To make things even more complex, modern technology -- my focus here is on Business Intelligence, but the case extends to other business applications -- blurs the line between end users and analysts, plopping robust features previously hidden behind the curtain right at the user's fingertips.

This shift in paradigm is demonstrated below:

Figure 1: The legacy model, with clearly delineated roles and responsibilities, skills, and knowledge, with articulated hand-off moments between groups

Figure 2: A blurry model with overlapping responsibilities, requiring more extensive cross-training and relinquishment of control by certain groups; as application customization has moved from code to configuration we have been forced to confront this model.

Figure 3: The my shop faces in deploying Oracle Business Intelligence (OBIEE) (but hardly unique to that vendor or that platform). Here, technical developers, functional (quasi-IT) analysts, and business users are almost indistinguishable.

There are clear advantages to the third paradigm: it broadens the base of potential report "authors" (perhaps a better word than "developer") and eliminates the necessity for middle-men and low-value-added hand-offs. I have argued that it ought to off-load certain changes to the business users so that IT staff can focus on harder stuff. 

However, when I rolled up my sleeves and put my own hands on the technology (OBIEE) even I was somewhat shocked by the dizzying array of skills required to implement solutions:
  • Domain Expertise
  • Business Analysis / Requirements Definition
  • Quality Assurance
  • Data Modeling
  • SQL (and not just basic SQL, either...)
  • Web Development (HTML, JavaScript)
  • User Experience (UX)

This is a lot to ask for in one person. On the one hand, your typical technical developer does not have deep domain expertise and may be accustomed to receiving explicit instructions rather than working with end users to define the requirements; on the other hand your crack functional analyst may be able to execute drag-and-drop reporting but balk at writing CASE...WHEN statements. And only a very select few will come to the table with robust usability and graphic design talents.

When you click "New > Dashboard" in OBIEE, this is what greets you:



To fill this void requires asking and answering "web developer" questions. How much information should appear here? With what density? How will it scale based on individual screen resolution? User device form factors: the 19-inch desktop monitor vs. the 15-inch laptop vs. the tablet vs. the iPhone? And then there is the issue of navigation. Where will users click? What will the expect to happen when they do? What additional information belongs on the page? Look at all those options -- links and images, embedded content, text (don't be deceived -- this really should say "HTML" and/or "JavaScript"), or actual report artifacts?

As G.I. Joe taught me many years ago, "knowing is half the battle." My group has started to pay more attention to user experience sessions at conferences and resources such as Oracle's Usable Apps and Patterns pages. I launched a style guide on our Confluence portal: fonts, font sizes, alignment, color palette, text styles, icons and images... This is not the way we think! But this is our world.

We are also trying to define criteria to route emerging requests for reports to the right type of "author" -- if advanced visualization is going to be required, let's get that over to the IT team; if the change requires XSLT, hand it to the functional IT analyst; if the changes can be accomplished through the GUI, let the business user run with it. We are brainstorming a checklist and I hope to post something later this fall. We have also started to build a library of best practices and samples; this will expand rapidly as we deploy the application!

Our journey is just beginning... I would love to learn how others tackle this challenge and will be on the lookout for sessions during my upcoming conference junket!

Labels: , ,

posted by JasonShaffner @ 8:15 AM Add a comment!

1 Comments:

At February 5, 2013 at 9:21 PM, Blogger StephaniePumphrey said...

Taking full advantage of technology, together with faster and open minded life, all make human society more comfortable, greater, more developed and more equitable.

lifestyle definition

 

<< Home