So what’s the common way to develop and deliver a self-service solution, and is there a best way?
The simplest answer to this is there are many ways to skin a cat, and sometimes solutions can work in many different ways. You can program a solution to work to be viable in different technologies.
What I am about to share with you is a real life example of a solution that failed in its first instance, and was later rescued by implementing a proven way; the way we typically develop our solutions.
I was tasked with working on a ticketing system for a large client, whom we were subcontracted through another partner for. Our partner provided their online infrastructure, and insisted on their solution utilising their online environment. So from a design perspective our hands were tied to a web application strategy for development.
We started out developing a smart browser, which enabled their existing customised ticketing platform to be used. This solution was a hash together of their solution which was used on web and mobile. Our task was to provide a secure locked down environment, with a browser solution that would call specific pages on their web platform, and take payment locally via chip and pin. The solution in testing worked, however it later was found to have issues, which we were not in control of.
The issues specifically were related to the hosting environment that the browser was pointing too. The specific issue was due to poor coding on the web platform, and the web developer not understanding the life-cycle of IIS and web apps, and app pools. When the application recycled on the server the browser was unable to navigate to the web browser through the agreed strategy, which caused the application to go out of order. I could go on to explain a whole host of issues that were identified, but I won’t. Suffice to say the developer was inexperienced with IIS configuration and administration – a lesson he learnt in a production environment unfortunately.
As this was quite an important client for all parties involved, we needed to show how the application should be developed based off our proven experience. We ditched the web application, developed web services to drive the ticketing fulfilment and other key functions, and wrote all the user interface as a native application. This development took about a day to do (mainly due to the interface being so simple, and extensive experience in developing these types of applications), and we had a solution that worked flawlessly.
The lesson here isn’t really that you should develop in one particular way for a self-service environment, more that if you are to develop a solution be damn sure that you understand your environment and limitations. In this case the developer didn’t even know what happens when the app pool recycles on IIS.