Category: Uncategorized

Consider this story of a typical software implementation for business specialists (in this case, an oil and gas company information management system) – provided by software company KADME of Stavanger.

[This is based on an article by Gianluca Monachese, Director Business Development, KADME AS and Vasily Borisov, Director of Technology, KADME AS, to be published in Digital Energy Journal Aug-Sept issue and also presented at the PNEC conference in Houston earlier this year.]

Consider an organization which has decided to change their information management system because the software they have been using for the last 20 years is not supported anymore.

They produce a Request for Proposal (RFP), trying to describe what they want.

The RFP is often written by the most experienced users of the old system, who have been doing their work in the same way for many years. So the RFP may include specific requests based on how a certain user wants to work, such as “It should also be possible to merge results and compare data, and a table view, row view and chart view of the data must be provided”

In order to cope, vendors often end up increasing the price, to cope with the risk presented by a non-clear technical requirement that might add considerable amount of work to the scope.

The customer will most likely end up with a system that is regarded by the end users as “not as good as the previous one”, while the vendor will have developed a heavily customized, less supportable solution that deviates from the product they had developed on the basis of their technology and market research.

After software deployment, there is a lot more resistance.

If the new system is better than the old one, then it will also be better at showing the underlying data errors. It is usually the same people that are looking at the new system now who made those data management errors.

Users are reacting by default, blaming bugs in the new system, because they do not see exactly what they were seeing earlier.

It is up to the vendor to defend why the information is presented in the way it is, and to demonstrate that any inconsistencies are not due to the new system. So the new vendor can easily end up with no friends among the operational staff.

Often, the organization leaves the vendor at the mercy of the flow of critics from the end users. The project team on the customer side is quickly disbanded and the vendor is left to “support” end users that were probably not properly involved in the early stages of the project and that were not sufficiently informed about the rationale behind the change.

“Training courses” quickly turn into discussions on why the system does things in this way rather than another.

One possible ‘back story’ behind (or obstructing) low code is the desire of coders to build stuff themselves.

The story of the person who built a piece of custom software and then got easy money for the next 10 years supporting it (and naming their price – because they are the only person who understood it) is often told within the software industry.

But more to the point, if you (as a coder) had spent years developing a skill, would you welcome making that skill redundant? It is (in a sense) as likely as London Underground drivers voting for driverless trains?

Perhaps the truth is that Low Code could mean quite a bit of change in the employment market for coders. Hand coders could become more redistributed – with more employment in low code companies and a few super specialist coders working for big companies doing specialist integrations.

But there will also be a growing market for people who can configure, understand, adapt, use their brains creatively and work out new solutions. That could be more exciting than coding.

Forrester has some advice for company ‘enterprise architects’ (IT system designers) on how to use ‘low code’ in its paper “Five Customer Facing Scenarios Shape Low code Platform Choices”.

It says Low Code platforms can work better on small / individual projects, but not so well on massive company wide applications.

So often Low Code platforms work side by side with bigger company wide platforms.

Forrester also points out that if you need to build sophisticated software integrations, including connecting transactional systems, you will probably need to do it with hand code, and won’t be able to get it as part of low code systems.

Low code platforms might be best for applications following “well established user experience design patterns.”

But if you are doing coding yourself, of course you get more control and flexibility.

Forrester says that Low Code platforms will be good if you want to make an application which can work both on PCs and smart phones – you can design it once for PC and the low code system will adapt it for smart phones automatically.

All this makes a lot of logical sense. We could use a transport analogy – handcoding is equivalent to getting to your destination by foot or by car, and low code the equivalent of travelling by bus or train. If a lot of people want to go to the same place at the same time (equivalent to a lot of people wanting the same sort of software), then it is more efficient overall to get there by bus or train than to walk. But if only one person wants to go somewhere, a bus is more expensive than a car.

Forrester’s report “Five customer facing scenarios shape low code platform choices” includes a section on how low code platform companies are working together with big cloud companies.

