Defining services for SOA, Web Services, etc.

I find over and over again that an obstacle to developing effective enterprise services boils down to the difference between something akin to the difference between a CustomerHasMoved() service and a UpdateAddress() service.  However the choices are worded, the essence of the alternative is between initiating a series of business processes or changing data.  This challenge presents itself as part of enterprise architecture work with SOA and should also be considered when doing the technical work of web services.  The enterprise is best served when both engineering and management tackle this issue.  The tricky part is that neither one is automatically the right answer and how to find the appropriate compromise.  Developing enterprise services that embrace the suite of business activities necessary when CustomerHasMoved is very powerful stuff... but projects can get stalled trying to do to the perfect solution while neglecting the good enough solutions.  Alternatively, enterprise data management services have their place but simple create/retrieve/update/delete services don't deliver much on the promises and potential enterprise services, SOA, etc.   In my own personal professional experience it has become clear that this is an essential question to be worked on with some effort, thought and care.  Enterprises service efforts that neglect or dismiss the point almost always do so at their peril.  What remains elusive is how to figure out the balance - something more sophisticated than "not too much, not too little, but somewhere in between".  This part I am still working on. 

No comments: