Services oriented architecture (SOA) has proven itself very much alive with companies finding success with their initiatives. Yet, some struggle with SOA because they’re doing it all wrong, said one Forrester analyst.
“It’s not that SOA itself is necessarily sick, it’s some of our approaches to SOA and how we do it are not the best,” said Randy Heffner, vice-president of Cambridge, Mass.-based Forrester Research Inc.
Speaking at the opening keynote of the SOA in Action virtual conference Wednesday, Heffner said SOA is difficult and complex due to the myriad things that require a different way of thinking.
For instance, SOA – an architecture that reaps business agility through improved business processes – is too often seen as a technology and not a means of achieving strategic business transformation.
Heffner said SOA is frequently taken to mean “the latest way of packing things like objects and components,” but the problem is that ties the approach to technology and nothing else.
Part of the issue, too, is the fact that industry messages about SOA don’t exactly help keep SOA on track, said Heffner.
Take the concept of reuse. If SOA is overly guided by reusability, then services will be developed atop what is perceived as potentially reusable, said Heffner. But making predictions about what is reusable within the enterprise has never been very easy.
“It’s an amnesiatic way of going about development,” he said. “It’s not all about reuse, it’s about the right design, and reuse is the side effect that should be happening as you’re doing good design.”
Another misperception about SOA is that it’s all about creating services and dropping them in a library, said Heffner. The problem here is the lack of direction for service creation won’t ensure a connection to the business. A services portfolio, not a library, is a better “guiding light,” he said.
Looking more broadly, Heffner said another error is viewing SOA as the end goal when it’s really the approach to a flexible business. Work the SOA strategy into the solution, he said.
Taking a “big bang” approach to SOA doesn’t work either. That often leads to the thinking that all of sorts of infrastructure components must be bought at the outset, which causes unnecessary monetary concerns, said Heffner.
Instead of a big-bang tack, take a “street-level strategy approach” by working from the service portfolio in an incremental fashion, defining only near-time specifics, said Heffner. Longer-term things like service lifecycle management can be vaguely defined for now.
In an interview with ComputerWorld Canada, Judith Hurwitz, president of Newton, Mass.-based Hurwitz & Associates and author of SOA for Dummies, said a roadmap that defines the business problem to which SOA is being applied is necessary.
For instance, the ultimate goal might be to have the ability to create a set of services that reflect the main functions in a business, like customer account creation or customer address change notification, said Hurwitz.
That way, one will avoid the mistake made by early SOA adopters who created hundreds of services that nobody used because they were not mapped to the business, said Hurwitz.
In the same vein, a focus on process before creating the service will ensure usefulness.
As for a starting point for SOA, Hurwitz acknowledges the options are numerous, but it’s best to first pick a project with relevance to the business, so that its success will directly impact the bottom line.
“Focus on things that really make a difference,” said Hurwitz.
A realization that SOA is ultimately about the business will ensure that the initiative is perceived as more than just coding, said Hurwitz.
“If you build a library of services, and sit back and be proud of yourself that you coded so well, it has nothing to do with the business,” she said.
