I saw this article by David Kelly today, "The 'Longer View' on SOA Reuse" in which he discusses the need for various collaboration technologies and approaches in effective SOA. A couple of his comments made me think of how business rules and how they can play a role in SOA and in delivering re-use in an SOA. The first comment that caught my eye was when David said:
It’s also about creating, fostering and enabling a more collaborative development process and collaborative technology environment than most organizations are used to
He is absolutely right about this and it is one of the reasons I think business rules have so much to offer SOA. The ability to collaborate or do what Forrester calls Concurrent Business Engineering with Business Rules makes for a collaborative environment even down to the business logic in the services themselves and so resolve some of the issues of different perspectives. He goes on to say:
but the work actually starts once that service is successful
Indeed. This is what some writers have called "change time" and realistically it represents the vast majority of the lifetime of a service. While David lays out a number of steps to cope with this period, I think you also need to get set for change time by using business rules and that this can really help with services that are constantly changing. He also goes on to say that
developers, testers, operations personal and potentially even partners or customers gain a broader understanding of how services are defined, where they should be used, and how they’re supported.
and this means that the business and IT need to collaborate and learn to love, not hate, change.
Happy Halloween.
Technorati Tags: BRE, BRMS, business agility, business rule, business rules, Forrester, service, SOA