Encouraging Enterprise Services
- Enterprise Services save money. When done well, they create discoverable, supported, consistent, and reusable end-points for functionality.
- Enterprise Services cost money. They need constant monitoring, upkeep, maintained standards, and systems of financial connectedness that the business is not used to providing. These costs can overwhelm the benefits of some services, but other services can clearly pay for themselves.
If you accept both statements, then there is an obvious conclusion: we must encourage services to develop as described in the first statement, while ferreting out services that are too expensive to own or incapable of playing nice, as described in the second statement. This means that some services should exist, while others should not.
Fascinating problem, because a lot of the discussion around the generation of SOA architectures has focused specifically on the first statement. However, an unbalance approach to SOA will generate many of the services that it should not develop.
I want to add a third statement: Services that are 'correct' today may be 'incorrect' tomorrow. Here's why:
In the early days of retail, and still today in the smallest of towns, a single store provided for all the needs of the community. In the USA, the "general store" had already been replaced with boutique retail as of the late 70's when Walmart started to emerge. We've since swung back, with the small retail "downtown" of most towns going quiet while the Walmart on the edge of town draws away the business. Whatever you have to say about a disappearing lifestyle, or the poor wages offered by these megastores, the fact remains that retail goods are distributed more efficiently and at a lower cost now than ever before.
The point is that a model of service (rural retail) that was appropriate at one time is not appropriate at another. Just as retail has moved through this cycle over time, without central planning, we should expect that some areas of our SOA will do the same over time. There will be cycles between the use of centralized services and the use of distributed (boutique) services.
Right now, this is not possible. Right now, most enterprises have very nascent models that either rely deliberately on one or the other. That deliberate voice comes with a price: the price of control.
So, my third statement goes like this:
- Enterprise Services need to have a model where they may NATURALLY migrate from central to distributed and back without the central architects either driving or resisting the change.
Note that the city planning of most small towns did not change during the time between distributed retail and central retail. The investment by a clever company changed the landscape, to be sure, but the city planners neither planned for Walmart, nor did they prevent Walmart (in most cases). The growth was natural, not centrally planned, and organic. The result was displacement, but also efficiency.
So, we need models for details that we haven't really thought about:
- How do you "lay off" a service?
- How do you determine that a service is not worth keeping open?
- How do you compete in a services marketplace, to get consumers to come to you (we are talking IT SOA here).
- How do you create a 'data supply chain' that makes the distribution of data efficient and well run?
- When is it the right time to create a 'boundary' that encourages very specific services (think "boutique retailers") while discouraging consolodated service providers (like a "Walmart") from providing those services.
In city planning, any company wishing to provide services to the public has to apply for a permit. The rules for permitting are complex, and often a 'zoning board' will set rules that the permitting process needs to respect. This level of sophistication needs to be reached in IT, and fast, if we are to create SOA governance that hits on all three statements above. Otherwise, we risk creating the situation where we either stifle services, or create a rigid set of services that cannot adapt over time. That isn't better than COM. It's worse.