Over a million developers have joined DZone.

Empowering the Power User — Will This Ever Work?

DZone 's Guide to

Empowering the Power User — Will This Ever Work?

Over the years, there have been attempts to empower more experienced users to perform IT-like tasks and functionality. Have any actually worked?

· Agile Zone ·
Free Resource

I was terrible at taking courses related to history. In fact, while attending a well-known music college in Boston (Massachusetts), I took a course titled "The History of Rock and Roll." I struggled with this course as well...despite growing up listening to the type of music that drove the course material.

I believe the main reason I am terrible at history-related courses is because I am extremely sub-par at memorization. The current approach to every history course I have taken is to know a bunch of names, along with corresponding dates. If these very courses ditched the "who's who" approach and left out all dates that were expected to be known — we could simply focus on the moral of the story. Honestly, isn't that what is important after all?

Why History Matters

I was terrible at history, as noted above, but things got better when I started playing the Call of Duty first-person shooter (FPS) series of games on my personal computer in the early 2000s. In those games, they would re-enact events from World War II, allowing the player to live the experience of some very events that occurred during the years when the world was at war.

I learned a great deal about World War II from playing the Call of Duty games. I learned the moral of the story and really didn't have to worry about a bunch of names or dates that really didn't matter as much (to me).

With any historic matter, if you understand the lesson that was learned, there is a better chance to avoid a similar fate in the future. Right?

Well maybe not...especially with some aspects of technology.

Empowering the Power User

A popular approach that software solution designers often employ is the concept of what I call "empowering the power user." In this model, a system or application is put into place that introduces functionality to non-Information Technology (IT) users to perform IT-like tasks and functionality.

The thought behind this concept is to minimize the amount of time required by (expensive) IT resources and allow business users (the power users) to configure or extend the solution to meet their needs.  Unfortunately, there are challenges with this approach, as noted in the two examples below.

Example #1: Business Process Management (BPM)

The first time I recall seeing power-user enablement attempted was with business process management (BPM) applications. Using a plug-in for the Eclipse development toolset, power users could visually design their BPM flows — with the ability to add conditional logic based upon the metadata included with the flow. The thought was that the power users understood the business far better than IT staff and were more invested in the meeting the requirements met from the BPM flows and processes.

The reality was that the flow design process required a deep understanding of the metadata, which was not maintained by the power users. At the same time, while there was a graphically-based tool to design the flows, fully comprehending the toolset would require far more time than the typical power user had available to contribute to the project.

In most cases, an IT staff user ended up using the tooling instead. Unfortunately, this type of tooling wasn't appealing to IT staff and the concept struggled to gain momentum in the industry.

Example #2: Business Intelligence (BI)

When the Data Warehouse buzzword was at an all-time high, the concept of Business Intelligence (BI) became popular too. In fact, dimensional data models focused on BI optimization rose to the forefront of technology budgets — essentially duplicating data in traditional databases and employing the use of new tools and technologies. Just like BPM, there was the idea that when it came to creating reports, the business users would be ideal candidates for this work. After all, they maintained the knowledge of the business and would be inclined to keep the reports updated as business rules changed.

Just like BPM, the reality struggled to align with the concept. Again, power users failed to understand the dimensional data models designed to optimize report response times and the tooling was not as (power) user-friendly as it could have been. There was drag and drop, but things got complicated quickly when more advanced reporting was required.

Also, just like BPM, the reporting design responsibility ultimately fell into the hands of IT staff — who felt equally as dissatisfied with the reporting tools as those did with the flow design tools found within BPM.

Developing on the Edge

With the rise and popularity of Web Application Programming Interfaces (API), corporations are racing to create APIs which can be leveraged across their enterprise. In some cases, this includes exposing APIs to business partners, customers and (in some cases) public users.

Since the cost to utilize IT resources is always a concern to C-level executives, API management solutions are providing interfaces that will allow power users to develop on the edge. In this latest attempt to empower the power user, the tooling would allow users to build APIs using something like Swagger or RAML and eventually lead to providing fully functional APIs that were developed just as if they were authored by IT professionals.

Sound familiar?

This is too new of a concept to know if developing on the edge will be successful, but if history is our guide, a similar result is likely.


Empowering the power user sounds like a great idea in theory. You are putting the responsibility on the person who has a vested interested in providing a successful result. Beyond that benefit, many challenges exist. Three that quickly come to mind:

  • Lack of governance would facilitate a great deal of duplication across similar business units (at the very least).

  • Lack of standards would yield a myriad of solutions which are challenging to support and maintain.

  • Lack of oversight would lead to improper usage of the tooling.

In all three cases, the end-result is an increasing amount of technical debt that would eventually lead to solutions that cannot be easily maintained. Of course, this would assume that the concept of empowering the power user was successful, which really has not been the reality thus far.

Like anyone in IT, recognizing power users exist is a lesson that is learned early in one's career. I truly believe they are a very important aspect of our world today and serve a very strong purpose. However, I believe that IT also maintains a strong presence in today's technology-driven world.

When solutions attempt to push tasks onto power users that are typically IT-related items, there is a great deal of challenges to reach the expected level of success. I don't believe I have seen a successful scenario and I feel like the latest API-driven approach will unfortunately face a similar fate. IT professionals exist for a great number of reasons, far more than can be absorbed by empowering the power user.

I might be bad at taking history courses, but I have gotten to the point of my life where I really want to understand past lessons learned to avoid history repeating itself.

Have a really great day!

agile adoption ,lessons learned ,historical analysis ,business process management ,business inteligence ,data warehouse ,dimensional data

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}