Share what you know with millions of people
Focus is the best place to turn what you know into remarkable content
0
How should IT leaders address line of business users that develop business applications themselves?
For instance, if a line of business user uses Microsoft Office and VBA to write an "application" in MS Access that is used to store non-public information? Or a line of business partner using SharePoint to create a workflow which, if it fails, would impact your customers and perhaps have regulatory or compliance concerns?
Events
- Dos and Don'ts of Small Business Marketing May 29 @ 11 am PT
- Lead Nurturing 202: The Next Generation May 31 @ 11 am PT
- The Tricks to Paid Media June 6 @ 11 am PT
- Display Advertising for Brand Awareness June 20 @ 11 am PT
Related Activity
3 Answers
These kinds of ad-hoc solutions are all too common, particularly in enterprise environments.
I think these cases are above all, an important learning opportunity. It’s been said that necessity is the mother of all invention. When we step back and look at these situations, someone believed (correctly or incorrectly) that it was easier, faster, and/or more economical to patch together these “solutions” than to engage IT. This is essentially a failure of the IT department, typically in user education and governance and/or execution on business needs.
As an architect, I like to begin by getting the back story on how the solution in question was commissioned and what needs it fills. We then look for an existing enterprise tool that either already provides that functionality or one that can be easily extended or configured to do so. If there are no existing alternatives, we determine if the risks of this ad-hoc system are great enough to warrant replacement or if it can be “beefed-up” to mitigate risks and become an officially supported tool added to our enterprise software portfolio.
I try to handle these situations with care because of the “potency” of these types of solutions. It’s been my experience that they are usually very tightly coupled to operations. If they’ve been there for a while, simply yanking them out or forcing a hard transition will have a very negative impact on the user group’s productivity.
I am glad John was the first to answer this question becuase he made a very critical point when he stated, "This is essentially a failure of the IT department, typically in user education and governance and/or execution on business needs." Having (or not having) this perspective will have a monumental effect on the IT leader response to this situation.
Here are some very high-level steps I would take as an IT leader:
- Recognize and openly admit this is an IT failure (as Bob suggests)
- Identify the business users involved in the development effort
- Understand the business need they were attempting to fulfill
- Determine if there were existing IT constructs (policy, standard, processes, capabilities, etc.) to fulfill the business need
- Determine if the business users were aware of the IT capability
- Determine if the business users were aware they were doing some that was "unsanctioned" or possibly, in violation of existing IT standards. If yes, understand what incented the users to do something they knew was "wrong." If no, investigate why the users were not aware (identifying the communication or training deficiency)
- Determine if the business application can be "transitioned" to the "appropriate" construct. If no, determine how existing IT constructs must be modified to fulfill the business need, and THEN make the transition
- Work with business users to take all the appropriate steps necessary to reconcile the circumstances that resulted in the issues leading to the situation
Notice the lack of confrontational, adversarial, and punitive responses. The key is to work with and FOR business users, and focus on what is best for the enterprise.
I'm going to take a slightly different perspective from John and Steven and ask "why shouldn't lines of business develop applications?"
Okay, we all know the issues of "shadow IT" and the inefficiencies that accompany it. No argument there. But in the evolving world of virtualization and cloud computing, just as we have abstracted the OS from the hardware, why can't we abstract the application development process from IT? Lines of business own the business context (intellectual property) that make up the logic of applications. What's preventing them from using tools to create business services (applications) on top of services provided by IT? Do we really need IT to be the gatekeeper in the future?
Granted, your examples are pretty specific to certain products. But this is an age-old problem. We've been creating apps out of Excel for years. Scary how many businesses run critical operations on spreadsheets and VB.
But maybe it's time to change the focus of IT to create an "open source-like" environment where lines of business can contribute to the development of business applications. Somebody still needs to set policies and audit for compliance, but should that really be IT? Let's have them focus on the elasticity, reliability and security of a "services" environment and let lines of business focus on getting products and services (translate to applications) to market more quickly.
Too radical? Thoughts?
Answer This Question