On Mar 13, 2007, at 10:42 AM, Michael Poulin wrote: > Ann wrote: "IBM has created a central notification system that > ensures that lots of applications that contain redundant > capabilities are notified of a changes that impacts all of them. If > the system were truly service orientated, it would no longer have > redundant capabilities implemented in all these applications. There > would in fact be only one system that maintains delivery date > information." > > I disagree. If SOA reflects business model, then it has to accept > concurrent redundancy of the services. Does it make sense for an > individual enterprise - it is the business of the enterprise. > However, SOA solution should be capable of changing provider (and/ > or services) if current one violates Service Contract and/or > Service SLA. >
It's hard to take a blanket statement regarding redundant capabilities and say whether it is good or bad. Part of it depends on the current corporate governance policies. If the corporation has several lines of business where growth is the objective, it is entirely possible that redundant capabilities would be encouraged, especially if packaged applications are involved. At some point, the focus may shift to cost reduction, which is when the projects will spin up to remove the redundancy. The important thing is that you should have a clear idea on how this will happen from day one. All too often, these systems go in and no one even knows that the redundant capability even exists. As an analogy, take mergers and acquisitions. While I've never been through a merger or acquisition, I would hope that the two companies sit down at some point in the process and put their org charts side by side. They can identify the redundancy and choose to consolidate, or choose to keep the redundancy, if they feel the benefits outweigh the gains. In contrast, when IT shops acquire technology, is there a mapping of the architecture of the solution to the current architecture of the organization? This doesn't imply that redundant systems are put on the chopping block, but as part of the decision process, you should at least determine whether the architectures are consistent or not. Regarding Michael's specific comments, I don't know that a contract violation would necessarily result in routing to a new provider with interface consistency. I think contract violations result in routing to a redundant deployment of the same service implementation. There are other cases, as Steve articulated in the message that just popped into my inbox where redundant deployment does make sense. -tb
