One of the cold realities I have discovered with Ambisonia, is that there is a hard limit to activities which dont sustain themselves financially.
I cant (yet) claim to have a good grounding in online business models, but I do claim to have a solid base in marrying online technologies to deliver applications. I’ve been doing lots of thinking, recently, on how to infuse business models into application architectures.
In Part1 (this post), I will highlight a ‘software use case’. In Part 2, I will propose an architecture which delivers a scalable solution combined with a deeply integrated GUI and with an infused business model.
Y Combinator, a high profile early-stage startup fund, lists ideas they would like to fund. One of them is “Enterprise software 2.0″:
Enterprise software companies sell bad software for huge amounts of money.
Oh, how I agree with them! My ‘payed’ work, for the past 10 years, has been mostly in the corporate ‘IT Service Management’ field. The complexity and lack of ‘user experience’ most available software provides is head-ache inducing.
One of the current lights of this industry is www.service-now.com … a “Software as a Service” (SAAS) IT Service Management provider, which brands itself as “Web 2”. I worked with this tool for over a year, and whilst it is definately years ahead of any other software I’ve encountered in this field, its still far from what I would consider “Web 2”.
Service-now essentially models business processes by offering long, deep forms and endless choices of convoluted combinations of configurable drop-down fields. You know what stage a particular process is in by reading the current value of a drop-down. Not very intuitive. Filling out a form requires making many ambiguous decisions that will always be prone to errors. Staff need to be trained, and then work full-time, just monitoring/maintaining values in forms.
One of Service-now’s other drawbacks is its complexity of configuration. The vast bulk of a new customer roll-out involves configuring users, groups, privilidges, tasks, alarms, notifications, workflows, etc. About 80% of that is achieved by, you guessed it, filling out numerous web forms. The last 20% requires scripting (in ecma script). Often, you can achieve in several lines of ecma script what might take several pages of web forms. Ofcourse, the professional service consultant will always tend towards favouring the web forms, because the customer can then maintain the system themselves. Or at least that is the theory.
But Service-now have enough ‘young smarts’ in their midst to recognise there was a better way … they recently deployed the Graphical Workflow editor (see image). One of the things I noticed when collecting customer requirements, was that many customers defined their requirements with Visio diagrams. We would then ‘translate’ these Visio diagrams into values we would type into a gazzilion ‘web forms’, and ecma scripts.
It wouldn’t take much to reach the conclusion that configuring the system should be done with a ‘Visio diagram’ style interface. Service-now saw this and delivered. Although, there are now 3 ways to configure a system, a gazillion web forms, ecma scripts, and the Graphical Workflow editor.
- Will all features be available through this interface, or will I be relegated to doing *some* things in ecmascript, *some* things in web forms, and *some* things in the Graphical editor? Already, not all aspects of certain features are available in web forms, and not all aspects of things in web forms can be easily configured in ecma scripts.
- How has it been architected? Is it just a layer on top of everything else? Like so many other corporate applications, will Service-now fall over in 5 to 10 years because of a complicated multi-layered architecture that piles new feature on new feature, eventually requiring a team of Quality Assurance engineers the same size as its development team, just to make sure that a new feature hasn’t broken everything else?
I also wonder if this interface is only intended for configuration. Because it shouldn’t be. If Visio diagrams is how management see processes, then Visio diagrams is how the staff should execute these processes. Removing Web forms with endless drop-downs, check boxes, radio buttons, free text fields etc. in favour of a high-level diagram that makes it very clear where we are and where we want to be has to be a good thing.
Instead of an ‘assigned to’ field showing who currently owns the ticket, show me a little image or photo of that person (with their name below), then let me re-assign the ticket by clicking on the image. Or something like that.
Show me when emails were sent just by displaying a little envelope icon next to the relevant arrows/boxes. Give me more details when I click on them. Tell me what emails are going to be sent by ‘penciling in’ light email envelopes at future points in the Visio diagram.
Tell me what stage the process is up to, just by ‘firming up’ the relevant boxes/arrows up to a certain point. etc.
In Part 2 of this post, I will propose an architecture where the graphical user interface IS the application architecture, where adding new features to the application causes no risk and adds no complexity, where the application effectively becomes a platform, and 3rd party providers can offer added features which pose no (or little) risk to the underlying platform but with an easily measurable value.