It says that Microsoft’s long term priority is building platforms for coders to use (like .Net). Microsoft does not do much ‘low code’ platforms. So there could be room for low code vendors to do this, making low code services running on Microsoft’s “Azure” cloud system, or over Office 365. K2 and Nintex run on Microsoft cloud.

Mendix, OutSystems and Acquia are providing services running on Amazon Cloud.

OrangeScape is building ‘low code’ workflow tools running on Google Apps.

Alphinat is an ‘IBM partner’ – IBM is currently developing cloud infrastructure

ExactTarget’s fuel runs on the Salesforce.com cloud.

This is how Forrester classifies low code platforms in its report “Five Customer Facing Scenarios Shape Low Code Platform Choices”.

DATA TRACKING AND GATHERING: Alpha Software, Alphinat, Avoka, ClaySys, TrackVia

BUSINESS PROCESS MANAGEMENT AND CASE MANAGEMENT / WORKFLOW (or more complex systems for data tracking and gathering): AgilePoint, Appian, Bizagi, K2, MatsSoft, Nintex, Software AG, MicroPact, Mobideo

WEB CONTENT / WEB USER INTERFACE: Adobe, Acquia, Avoka, Mvine

GENERAL PURPOSE: K2, Mendix, OutSystems, Salesforce.com, Intalio, Progress Software

Here are some pointers on how the low code software market works, stealing ideas from Forrester’s report “Five Customer Facing Scenarios Shape Low Code Platform Choices”.

The five ‘scenarios’ which Forrester identifies are

• Simple customer self service apps (eg an online form or succession of online forms connected to a database)
• “Dynamic” customer self service apps (something more complicated, such as a supermarket online store)
• “Human mediated forms applications” (a more complicated form, when the customer would typically be taken through it by someone over the telephone, such as an insurance application)
• “Human mediated customer engagement application” – a more complex form system with a customer speaking to an employee over the phone – eg a credit card application
• “Human mediated case management” – a more complex internal / external administrative system for a certain process, which may involve uploading documents

Understanding the software landscape is an enormous challenge – there is a lot of terminology, some of it overlaps, and some has more specific definitions than others.

“Business Process Management” can mean literally managing business processes – or software to help manage business processes. (You get the impression that some people don’t think there is much difference between these two).

There is a whole range of ‘business process management’ software tools, to help make it easier to make a system to manage your business process.

According to the Wikipedia page on ‘Business Process Management’, a typical BPM suite might include:

• Process engine — a robust platform for modeling and executing process-based applications, including business rules
• Business analytics — enable managers to identify business issues, trends, and opportunities with reports and dashboards and react accordingly
• Content management — provides a system for storing and securing electronic documents, images, and other files
• Collaboration tools — remove intra- and interdepartmental communication barriers through discussion forums, dynamic workspaces, and message boards

This is close to what we are interested in with ‘Software for Domain Experts’ although it also perhaps a bit more sophisticated than most expert users need.

There is also ‘Professional Services Automation’ – defined on Wikipedia as “software designed to assist professionals, such as lawyers, auditors, IT consultants, and other professionals, with project management and resource management for client projects”. So that’s project management software.

The kind of ‘Software for Domain Experts’ we are interested in here is more about simply gathering together information people need and presenting it in the right way.

We believe many expert users are satisfied enough with their corporate file storage systems (for content management) and satisfied with e-mail systems for collaboration (or if not, there are plenty of specialist tools available which will do more)

But what they don’t have is their data in exactly the way they want it – and of course their requirements are always changing.

So that’s why we are maybe looking for a more ‘low code’ version of ‘Business Process Management’.

