This is good but I believe we have to take care of some good design principles here which if we don’t we will end up having big silos instead of small ones like we have now.
I believe SOA (Service Oriented Architecture) is the natural choice here, which simply says stop integrating and begin service enabling.
So what does Service enabling your software mean? It means your software should be publishing services which can then be used by any other application in your organization.
Service enabling basically means both , integration and flexibility or reusability.
To understand the concept let’s look into the traditional approach, whenever an application needs data from another application we do one of below things
1. Directly communicate with the database and get the data from it.
· It’s quick
· No need to go through painful process of approvals
· No need to wait for someone else to provide you the data or to develop something in his application you can use.
· Since you are not the owner of this data , and nobody knows that you are using it.The owner may change the data or it’s nature at any time without informing you and you will start getting all sort of errors in your application.
· Let’s say you applied some business rules on the data which you discussed with the owner of that application you applied the rules in your application. Now in future if the rules change you will have to keep track of where else you are using the same rules and it would become night mare in some cases.
· The ownership of business rules should be with a proper person/group , but in this case it’s not.
2. Force the user to open the other application, login again and view the needed information.
a. What if your user needs more information then shown in that page?
b. What if they want to see less information? Or wants to add more stuff to the same page?
c. In many cases you can’t just wait for the project lead of that application to create the page you want.
A much Better Approach:
While designing new Applications
We keep in our mind the service enabling principles , we can easily judge that this functionality of our application can be opened as a service or a web service. And then keep on creating those web services.
Of course we will need to maintain an inventory for those web services in future , but we can even continue developing web services and then organize those in an inventory in future.
Having Service Inventory will help in easily finding an already written service , organize services in proper categories , finding and approaching the owner of the service. Making sure we don’t redo anything.
What If an application was already developed and now you need to integrate it with other applications
We need to be very careful in these cases , many times reinvention of the wheel (developing whole application from scratch) is not needed , instead you can decide to keep using whatever there is since user is already utilizing the software with almost no problems and do all the new enhancements in a way that where ever you see an integration between two system you don’t integrate you service enable it.
Which simply means instead of writing tightly coupled code between the two applications , write the integration as service open for other systems in future if needed.
See this is the difference , if we decide to go by creating bigger systems integrated all the related modules inside one basket and ignore the service enabling principle we will end up having bigger problems J.
However sometimes based on the requirement it can be decided to rewrite the whole application , and this brings us to another point if the same application was being developed in a way that it had reusable services , re writing the same application will be less painful because you can still reuse a lot of service made for old application.
The below pictures will help us understand Silos and what can happen in future J