--- In [email protected], "Anne Thomas Manes" <[EMAIL PROTECTED]> wrote: > > On 7/4/07, Hitoshi Ozawa <[EMAIL PROTECTED]> wrote: > > > > Gervas Douglas wrote: > > > She suggested measuring business improvement to track SOA progress and urged > > > users to model their business, not their technology, when setting out on the > > > path to SOA. > > > > > +1 IMHO,I think it's important to properly define a "service domain" and > > to create a model from which to > > define services. Using web services or REST is not going to improve > > business too much if at all, but they are > > fun technologies nonetheless. > > > > > "The technology really is irrelevant," she said. "The technology you use today > > > is going to go away at some point. It's about how you use technology, not what > > > technology you use." > > > > > +0.5 Logically, yes. But IMHO there's actually a limitation associated > > with each technology that's available now. > > In actual implementation, I think it's necessary to choose a technology > > to be able to do what one wants. > > This was a quick news summary of my keynote speech, so as you can > imagine, it doesn't fully reflect all the things that I said. I > clearly indicated that the technology selected would impact the > capabilities of the system being developed, and therefore > designers/developers should choose their technologies carefully. I > also recommended that the requirements of the system should drive the > technology decision. > > But the primary point I was making was that SOA is not dependent on > any particular technology. You can implement service-oriented systems > using any type of technology. And you should assume that 10 years from > now we're likely to have a completely new set of technologies to > choose from. Few middleware technologies remain in vogue for more than > 15 years. Nonetheless, a service-oriented design should survive a lot > longer than SOAP will remain in vogue. So designers/developers should > do their best to maintain a separation of concerns between their > services and the middleware they use to implement and expose those > services.
Anne, I don't think anyone would disagree with this. One of the obvious issues with SOA structures is integrating legacy systems which were designed as isolated monolithic systems, e.g. 370 mainframe proprietary UNIX systems. Can you be more specific, please, as to how one can best future-proof a new SOA-based system so that the modules can be as integrable as possible for as long as possible in the future? Gervas > > > > > It all came back to Manes' assertion that "technology is irrelevant." She said > > > that governance, quality and management are the keys to a successful SOA, not an > > > integration bus. > > > > > > > > "Technology is irrelevant" similar to as in Carr's "IT doesn't matter"? :> > > Similar, but different. Carr's point was that IT has become so > commoditized that it no longer gives an organization a competitive > advantage. (It's still an essential aspect of the organization, > though.) The rise of the COTS and SaaS business models are an > indication that most organizations rarely use IT as a competitive > weapon--for most systems, they use what everyone else uses. But I > think the new flat economy (i.e., "The World is Flat") is changing > things to such a degree that IT clearly can give an organization a > competitive advantage. And SOA can make an organization much more > nimble in a flat world. If you want to be able to outsource big chunks > of your non-core capabilities to other companies that specialize in > those capabilities, you must be able to integrate your core capability > business processes with those of your out-sourcees. > > But the technology that you use to implement the services really > doesn't matter. What matters is the design--the capabilities exposed > via services and the data (message structures) used to interact with > the services. That's what can enable business process integration. > > Anne > > > > > H.Ozawa >
