SOA unplugged: what readers had to say about SOA in 2008
I'd like to take this opportunity to thank all you readers out there for visiting this blogsite over the past year, and I appreciate all the feedback and commentary received through the TalkBack feature. A lot of compelling and frank views were shared and discussed.
I thought it would be interesting to repost some of the comments that some of you provided over the past year as they relate to SOA issues discussed.
On the relationship between SOA and Complex Event Processing, James Taylor said: "I think one of the powerful effects of automating and managing operational decisions is that it helps link SOA, EDA/CEP and BPM. Decision-making logic must be shared effectively across these different approaches and that means that decisions must be identified and managed as first class objects."
On the relationship between SOA and business process management (BPM), Chris commented on the challenge of achieving stateless and loosely coupled services: "We have been looking for ever more flexible ways of creating components. We have been looking for as little coupling as possible between our components because that makes it easier to localize changes and reduce unwanted side effects. We have been looking to increase cohesion because keeping 'things' that belong together together gives us an easier way to manage the thing. We create deployment mechanisms that allow us to scale our components by adding new instances. We create deployment mechanisms that keep the functional behavior away from the operational details. But still we have trouble with the right level of abstraction to get value out of the components. That's partially because we have relative complexity in our businesses, we are encouraged to design for the 'pretty case,' i.e. the case where stuff doesn't break and we don't deal with timing and ambiguity well... So the hope of having 'process stateless' services is a longshot. Nice to strive towards, but not easily achievable."
On SOA and economic conditions, Kirstan said: "If the economy is turning down, then free and open source tools to help build and run an SOA make more and more sense. Open source tools like XAware for data services, ActiveEndpoints for orchestration, Mule or ServiceMix for ESB, are quite mature. Aside from saving money in a downturn, open source tools make even greater sense for 'project level SOA,' where a company can build an SOA in the small before committing to an expensive enterprise-level SOA.
On SOA even makes the US Marines nervous, Jabailo1 said: "SOA is the only way to go. Unfortunately for large organizations which have grown fat and stupid on "application servers", outsourcing and management pay increase, it also takes finesse, intelligence, hard work and most of all -- that bugaboo word -- programming! Yeah, all those guys you laid off seven years ago? Those are the guys you want. All those guys you kept and made into "technology managers" and gave 14% per annum pay rises while they shipped the budget to Bangalore? Those are the guys you want to get rid of..."
On the "emergence" of event-driven architecture (EDA), Rob Eamon said: Analyst groups "have been promoting the notion of the event-driven enterprise for over a decade. In my opinion, EDA and SOA are orthogonal notions. One doesn't subsume the other. A business or enterprise architecture is likely to adopt, or should adopt, principles from both approaches."
On reuse being a primary goal of SOA efforts, Eelcoh said: "SOA should not be about reuse at all. If there is, and will be, only one consumer, there might be two different situations: 1 - The providing department is wrongfully made responsible for the process (that might happen). In this case, it does not make a lot of sense to have that department provide the service, but unless the right department is found, the alternatives aren't that good either. 2 - It just happens to be that there aren't that many consumers. In the second case, there should be no question about who should provide the service. The alternative would be that the consumer one way or another replicates the process. That is what SOA prevents. So one could say it is not about reuse, it helps to reduce. In the end, in my opinion, SOA is about isolating change, but I doubt whether the vendors understand that."
On 'how to tell it's not SOA,' Tonymcs flipped the scenario with 'how to tell if it IS SOA: "If it it doesn't work, it's SOA.... If its a 3 hour lecture with no information content, it's SOA... If it's recommended by non-tech people, then it's SOA... If it's as useful as art criticism, it's SOA... If it's slow, it's SOA.... If it's spaghetti Javascript, then it's probably SOA..... If it's a bunch of services you'll never use, it's SOA.... If it's a category looking for a reason to exist, it's SOA."
On the evolution of computer science to "service as a science," Storm14k said: "Sometimes I laugh at these paragraphs that basically say nothing or restate common place scenarios with a lot of business buzzwords: 'Service systems are complex systems that dynamically configure access to resources (people, organizations, technology and information) to interact with other service systems and mutually create and capture value....' Now ask one of these guys to build a concrete example of this and then the truth comes out. Its a load of crap and once they do figure it out they'll turn to the nearest guy with a CS degree to implement it anyway."
On selling SOA to the business, Jean-Jacques Dubray said: "There is nothing ethereal about SOA. The very reason why most people think SOA is ethereal is precisely because most developers, architects, business analysts were never presented with a comprehensive view of SOA. Most people claimed they were doing SOA 20 or 30 years ago and that WS-* is not SOA. The reality is quite different, concepts such as bidirectional interfaces (WSDL), semantically accessible data structures (XML), orchestration (BPEL), forward compatible versioning (XML, XSD, WSDL)... are all brand new ideas that never existed before 1998 or so. SOA is only ethereal if you care to ignore these concepts."
On SOA as a strategy for times of economic turbulence, Robert Morschel said: "Not convinced. The biggest problem that SOA is trying to solve is the total cost of ownership and the lack of agility caused by years of tack-on systems development. That's where the big money saving potential is, not making business processes more efficient. I agree SOA introduction needs to be iterative, but against the backdrop of an already persuaded business who are sick and tired of paying 60-80% of their IT budget just on maintenance costs not new development."
On whether SOA may be a faddish -- and even sloppy -- approach to management,Donald said: "Those who say that SOA is just a fad or a buzzword do not really understand all the necessary concepts, governance, new application development and execution paradigm, and technologies needed to implement the simple concept of SOA. For a decade people had hoped that PKI [Public Key Infrastructure] would just go away because implementation is too complex for most people to want to understand. But today PKI is the only name in town for various identity purposes. SOA will not go away because it is the only name in town to shorten time to market and to save millions of dollars."
On whether SOA is more about integration or architecture, GGruber66 said: "SOA=Integration is a very narrow view. And most people who are looking at it that way aren't just missing 1/2 the point of what SOA can do, they're also missing 1/2 the point on integration. SOA is not a panacea for integration. Passing data is easy, but if you're not moving to the business process aspects of 'what do I do with the data now that I have it' you've missed the boat. And SOA doesn't do that. Frankly if all you want is integration, just use a service like Boomi. SOA's real impact is felt when people expose services to others and allow people to create new capabilities and new products or services (I don't mean Web services). And when they take their eye off the fact that as you state SOA is an architecture, the services that they create probably won't meet the requirements for reliability and availability that businesses large and small demand. This is what happens when people fall in love with a buzzword and don't try to understand the business value that it's supposed to create. The SOA projects that fail most are the ones that start with SOA as the answer before anyone really thinks about what the question was."