SOA is expected to give the corporates, that have a love-hate relationship with their monolithic legacy applications, a new lease of life. Clearly management of these legacy applications mainly in mainframes have become the single largest outlay of IT funds, on the other hand, amoebic growth (in terms of functionality and business processes and data) of these applications over time, has made it nearly impossible to replace these applications. To complicate the matter organizations are also losing people, who are the so called "Knowledge Centers" for these applications. Organizations are also facing numerous challenges in terms of business agility which can be traced back to the inflexible nature these applications and their embedded business logic.
The best possible way out for these organizations lies in creating services out of these applications. These services can then be reused to develop new business processes or modify existing business processes to cater to changing business needs.
But, how to go about this? Is there any standard methodology or approach for this? I have discussed about the top-down and bottom-up approaches in one of my earlier posts. Obviously both of them have their limitations and may make the whole initiative bite dust. No effort to identify and create services would be successful without understanding the existing applications and their routines.
In his article Finding Services in the Mainframe, Mike Oara ,CTO, Relativity Technologies, discusses "meet-in-the-middle" approach for service identifications in mainframe applications. I am sure this can be applied to any kind of legacy applications (mainframe, non-mainframe). He also talks about identifying potential services and harvesting them.
According to him...
"In this approach the service modeling team and the mainframe application experts work together to identify potential services that are both useful and feasible, given the existing legacy constraints"
He defines potential services as ...
"Application artifacts which alone or combined have all the characteristics of services"
He also goes on to add a few ways to dig-up functionalities from these applications and delves into the debatable topics like "service composition" and "service granularity". Finally he talks about importance of interactions and negotiations obetween "mainframe" and distributed applications" communities.
IMHO, there are still quite a few gray areas around Service Design? There are two schools of thought advocating different approacheds for Service Design
- Business Transaction Approach
- Logical Data View Approach
In Logical data view approach, a service would be defined with more CRUD type operations. I am not convinced that this is the right approach for designing services?
My preference would be to design services based on business transaction rather than logical data view. But, within the constraints of legacy applications, this option may prove to be road-block.
Where as, when developing new applications it would be appropriate to go for the business transactions approach and keep the data for the services close to the services. Talking about "Service and Data" I am reminded of this blog post "SOA Question: should we carve service independence into the database?" by Nick Malik . He mentioned that...
"If the services are designed well, there should be no cause for a single transaction that adds data under two different services."
This is only possible if we provide for data redundancy across services and synchronize them.
