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!

Thursday, September 15, 2011

A Bag of (Trick) Questions

Every summer I sit down for 30 minutes with the members of my team—roughly forty business analysts, systems operations analysts, product managers, and project managers. I inherited this tradition from my predecessor and the first time around I found it to be a valuable undertaking—challenging as may be to execute forty-odd sessions in the vacation-rich summer months!

When I was new to my position the approach was rather straight-forward – I simply asked what staff members thought was going well (or poorly) in the department and what they were looking for from me as a leader. In those early months, their suggestions, questions and concerns were huge. And although I had no doubt about the value of repeating the exercise, I was fearful that repeating last year’s “agenda” could be a recipe for long stretches of silence.

I crave staff input – I want to understand everything: motivators and de-motivators, career objectives, opportunities for improvement for the department and the institution. Furthermore, as months upon months of Sunday’s “The Corner Office” in The New York Times has taught me, it is equally important to understand individual likes and dislikes, favored weekend activities, favorite books, etc. And as a part-time cinephile and foodie, I wanted to ask about favorite movies and meals!

Too many questions, too many interviews, and too little time: I needed a system. Being an applications guy, I entertained the thought of building a systems solution myself… Or scouring the App Store. But then I realized (for once?) that technology was not the answer.

Hidden away in a filing cabinet outside my office was a laminator. I blew the dust from the lid, framed out my discussion prompts using an MS Word label template, pre-heated the laminator, ran my labels through, and located a long-abandoned paper-slicing guillotine stowed behind a copier on the second floor. Interestingly, nobody inquired why I was partaking in light arts and crafts on a Tuesday afternoon.

The next morning, I had my first of 40 interviews. The rules were simple: for the first 20 minutes, you draw questions from the bag; we’ll leave the last ten minutes to talk about anything else on your mind; in that time you’re free to turn the questions around or continue drawing prompts.

It worked. The conversations flowed nicely, a neat balance between quasi-interview and idle chit-chat. By the second week, rumors about “the bag” (a very snazzy Whole Foods fabric bag with ample room to shuffle the laminated cards) had circulated but since the average participant only saw about 30% of the questions most people were still surprised by the questions. (Although toward the end I fielded several prepared responses to the exceedingly difficult “vegetable” question).

On the corner of my desk is a legal pad filled with detailed notes from these discussions – I have started to pull out key themes, insightful quotes, and lists of the eclectic musical and movie tastes in the department. I feel closer to the team, more aware of their needs and personalities. I am proud of my “innovation” (quotes because it is unlikely I can claim IP over this technique) but already thinking – what shall I do next year?

Labels: ,

posted by JasonShaffner @ 7:00 AM Add a comment!