When I first wrote opentaps 2.0 Planning, my goal was to come up with a new architecture that would make enterprise software more modular and more reusable. But we will need to do much more in a mobile and API-driven world, so here are some of the guiding principles behind the architecture of the new opentaps:
Universal data layer
Today’s business software is still driven by tables in a database, even though relevant data is likely to reside anywhere — in a database, a document, or over the web through an API. The answer is using the domain driven architecture to interface with multiple sources of data.
API instead of UI
With the emergence of the new web architecture, the rise of a multitude of mobile platforms, and the increasing importance of open API’s, separating view from logic has become a necessity. Therefore, new versions of opentaps will provide an API layer without a “chosen” UI framework. This will opentaps up to developers of any platform or framework to implement applications based on the opentaps API.
Smaller “Units of Work” Applications
Instead of carrying the entire feature set in one application/framework/database, we will break it up into a series of independent mini-applications. Each mini-application may have some internal data model which is invisible to its peers, and all the mini-applications will interface through a common data model. This would make the mini-applications both easier to develop and maintain and less costly to run. Each module could be developed, maintained, and supported by independent and specialized groups. Infrequently used modules could be run as needed with Amazon EC2 spot instances or their equivalents, thus significantly reducing the hardware resources required.
We’re too used to waiting. The web has conditioned us to the synchronous request-wait-response cycle. But mobile devices and partner systems connecting through API’s could give users a smoother, faster experience through an asynchronous cycle, where they process user requests immediately and then batch the results to be sent over the web. For example, products could be downloaded locally to a tablet, and orders could be created and then sent to server-side for processing while new orders are taken. The new version of opentaps will intelligently handle asynchronous requests from a variety of clients.