SOA, What’s The Big Deal?
March 16, 2007 Alex Woodie
|
No disrespect to cavemen, but unless you’ve been living under a rock for the past few years, there’s no way you could have missed the IT industry’s intensifying infatuation with SOA, or service oriented architecture. Like new and revolutionary computing architectures that came before it, SOA is the wonder tonic that promises to cure IT’s troubles, once and for all. Or at least that’s what the vendors say. The problem is, with everybody and his grandmother now riding the SOA bandwagon, the wagon is losing its identity and direction. In its purest form, SOA refers to a framework for allowing distributed applications to communicate with each other with less dependency and “looser coupling” than previous integration technologies and techniques allowed. To work in a SOA, applications must be “service enabled,” which is generally understood to mean that the applications themselves are Web services and conform to the various Web services specifications (XML, WSDL, SOAP, Etc.). SOA assets are generally freed from their monolithic hosts, such as iSeries servers, using technology “wrappers” that come in two flavors: Microsoft .NET and Sun Microsystems Java. While Web services are the key deliverable in an SOA, they aren’t, in and of themselves, an SOA–a common misconception. Rather, an SOA is generally understood to refer to a collection of many services, which are self-contained, self-described, and don’t depend on the state of the other services to work (thank you, XML). The whole idea–the raison d’etre–of an SOA is to allow these services to be plugged into and pulled out of an SOA without the whole deck collapsing into a tangled, splintered mess. From a technical standpoint, that sounds great. Anybody who has worked with traditional enterprise application integration (EAI) tools can tell you horror stories of things falling out of synch as underlying constituents are ripped out, upgraded, downgraded, or otherwise breathed on from a slightly different angle. Who wouldn’t want a new EAI framework that, by definition, has already dealt with and standardized the ugly, dirty details of hooking applications together? We’re not quite there yet with SOA, but it’s a good and noble goal for the IT industry to work toward. The problem is, that big SOA dream is now being hijacked by vendors of all types. SOA has become the latest buzz word, the latest “must have” feature. Every product these days seems to be “SOA-enabled” or “SOA-based.” Where SOA once had a specific, technical meaning and a place in corporate IT–it’s the integration, stupid–it’s now being applied wily-nily by marketers determined not to let the latest IT fad pass them by. Just like the previous “game-changing” shifts in corporate computing architectures–client-server, open-systems, the Web–SOA is being called upon to be the savior, the silver bullet, the panacea of the legacy problem and IBM lock-in. What began as a promising idea for a better way to connect computers utilizing the untapped potential of self-referential XML and ubiquitous Internet connections has deteriorated into a marketing vehicle with so many baggage-laden riders even pork-happy Congress would be proud. Chris Lategan, chief executive of iSeries middleware developer ADVANCED BusinessLink, (ABL) just about can’t take it any more. “It’s become so misused,” he says. “Customers hear all the vendors using it for hype. The buzz on the street is it’s the right thing to do, but nobody’s really sure why.” Ron Grevink, director of integration strategy for Attachmate, has also identified the trend. “There was a lot of marketing hype behind it. It was the same thing with Web services, and before that, XML,” he says. “People heard that they wouldn’t need integration anymore, because SOA will do it. That definitely was not true for applications that were built in the late ’80s or early ’90s. The enthusiasm was fueled by not completely understanding the new technology.” Customers are crying out for education and clarity on SOA, what it takes to build one, and what benefits customers can expect in return. An analysis on people’s perceptions about SOA by ABL found that three-quarters don’t know what SOA means, one-quarter think it applies to them, but only five percent are committed to building an SOA, Lategan says. Attachmate’s numbers tell a similar story. Despite the saturation coverage by analysts and the press that would suggest everybody’s executing an SOA strategy, only about 20 percent of Attachmate’s 40,000 customers around the world are actively involved in SOA projects, and of that portion, only 1 or 2 percent are opening their SOAs to the world outside the firewall, Grevink says. But wait, it gets worse. In addition to getting more airplay than it really deserves, SOA has become code for “moving workloads off the iSeries,” Lategan says. “A big percentage of tools can screen scrape some workflows from the green screen and the resulting data turns into a Web service, and that data I’ll export to another platform,” he says. “They’re able to take data off the iSeries and use it in an SOA framework. But that SOA framework isn’t on the iSeries–it’s typically to be used in the .NET group or the Java group or with trading partners.” Lategan is bothered that SOA has become a Java/.NET thing, to the detriment of the iSeries “native” languages, RPG and COBOL. “While SOA holds a lot of promise, there is no fundamental SOA framework on the iSeries, for use and benefit of iSeries programmers. Not at all. It’s there to harvest stuff on the iSeries.” The assertion is largely true, Grevink says. “To me it doesn’t make much sense to enhance the green-screen applications running on your iSeries,” he says. “To me it makes sense to do enhancements on other applications. Your iSeries application is pretty much becoming a black box–it runs like it is, with a service interface to the outside world, but any new development is taking place on other applications. [With SOA] you can see uploading business functions on the iSeries to other applications . . . or maybe thinking about redeveloping or migrating off iSeries. It makes it easier to migrate away from green-screen applications.” Attachmate’s SOA strategy is similar to the SOA strategies held by many other integration software vendors with histories in the emulation space. ABL’s Lategan thinks that leaves him an opening to sell products that keep the SOA within the iSeries family and provide RPG programmers with SOA tools. That is the main thrust behind a new product ABL is developing called Strategi SOA. Strategi SOA, which is debuting next month, will provide support for a native OS/400 enterprise service bus (ESB), support for consumption of WDSLs, and freedom to generate SOA user interfaces in the language of one’s choosing (except RPG and COBOL, unless you want to keep your green screen user interfaces). The idea with Strategi SOA is to give RPG developers and iSeries servers a full share in companies’ SOA strategies, instead of relegating them to supporting roles. The idea is to make SOA a reachable and worthwhile goal for iSeries shops and RPG programmers. Lategan tells the story of four Fortune 500 companies that are looking at Strategi SOA. All of them have significantly larger RPG staffs than Java and .NET staffs, but the reigns of the IT department invariably are held by CIOs with a Java bent, which creates a certain level of dysfunction. The IT departments got that way because the RPG folks were skilled in business logic but didn’t have the tools to take on new projects, while the Java and .NET folks were good at new projects but didn’t have the knowledge of business logic to really complete the tasks. The result is a mish-mash of inflexible, monolithic RPG code and flexible, but limited Java and .NET code, and no clear way to unite the disparate code bases. Lategan sees Strategi SOA as a way for the highly productive RPG teams to take back control of the data center, to help the platform gain a little dignity and self-respect, and put to rest all those awkward and misguided attempts to hang with the cool kids (that would be Java and .NET). “That’s why we’re so exited about Strategi SOA–it empowers RPG programmers to develop SOA applications natively on the iSeries,” he says. While ABL and Attachmate have different visions for SOAs, they both agree that customers are best served with an incremental approach to SOA over the big-bang method. “We teach a methodology where to start to build an SOA, you start with monolithic code,” Lategan says. “If you have a 60,000-line piece of code to service-enable, you won’t have time to build it from scratch, so you break it out into services, and the program is consuming its own services. So it’s an incremental change-as-you-go methodology. Attachmate’s Grevink agrees that customers are better off with a phased SOA methodology that calls for incrementally service-enabling their screens, a little bit at a time. “I’ve been in projects for migrating from one mainframe to another, and there’s lots of risk involved,” he says. “You’re working from Friday afternoon to Monday morning, with no breaks, and there’s always some mainframe function you forget to migrate. That’s the nice thing about SOA–you slowly decide to migrate functions.” Risk-reward analyses are inevitable and necessary in forging corporate IT strategies. Despite the hype, one would be foolish not to look at the potential application integration benefits that SOA can bestow. And while the freedom to migrate among computing platforms is one of the effects of an SOA, that’s really a bonus, not a detriment, because it helps empower the user over his vendor and avoid lock-in. However flawed, SOA is IT’s best hope forward. Like every entity, IT must evolve or die. Even a caveman could tell you that.
|
