This is a first attempt to define a simplified enterprise application framework that aims to improve IT environments and application development to be cost effective, integrated and future prove.
I've been an IT architect and developer for most of my professional live, working for very large organisations, all of them struggling with their application landscape and how to get an effective/efficient and adaptable environment. The final conclusion until now is despite my efforts, we failed at least on one of those goals.
Large organisations are complex organisms, where technology, risk, flexibility, operational excellence, money and politics all play a role and no model seemed to be able to satisfy them all. This new approach is an attempt to bring all those different influences together, maybe besides politics since that one lives a live on its own.
Let's start with a diagram
Image may be NSFW.
Clik here to view.
It's a simple diagram, I hope we can agree on that. Critics will probably say, too simple. But it can be adapted if and when needed. An architectural princples should only try to provide guidance and should never try to be rigid.
Let me explain the model.
Most important to current IT environments is that they need to be internet enabled and device independently. To facilitate that we need to have a clear split between the user interface which is dependent on the device from the backend which is system dependent, as the starting principle.
If we would only adopt that principle, it would only move all application problems to the backend, so we should solve this one too. An interface layer is required is the logical answer to that. And there you are, a webservice layer is introduced.
The user interface needs to connect to any backend application using those webservices (aka API). This is quite common practise in the internet world, but not in the business world. But the internet world currently still fails to decouple the user interface from the backend. We are to familiar to html is the legacy of web developers and therefore we try to solve it in HTML (and that is why HTML5 was born). So remark in the diagram that all frontend calls, including HTML will go to the webservices and get XML or Json output back. This is the most fundamental part of the principle
Currently websites are build using pages and views and to accommodate different user devices the internet community is moving to HTML5 with responsive designs. Adopting this architectural principle, will remove the dependancy from HTML.
Going forward on the current path only works as long as all your devices will all finally go to HTML. Is that really the only way we want to go ? Maybe there is some middle ground, where we leave space for all that legacy or even newer, prettier and more intuitive user interfaces. I hate to admit it as a true Internet adept, but some user interfaces are simply better.
The user interface is a very important influencer here, that is why a lot of developers are now coding IOS or Android apps, which in principle is not preferrable since it creates vendor lock-in. As a user or business owner, we really don't want that again aftere we have seen what Microsoft could do with that immense power.
So my proposed principle should work even better since it does not create a dependancy on the user interface using HTML5 but can be anything, from a windows native UI, jquery, html4 or html5, native mobile apps to linux.
Development can be easily split in Front developers on one end who only need to know how the API works and back end developers that are focussed on business logic in and output and who can access what.
The common data exchange format is XML or JSON should do the job for now, since most UI's can work with either one of them. Not much of a new insight here. Both are capable of doing the job, choose one, or facilitate both. I suggest the last, allthough it does add development effort, but as long as there is no definitive choice on which one is always applicable, what can you do ?
The rest is also common practices. Use OOP to access the database layer, so application programmers can extend the data model as they please and also get information from the DB layer based on the same principle.
Sure you can extend this model, where databases are represented to the application as a complex data structure with new rules to extract and search (big data) but that does not really change the model. But maybe I am wrong on that one. Big data might be to unorganised to use OOP to query efficently. Please let me know your thoughts on this one.
Anyway, I think this model can be applied to any application development or enterprise application framework. The integration layer is optional. You can add it, if and when needed. Needed means when backend applications have frequent interaction between each other.
Is it applicable to the real business world ? Probably not immediately, since most applications lack webservices. Development effort should be focussed on two aspects. Backend to build these webservices and front end to request them. Therefore it is still an architectural principle to provide guidance and not something you can apply immediately tommorow.
If we could to agree on this framework, I'll suggest one for the infrastructure part as well. since I did not cover that part here. That one should at least support cloud services, but given this framework that should not be to hard.