Application architecture and Business models. Part 2.

Following Part 1, where I presented a ‘software’ use case, this post proposes an application architecture that allows extensible workflow modelling, a tightly integrated GUI, a pay-as-you-use business model, in a “web 2” application platform. I’ll call it the ‘Enterprise Web 2.0 platform’.

The inspiration comes from multimedia applications that have been around for decades. Let me set the scene…

Its the late 80s, and gentleman named Miller Puckette is working at IRCAM (Institut de Recherche et Coordination Acoustique/Musique) … trying to work out a better way to organise how MIDI messages get sent to various keyboards and other pieces of audio hardware. MIDI is essentially a simple protocol for sending around musical info, like “Play note C, reasonably loudly, for 2 seconds”. These messages get routed around from computers to keyboards to samplers to this that and everything under the (audio) sun.

max_hi_patchMiller wants a way to easily change/affect/filter/configure this MIDI data, change what device the MIDI data gets sent to etc. He writes a now-lengendary software application called ‘Max’. Its simple … its just a set of boxes that do different things … and you can wire them up to each other, in a sequential manner, define the input and the output (where the messages come from, and were they go to). Have a look at the image.

For corporate software users, Max looks kind-of a bit like Visio. Boxes joined up by arrows (or lines). But it is very very different to Visio, because it is not just a diagram, it actually executes the logic that it represents.

The configuration interface is also the application architecture is also the user interface.

What you see is what will execute (WYSIWWE). There’s no ‘business logic’ below the bonnet.

Many people have since written other applications that use a similar “the GUI *is* the application architecture” model for audio processing, video processing, and other things. There’s MaxMSP, PureData, Plogue Bidule, AudioMulch, Reaktor, and more.

pixonixIn 2001 I spent many hours integrating video processing capabilities into JMAX. You can see, on the image on the left, one of my “Visio diagrams” of objects and connections describing how video should be processed.

Its a messy diagram, but that’s not the point. The point is to realise that each object does something different, and you can configure exactly what you want to happen by creating lots of little pipes between different objects.

That’s the first point.

The second point is how the “GUI *is* the application architecture” thing works. How is it implemented and why is it so profoundly significant? Well, it is simple. Let me illustrate this by considering how one would implement an email notification feature. Consider this code:

public void EMailer (email_address, email_subject, email_body, trigger) extends GUIObject
{
    # code to send an email here
}

That’s the only code you would need to write. You dont need to write a GUI. All you need to do is drop that compiled code in the right folder, and whamo, ‘management’ has a tiny little independent object called EMailer that they can drop into their Visio-like diagram. Just configure the recipient, subject and body, then draw a line into it (from whatever point in the ‘workflow’) and an email will be sent at the appropriate time. What you see is what will execute.

This little ‘feature’:

  1. has no dependency on any other code in your application,
  2. can be easily (QA) tested because it is entirely isolated from other code,
  3. will not introduce bugs because it is entirely isolated from other code,
  4. requires no GUI to be designed,
  5. can be used anywhere in the application,
  6. can be used by someone who knows nothing about programming.

Implementation

How would I implement such a thing? Well, it has to be accessible over a Web Page. I’d implement the front end using Flash (embedded in a web page) … communicating via a REST API most probably to a Java back end (or perhaps a PureData back end?). Flash would not execute any of the business logic… its just an interface to define/access/monitor/edit the ‘workflow’ (or business logic).

The useage of Flash is important because it favours graphic designers, and the design of such an application would be very important. That said, since the communication between the front end and the back end is a REST API, anyone could come along and implementa ‘new’ interface.

Design

I’d employ the best user-interface designers, and graphic designers I could find. The above code sample defines no GUI code just to illustrate the architecture, but in practise you would want to design a funky little GUI for each object. The EMailer, for example, would typically be a little envelope icon. That GUI design would be a little Flash file that would be sucked up into the larger Flash file.

Business Model

You would pay only for what you use. So, for example, the EMailer might cost 1c per email sent. EMails are sent when the object receives a ‘trigger’ so the ‘triggers’ would be counted, and each object would have access to a REST API to ‘log’ useage volumes.

3rd party extensions

3rd parties only need to develop the independent objects, then ‘log’ them in an object database. All customers of the platform would be able to access all objects in the database… and their account would be charged as per what they use. They can choose to use or not use any objects at any time.

Sample objects would encompass typical enterprise software needs, such as these:

  1. LDAP server integrator,
  2. Schedule objects,
  3. Logic flow objects,
  4. Notification objects (emails, SMS, IM),
  5. etc.

Configuration

The customer’s administrator (or manager) would then drop, onto a blank screen, a selection of core and 3rd party developed business logic ‘objects’, then string them up to model their workflow/process requirements.

In Production

Once configured, the ‘patch’ (or diagram) would be locked. Each object would then expose different levels of interface to be used during the real world ‘workflow’.

Prototype

I’d prototype this by using the existing PureData. In fact, I might even implement it using PureData as the back end.

Conclusion

This post proposes an extensible ‘platform’ for modelling and executing ‘workflows’ in corporate environments, and how that ‘platform’ could be monetised (on a per-useage basis).

It is inspired by configurable multimedia software, where a workflow is modelled by a GUI which looks and feels similar to a Visio diagram. The radical difference is that the diagram then *becomes* the application architecture. It is not just representational, it is in-fact executable.

This architecture is very scalable, feature-wise. Adding new features causes no weight on the existing infrastructure.

The platform is heavily GUI based, and so could be easily configured and maintained by the customer.

The platform’s GUI would be delivered by Flash embedded in a web page, thereby offering high accessibility.

NOTE: this post is, ofcourse, a simplification of all the details that would be involved in implementing this architecture. It is essentially just a first ‘fleshing out’ of an idea I’ve been thinking about for a while.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

One Response to Application architecture and Business models. Part 2.

  1. Pingback: Application architecture and Business models. Part 1. « Building Ambisonia.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s