• • Here are some sorts of domain expert software which we have thought of so far, and examples
  • For sorting through the company’s data (which it probably has tons of, in various databases and spreadsheets), we suggest Maana (www.maana.io). This software automatically indexes, classifies, and statistically analyses, all of the company’s data it can find (even non labelled tabular data, or reports) and gives you some useful advice. Together with a domain expert this could be a very powerful tool.
  • For making automatic analysis of spreadsheet data, you can use Tibco’s Spotfire.
  • For ‘case based reasoning’, bringing up examples of what happened before when your situation was like it is now, see Verdande of Norway, a system for oil and gas drilling, also being used in healthcare.
  • For information management services for an organisation’s structured information, see Kadme, a tool for oil and gas national data.
  • For an example of collaboration tools, see software by Norway’s Computas, for collaboration during oil and gas drilling.
  • Business Process Management tools can help share information with others.
  • Sensorflare of Athens can make it easier to connect together ‘internet of things’.
  • We haven’t seen any software for managing data to compute Key Performance Indicators (KPIs), someone has probably built it.
  • (note: none of this has much to do with the software you can build with the current range of ‘low code’ tools, from companies which consider themselves ‘low code’. That’s mainly for putting data into online forms, entering data, managing data associated with cases, online content management systems and online stores. There’s plenty of progress to go here).

Here are some ideas about how software can help in urban transport planning, gaining from reading a few chapters of this book “Urban Transport without the hot air”. http://www.amazon.co.uk/gp/product/B00UQYS1MO

An underlying theme of the book is that urban transport planning is extremely difficult – but there are large bodies of data which can help guide just about every decision.

• • For example, what happens if you build houses in cities with no car parking? Does “naked” street architecture (building roads with no barriers between the road and the pavement) improve safety? Is it practical to get traffic to slow down?
  • Planning public transport is actually extremely difficult. Making a service which people actually use will require that it is more convenient than a car, which can (usually) take them from their house to their destination in comfort any time they like at low cost. For a bus to do this, they might need their own private bus. This kills off the bus economics. But how do you get good bus economics with the convenience of a car?
  • And plenty more.
  • Dense cities can solve many environmental problems. If we’re expecting a future with high energy prices and carbon emission constraints, we’ll need to keep transportation short distances, preferably shared, with as many walking trips as possible. But making a dense city without streets clogged up with motor cars requires public transport which works well.
  • Back to Software for Domain Experts – imagine an urban transport planner with software which could provide – at her fingertips – all the data about past transport projects in cities around the world – all the data about her current city – and advice and stories from other transport planners about how they would work in any situation.
  • Then imagine if she could gather and manage data about everything she’d built to see how well it works – and possibly make adjustments (over short term – traffic signal timings for example, over long term, in policy for building new housing estates) – and see how well that works too?

• Let’s start with this vision – that every domain expert / specialist has all the right information in front of them to make a decision – they know what is happening and they know what the organisation did last time the situation was like this, and how well it went.They can analyse the data and consider a course of action, and work out how good it is. They can collaborate as necessary. They can make their decision and see how well it works.
• This doesn’t sound particularly original – Microsoft might have been saying something like this 10 years ago. But it hasn’t really happened yet.
• The reasons why not are well documented. The data isn’t available, is not easily searchable, you can’t make comparisons easily. The business software to bring it together is not built well enough. People can’t gather the data they need easily, or see what the result of their decisions have been.
• The good news is that there is technology to solve all of these problems. The ‘internet of things’ means that data can be gathered much better – using sensors, cameras on drones, people entering data on mobile devices. New search and analytics technology makes it easier for a company to understand all of its vast data sources. The experience of other professionals can be gathered as stories and presented as required using ‘case based reasoning’ tools.
• Sophisticated software can automatically diagnose and visualise the data so it is in the best condition for decision making. You can automatically be connected with other professionals who know.
• Most exciting of all, making better software is becoming much easier with the advent of ‘low code’ technology – instead of going through the lengthy (and error prone) process of “specifying” software and then building to specification, you can build something roughly right in a day or so, give it to your end users, and invite them to tell you what’s wrong with it.
• This is the journey which Software for Domain Experts will take you on – and we invite you to join us in it.