Shadow IT & citizen development – Love IT or Loathe IT

Shadow IT and citizen development

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?

Today, client-server and other legacy applications are largely being replaced by zero-deployment browser applications and apps for mobile devices.  Developers who use traditional development methods now need a combination of HTML, CSS and JavaScript (all three), plus their preferred JavaScript library (too many to choose from) to construct the user interface. An added complexity is that the design of the user interface must be responsive, meaning that it can be deployed to mobile, tablet and desktop devices of multiple sizes. Then there is the server side and middleware to handle.

  • 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 often have to revisit (or even re-write) their code when one of the underlying technologies changes or when the new release of their favourite JavaScript library turns out to be not backwards compatible.
  • 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?

Even in the rare case that the citizen developed app forms a properly architected and stable base for IT to build upon  (rather than a throw-away prototype/experiment), low-code citizen development tools are different from low-code rapid application development tools for IT professionals. (Be suspicious if a product claims to be both.)  Therefore, when IT takes over responsibility for a citizen develop app, IT developers often have no choice but to revert to traditional and far less productive development methods, such as Javascript, HTML and CSS.

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:

  1. 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.
  2. 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.
  3. A low-code rapid application development tool that allows developers to develop, maintain and debug with one, single high-level language. The tool should generate all the required HTML, CSS, Javascript, JSON and other code that is required. The tool should give developers enough control, so they never have the need to hand-crank the underlying code.
  4. 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.
  5. 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.
  6. 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.

Customer examples
LANSA Services
Get shadow IT back into the light  (case study)
Product information and demonstration videos
Blogs and other resources

 

Marjanna Frank

Author: Marjanna Frank

Marjanna is responsible for LANSA’s marketing activities in Asia Pacific, editing the LANSA Review magazine and writing customer case studies. Her career started as a COBOL and RPG programmer in the Netherlands, followed by 10 years as a developer, analyst and founding partner at PT Sistima, a small software house in Indonesia, which offered its own localized ERP solution and general IT services. After moving to Sydney, Australia, Marjanna joined Aspect Computing and later LANSA, where initially her responsibilities included consulting on data warehousing projects and developing LANSA training materials.

Leave a Reply

Your email address will not be published. Required fields are marked *