Friday, December 16, 2005
SOA: Cures Whatever Ails You - Maybe
The hysteria over Service Oriented Architecture (SOA) continues unabated. I haven't seen hype like this for an architecture since client-server went mainstream in the 1980s. Martin Fowler hit the nail on the head terming SOA "Service Oriented Ambiguity."
Of course, the vendors of software, services, training, books, and other essential elements of IT are all over this one with a vengence: "DO YOU HAVE A SOA STRATEGY??" screams one ad. Followed in another with: "IMPLEMENT SOA BETTER/FASTER/CHEAPER WITH OUR PRODUCTS!!" It's not surprising that vendors jump on fast moving bandwagons like SOA because, being vendors, they have to make money playing the tune du jour in the IT and development communities.
The problem with SOA, as Martin articulates, is that it means different things to different people, and that poses major problems when attempting to design enterprise and system architectures that are standard and robust. For example, I have run into more than a few situations where SOA simply means web services and little else. Or a refactoring and repackaging of data services previously handled as stored procedures in a database server termed SOA, in its entirety.
My advice is to skip the fad in terms of nomenclature and still keep selling EA to the business as EA. You may have an SOA, but so do your competitors and, it appears, everybody else...:)
Of course, the vendors of software, services, training, books, and other essential elements of IT are all over this one with a vengence: "DO YOU HAVE A SOA STRATEGY??" screams one ad. Followed in another with: "IMPLEMENT SOA BETTER/FASTER/CHEAPER WITH OUR PRODUCTS!!" It's not surprising that vendors jump on fast moving bandwagons like SOA because, being vendors, they have to make money playing the tune du jour in the IT and development communities.
The problem with SOA, as Martin articulates, is that it means different things to different people, and that poses major problems when attempting to design enterprise and system architectures that are standard and robust. For example, I have run into more than a few situations where SOA simply means web services and little else. Or a refactoring and repackaging of data services previously handled as stored procedures in a database server termed SOA, in its entirety.
My advice is to skip the fad in terms of nomenclature and still keep selling EA to the business as EA. You may have an SOA, but so do your competitors and, it appears, everybody else...:)
