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 customer feedback as to what the product features should look like, and we needed to sell some software to interested customers. So inviting a potential customer to help design the features they wanted (provided they would sign the contract) looked to be a win-win proposition. What we have discovered in the intervening years, however, is that a few of the early customer-designed features don't make sense for the rest of the customers who have since joined our happy family of users. And a couple of features don't even make sense for the customer(s) who originally requested them!

The root problem in these situations was that we did not have enough subject matter expert involvement, and not enough enough attention given to implementing the feature generically (i.e., in a way that could be used by many customers). Sure, we would have had to provide a little extra customization code so that the initial customer could have what they wanted (on top of a generic implementation). Unfortunately, designing the feature for the peculiar needs of a specific customer was tantamount to putting their customization code into the code base for everyone else--not a good idea. And now that the customer-specific code is in there and part of the API, it's hard to extract.

I'm not knocking the overall feature set of our product, by the way. It provides a lot of value for non-profit organizations, and is for the most part implemented generically enough to avoid putting our customers in awkward situations. I'm just saying we made a few mistakes along the way, that's all.

Now let's apply this lesson to enterprise SOA: do not throw the task of modeling and designing a reusable service over the proverbial fence to the first department in the enterprise that needs the service. That department may very well drive the service design towards meeting its peculiar needs and computing environment, much as some of my employer's customers drove our enterprise CRM product in the occasionally odd direction. And then you'll have a service that's hard to reuse. Erl mentions the importance of getting subject matter experts (SMEs) and technology experts involved in modeling services to avoid this danger, and I heartily concur.

However, ISVs are doing a poor job if they restrict their reusability analysis to the involvement of SMEs and technologists. Successful ISVs always have a product management team (or at least a product manager, if the product is small) that is responsible for making sure the product's features and design meet the needs of the target market...not just the first customer, or even the existing customers. Of course, the product management team has subject matter expertise, but they also have the important responsibility of keeping the needs of the entire target market in mind. Without product management, a product can become incoherent, reflecting small and immediate concerns rather than the long-term big picture.

Likewise, an enterprise that is building an inventory of reusable services needs to have an enterprise architecture team that bears the responsibility for modeling the services in the SOA. The enterprise architecture team plays a role similar to the product management team in an ISV. Do not delegate the responsibility for modeling reusable services to departmental implementers--or even a collection of implementers from various departments--if you want them to be truly reusable.

Our product management team doesn't arrive at their conclusions by simply theorizing, or by having many conversations with individual customers. They do those things, yes, but they have also invited key customers to join a product advisory group (PAG). This group meets regularly to discuss which features are most important, and how they can be most effectively implemented. They have to deal with the trade-offs in the iron triangle (time, resources, features) jointly. Because these customers are talking with each other, and not just with our product management team, they can hammer out agreement about which features should ship when, and how they can be generically implemented.

Similarly, if you are trying to work out a service inventory blueprint in your enterprise, you should be gathering decision-makers from all the participating departments and asking them to help determine which services should do what, along with the order in which they should be developed. What shall we call this group? How about "Service Priority Advisory Group Helpfully Elaborating TimeTables of Implementation" (SPAGHETTI)? Whatever you call it, though, form your group and work with 'em.

To conclude the lesson, here are the principles we can apply to modeling reusable services that we have learned from ISVs:

Do not rely on departmental implementers to model a reusable service for the enterprise--the resulting service will likely reflect the unique concerns of the department, and be hard to reuse elsewhere.