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 -
Subscribe to:
Post Comments (Atom)
-
The purpose of this blog is to get some validation for how I look at Business Processes vs. Business Services. In simple terms, I differen...
-
A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...
-
One of the key ingredient for success is clearly defining the roles and responsibilities within IT. There are multiple stake holders in IT w...
2 comments:
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.
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.
Post a Comment