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.
Advantages:
· 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.
Disadvantages
· 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
