September 2010 Entries
In Part 1, I introduced Thomas Erl's notion of adopting the reusability analysis practices of ISVs when modeling reusable services. Today we look at what this entails. First, let's take a look at what happens to software that's supposed to be reusable if you do *not* perform reusability analysis. When my employer was launching its first enterprise product a few years ago, we allowed our first few customers to dictate the details of many features. This practice had a certain logic to it: we needed...
Thomas Erl insists in his magnum opus, SOA Principles of Service Design, that you do not need to goldplate a service's capabilities, or consult with Madame Zelda and her crystal ball, to make the service reusable for future consumers and compositions. Certain types of software that we have been using for decades--operating systems, business productivity software, almost anything an ISV produces--have benefited from a lot of up-front analysis of reusable capabilities. If your software is being used...
Services, designed right, have much more runtime autonomy than components. That autonomy gives you much more ability to manage the security, reliability, and reusability of the encapsulated logic, although there can be a small cost in system performance. And service autonomy makes changes quicker and easier. That ability can save your bacon from time to time, just like it did for me one morning when I got to work....