No wonder the IT backlog is mushrooming. Many IT departments are struggling to deliver mobile applications, getting cloud-ready and other digital innovation initiatives, while also taking care of an unrelenting volume of maintenance.
There is wide agreement that the ‘need’ for shadow IT and its more legitimized progeny, citizen development, is caused by IT not being able to deliver what users want when they want it. Excerpts from blogs and other articles on the topic include:
“IT organizations are not equipped to offer solutions at the pace that business requires them.”
“Opportunities to innovate are being stifled by traditional application development processes.”
“Shadow IT and citizen development are an acknowledgement that IT does not have the resources to deliver what users need.”
To overcome this backlog problem, you would think that the most logical solution would be to equip IT with more productive tools for application development, maintenance and cloud-enablement. But instead, the de facto solution seems to be the rise and rise of shadow IT.
Why not try to remedy the cause of the problem? Have users given up on IT? Is IT itself reluctant to adopt a more productive development approach?
What is holding the IT division back?
- The sheer complexity of having to deal with a multitude of tools and languages results in developers spending a large amount of time on mastering the technology, eating away from the time they should spend meeting the actual business requirements.
- If that isn’t bad enough, developers also spend a lot of time on making applications compliant with multiple browsers, versions and devices.
- Developers inevitably have to specialize in front-end (user interface), back-end (server or cloud) and middleware (integration). With these siloed-skillsets it becomes harder to schedule projects, as multiple skillsets may be required even for small changes.
Where does citizen development fit?
Perceptions about shadow IT are often negative, illustrated with horror stories about data breaches in BYOD scenarios, storing data in unapproved cloud environments and use of private email for work.
If citizen development is just an offspring of shadow IT, is it any different? The answer is, it depends: If the development environment is properly managed, the security risks are manageable. However, security is not the only problem.
Even vendors of citizen development tools agree that simple internal engagement apps, so called ‘tier-3’ apps, are the sweet spot for citizen developers. Typical examples cited include workflow, project/event management, staff scheduling and sales support. (The type of applications that were previously handled with MS Access, except now they have a mobile interface.) The same vendors agree again that ‘tier-1’ business critical transaction-based applications, such as ERP and supply chain systems, should be left to the IT division. ‘Tier 2’ is a grey area.
But what about the many applications that start as tier-3, but eventually turn out to be tier-2 or even tier-1 as they morph over time? Is IT eventually supposed to take over responsibility and maintenance of those apps?
Even if the citizen developed app stays in tier-3, there are risks. The app may have been developed with only the team members of the citizen developer as the intended users. If the app is deemed to be useful, it may see wide adoption. More and more users may start to rely on the app. But since the app was never designed for a wider audience, things most likely will go wrong at some point. Also, without change management procedures in place, software updates can be dangerous. New features that benefit the immediate team members of the citizen developer may break things for users outside that team.
Will IT be faced with the emergency first-aid and maintenance of such apps as they run off the rails?
Myth or reality: IT simply takes over when the citizen developed app becomes too big or complex?
Citizen developer tool vendors like to claim that the IT division can simply take over maintenance of a citizen developed app when the app reaches its limit of complexity, or when a tier-3 app morphs into a tier-1 or 2 app. That looks good in concept, but is it that simple?
If an app is citizen developed, is it likely to be scalable, maintainable and flexible? Can the citizen developed app be extended easily without a lot of rework? Can the business logic or user interface be reused in multiple applications? What are the boundaries of performance, for example, can the app work with larger data sets?
Any productivity and agility will be lost from that point onwards. Is that acceptable?
If citizen developers are agile, what about IT?
No one will disagree with the idea that IT professionals and business users should be partners in solution development. There is a place for citizen development, but it has its limitations and risks.
Why not minimize the NEED for citizen development at its core and give the IT division a more productive development platform?
To stay relevant in an environment where business users have first-hand experience in creating apps fast, IT needs more productive development methods. It doesn’t matter whether you call it RAD (Rapid Application Development, RMAD (Rapid Mobile Application Development) or Low-code. What does matter is the productivity and functionality that the development platform offers.
Your checklist should include:
- An Interactive framework for prototyping that allows for close collaboration between business users and developers. The prototype should evolve to be the real thing, rather than be a ‘throw-away’ experiment.
- A WYSIWYG designer to assemble responsive designed applications by dragging-and-dropping and by using layouts, widgets, reusable components and other items from a repository of controls.
- A Business Rules Engine, where you define metadata and rules in a central location – external from any program code and independent of the database. If any of the definitions or rules need to be changed, you only have to make that change in one place! This will eliminate duplication and dramatically reduce the maintenance burden of a system.
- An independent Data Services Layer to provide a single access point for all data. Defining meta data and business rules centrally is only a first step. You also want to make sure that all programs, including citizen developed apps, that access the data use the most recent definitions and rules. In other words, to protect your data, you want the definitions and rules not only centrally defined, but also centrally deployed.
- Platform and database independence. It should be easy to generate the Data Services Layer for another platform (any Cloud and on-premise mix) from the same Business Rules Engine. Also, it should be easy to generate the applications for another platform from the single high-level language set of code.
LANSA is an example of such a productive application development platform. It’s not restricted to bi-modal mode-1 or mode-2. It’s multi-modal.