And then what?

An often discounted part of a software solution project is lessons-learned. Getting a new or upgraded solution into production can be an exhaustive task with little or no appetite for a review. So the high risk of repeating the same mistakes shouldn’t come as a surprise. Technical evolution is no substitute for lessons-learned or experience.

With no production to worry about, here is my item-availability lessons-learned:

From the subject to the object

Software tools like languages and libraries are objective by nature. For example the Angular framework is designed to build apps for web, native mobile and native desktop. The subject of E1 item-availability is irrelevant.

Software development is however all about the subject, as I’ve noted before.

Software’s purpose is to manage subjects

The challenge here is that programmers are typically not subject experts. Their expertise is software tools and technology. The classic way to bridge this gap is by subject experts specifying the solution objectively.

This approach works fine within E1 software tools because the subject and object expertise overlap – the programmer has some E1 functional knowledge and the subject expert has some E1 software tools knowledge.

Once you leave the comfort of E1 software tools for mobile and web development, there is added complexity. There is no guaranty that either the E1 subject expert nor the E1 programmer have sufficient knowledge of the required development tools and technology – and the odds are they don’t.

So we have the challenge of new tools and technology.

If it’s complex, then break it up!

The first break-up I’m proposing here is do-it-in-E1. E1 is designed to build business processes and there is enormous existing expertise available to do that. Whatever you want the web or mobile app to do – build the business process in E1 first.

This is a definition of what we want to do – the subject. There is no fundamental difference from the classic way of defining a business process in E1, the only difference is the absence of user experience consideration.

The second break-up is the flow or how to achieve our what – this is the user experience.

The what business process and how flow are still subject matters that are fundamentally no different from the classic approach. It’s just been broken up into business process and flow.

Programming the what is integrating with E1 via AIS. This requires E1 tools knowledge but not necessarily web or mobile app expertise.

Programming the how is visualising the flow. This requires the web and mobile app expertise but not necessarily E1 knowledge.

The subject expert’s change is not that dramatic, just separate the business process from the user experience. The programmer’s change is much bigger with greater divergence from the subject to the object. How to visualise is more important to a programmer than what to visualise.

Web or mobile

The boundaries between web and mobile apps gets murkier by the day. A native mobile app has the advantage of presence, performance, storage and native features over a web app. But if none of these are of critical importance, why go the extra mile?

A recent web app evolution is the Progressive Web App or PWA. A web app can now have local presence with its own icon and off-line functionality, cutting the case for mobile apps even more.

Perhaps we are now finally seeing a truly platform independent, write-once-run-anywhere software.