Thursday, November 15, 2007

Key Observations - Service Reusability - Does it really work?

From my experience, on SOA projects reuse was mostly accomplished with technical services/ infrastructure services. However, it is the business service reuse that we are struggling with as the Lines of Business (LoB)/ business units feel that their sub-set of the business logic is very unique. The problem is that most of these business services are rendered non-reusable due to the fact that they include both business logic and process sequencing logic into the same code base and it is the later that is unique to the LoB and not the business logic. Also, we have achieved greater degree of reusablitiy in terms of data access and informational services and not so much business function services that are a higher level class of services.

I would like to hear about what your experience has been with regards to service reusablity. Have you been able accomplish this.

Thanks,
surekha -

2 comments:

Lou said...

Service reuse is the most successful when the focus stars with reusable underpinning services begging for standardization. Enterprises leave a lot of money and operational capability on the table by not starting here.

This has to extend beyond simple constraints on vendor package acceptance to standards governing all operational areas: configuration, deployment, backup and recovery, monitoring, operational management, etc.

Examples of where more needs to be done are centralized, homogeneous management of application server farms, database instance management and so forth. We allow a lot of non-value added diversity in these areas, where in contrast we disallow this diversity in things like acceptable network protocols, mail services, network file services and so forth.

Although focus on these issues won't implement the typical vision of SOA by itself, it will certainly form a basis for greater success based on the development of the required operational and business capabilities, such as governance, service management and technical synthesis.

Ashok Kumar said...

The problem is that services are developed as part of some application project. No matter how much attentiion is paid to make a service generic, some application specific logic creeps in, rendering a service not quite re-usable. In order to be re-usable, a service must be kept free of application or process context.

Key Learnings - Using EDA to implement the core SOA principle of "loose-coupling"!!!

A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...