IT revolution – 3 layered model driven information systems

There are frequently questions about why this abstract domain driven approach is not widely used yet.

This post tries to answer those questions – at least partially.

There is no doubt about the fact, that model driven information systems are theoretically simpler to design and implement than their procedural counterpart. There is also enough evidence to prove that this is also the case in practical implementation and it works. But why then it is not used  in the mainstream yet?

I don’t really know the full answer myself, but I know different aspects that are at least part of the explanation.  This is most complex issue. If it was a simple and strait foreword one it would have been solved ages a go.

The key issue here is the understanding of the 3-tier architecture and especially the role and importance of the domain layer. When we go backwards in time then all the earlier application implementation were design as single applications. In this case the viewpoint and focus is strongly in the workflow and the usage of application. In this case it is extremely hard to force the separation of domain and application layer and the developers for good reason haven’t seen any value in doing so.

The complexities of the developed applications during long period of time have gradually increased. This has meant exponential increase in number of attributes and especially association. This rapidly grown complexity has not been and is not very visible and for this reason it is dramatically neglected! This means that the impact and the consequences of this have not been generally understood at all. To get forward from this we need at least two things. First one must realized the full meaning of the complexity growth and secondly one must understand that to meet the challenge of that complexity one needs a paradigm shift from procedural to object oriented world vision.  The two paradigms are orthogonal and they see the world from two different perspectives. There is nothing wrong with either paradigm as such. So the trigger for changing the paradigm must come from understanding how to manage complexity. The path to here has been rocky and difficult. It took over 30 years and a enormous hardware development from the IT-community to gradually understand this. This understanding did not reach critical mass before the late 90’s web bubble almost totally washed away this knowledge.

In the early days of OO during the booming phase the OO-applications where poorly designed due to lack of understanding OO thoroughly. This in average led to too low level of abstraction and at the same time also no separation of domain and application concepts and their implementations. This led to huge numbers of implementation classes with very little structure. Here the complexity exploded and the outcome was totally unmanageable. The most ambiguous and therefore the saddest expression that I know of this type was IBM’s San Francisco project. This was in the last years of last millennium and if I remember the figures right at some time there were 3500 classes and about 25 000 methods in it !!

SOA, talk about services and process modelling took the development backward at least 10 – 15 years and is still taking it share. I don’t know from which source the whole SOA came from but I think that it started from application server vendor and at least Web Logic was one of the early promoters. Today it can be found from major database vendors such as IB and Oracle.

Now I have a guts feeling that the tide have change again. With strengthening demands of lean and agile development the focus is moving to domain modelling again.

The best solution

The ADDD- approach in ideal case in an organisation leads to one single domain implementation that contains all the business functionality to mirror the organisations reality. Then there are a set of application that share the one and only domain core and build up from it to implements different workflows of organisation. This means that there is no separate integration layer but only one aspect of the domain implementation acts as an natural integration point.  This is theoretically the same approach the ERP-systems (like SAP) have. The drawbacks of current ERPs are that the implementations are quite old and they don’t have object solution.

The obstacles to achieve this:

  1. Abstract domain modelling seems to be more difficult for many people than I anticipated. This means in many cases that the skills to create good abstract domain OO- models with proper domain behaviour.
  1. Skilful people who can design and implement this are very rear today(well at least in Finland). Currently these people don’t form effective teams to really deliver what I have promised here.
  1. Packet software vendors’ and a general attitude is of course that packet solutions are without an exception GOOD. Packet software is indeed very good if or when the user is 100% ready to adjust to use the software as it has been implemented. The more the user requires changes into the product the worse the situation grows. Clearly to worst case is a company trying to cover their application needs by requiring many independent software packages.  As we in the early days of IT (somewhere mid 80’s) hade silo application and gradually this caused multiple occurrences of same entity in different silos. This led to growing demand of integration. In the given situation and environment this is at last very complex and in most cases mission impossible. Now a collection of unrelated (and un-integrated) packages is actually worse silo effect than the old department silos. In spite of that there is still a stubborn belief that packet solutions are far better than tailor-made ones. In tailored solution without skilful OO-implementation this belief might be valid. Of course all packet vendors promote this attitude.
  1. Actually the current ERP package solutions (like SAP) are implemented from the same domain model root ideas, but they are very old and they lack the OO-domain model. All this has resulted in a situation where the initial package has far too much detail and thus right from the start has a overwhelming load (in many cases completely unnecessary) detail.
  2. When ADDD is adopted it means dramatically decreased amount of work compared to current situation. The industry doesn’t like to reduce the amount of work and really be far more productive. This will have a huge and even cumulating impact on the whole IT-industry. The industry would like to see more work not less!
Advertisements