Introduction

In this small article I am going to ventilate my recent thoughts on the evolutions and the future of software (both platform and development methodology). This is my first attempt for such an article, so please do not take it too serious. Maybe within 5 to 10 years time, one will be able to read this article and have a big laugh, but then again, I am hoping to get at least a few predictions right.

Application architecture

I think the next big thing leveraging software and it's development will be HTML5. The basic architecture would be like this:

• the client will be a task-based GUI running on the HTML5 platform; HTML5 will be supported on most peripherals.
• the GUI will be able to generate explicit commands (poco class instances) and query view data L/WS* (=local and/or from one or more webservices)
• these commands will be handled L/WS*
• when the command is executed, the changes will be propagated explicitly through events (=poco class instances), or change the view data directly
• these events will be processed L/WS* and will update the respective view data L/WS*
• viewdata can be generated and persisted locally and/or on the server, and syncing is a mather of syncing commands and events
• commands, events and view data will probably be published through some kind of ATOM/ODATA-like interface (or persisted locally)
• due to more and more microdata formats and standards, webservices will become interchangeable (think address lists for example)
• All devices will get a webservice interface (think phones/peripherals in general), usually with a full REST implementation

Consequences

This would imply that a well written app (in HTML5) would be able to:

• query/consolidate microdata or other standardized formats locally and from multiple sources
• disconnected apps could easily be synchronized
• app components should be reusable, apps should be composed of multiple HTML5 components
• it could work in both offline and online mode
• it should support multiple media/input methods
• apps should work on a plethora of platforms without to much effort

The environment/tools

In order to make this possible I expect the following

• the development language of choice will probably need to be the same for both the webservice and the client-side. This does not need to be javascript; it can be an other language translated to javascript for the HTML5 side (think Coffeescript for example)
• commands, events and the handlers should be first-class members of the language of choice, or at least offer a framework that makes it easy to use this.
• there will be a registry which would contain the mappings to resources (either local or on one of more webservices) - this registry might be a webservice in itself, for example a webservice of registry for all your personal multimedia resources
• sharing data between different platforms would become universal (think movies/music for example)
• caching/syncing data should be as simple as calling a single function
• replication/failover is a piece of cake to setup
• CQRS/BDD will be hot
• monitoring the infrastructure is easy
• everything will become continuous: continuous integration through a buildserver, continuous testing (think autotest.Net for example), continuous deployment, continuous monitoring
• authentication will also be done through webservices or through current http/SSL/OID/... implementations
• some kind of universal search which goes through all resources in the registry should be possible

Finally

I think in the end we will get an application that sends commands to a bus, which is either handling things locally and/or on one or more webservices. The app will also be able to either query the local data or some webservice for view data.

The registry of webservices will make it possible to plugin your own stuff without much hassle, and caching/backup/failover/monitoring should all become a non-issue.

A few possible problems come to mind here, which might be excuses why my predictions could be false:

• migrating/integrating legacy systems
• software/Services ownership and -protection
• CQRS/BDD acceptance might be hard for some devs
• implementations differences of HTML5
• REST webservices might be replaced by something faster/with less overhead (protobuf comes to my mind for example)

In the end, what it all comes down to, is finding a balance between simplicity, flexibility, complexity availability and concurrency.