Interesting link in the loosely coupled blog on Change Time. Phil Wainewright has some great pithy comments about what happens to deployed services:
Services have to operate in the real world, where nothing can be taken for granted and nothing is set in stone
I could not agree more. But what do you do if you have a service that you know is going to change a lot? Are there not better tools for building those kinds of services? I think so -and I think those kinds of services will often be decisioning services. I think you could use a business rules management system like Blaze Advisor to design these kinds of services and protect yourself from change by empowering the business users to take control of the rules in these services.
Conventional software tools do a poor job of catering for the change-time phase of the development lifecycle. This is a problem, considering that change-time represents the entirely of the lifecycle except for that thin sliver of design time before a service is initially deployed.
All true. Again, often the highest change components of an architecture are those that make decisions - policies change all the time, regulations change all the time, competitive pressure changes all the time etc. Business rules management software lets IT focus on what kinds of rules are needed and on setting up an architecture to manage those rules while letting business users worry about the specific instances of those rules in place at any moment. This works LONG after the service is deployed.
I talk more about the benefits of business rules here in my FAQ and have a few posts on rules and SOA here. SOA is a great way to position yourself for change. Using a business rules management system to implement some of those services can make it even easier.
