Rationalizing SOA for success - David Worthington

February 3rd 2009, David Worthington, SD Times

In these uncertain economic times, IT budgets are tightening and service oriented architecture projects are at risk of flat lining. One of the keys to sustaining long-term SOA buy-in is implementing projects incrementally, ensuring success while minimizing organizational change—and generating revenue to boot.

Knowing how to successfully implement SOA requires an understanding of why some projects have failed. SOA has significant organizational change implications, and overly ambitious projects can be unsustainable due to high upfront costs and low initial return on investment.

"SOA is not just a technology change, it is something that needs to be dealt with like any other business change," said WSO2 CTO Paul Fremantle.

SOA challenges organizations and organizational funding models, he explained. "People in the organization feel threatened by change, and companies have taken on SOA without realizing there would be resistance."

Many organizations like to keep their silos clean and push cost and complexity onto other groups, said Miko Matsumura, deputy CTO at Software AG. "For every silo, there is a tribe with its own political interest to horde things."

One of the principles of SOA is software reuse, and organizations benefit through increased agility and cost savings when there is more sharing of resources, Matsumura said.

"The question is translating what enterprises want into the behavior of an organization and individuals," he said. "Tribes act in their own self interests, and the value of SOA can quickly fall way by the wayside."

Matsumura suggested that organizations connect behavior to motivational drivers such as job reviews, bonuses and other compensation. "Organizations should structure incentives programs and link them to best practices behavior," he said. "Without discipline, air goes out of the tires. When the kids fight, you've got to call dad. Executives should be engaged at a reasonably high level."

Specifically, C-level executives are needed to sustain the effort, Matsumura said, explaining that it is because those executives witness the cost of the bickering.

"There is a natural alliance between architects and executives: The architect sees the big picture, and the C-level pays for the big picture," he said. He added that executives also need to have a clear understanding of the implications of SOA.

And indeed that seems to be the trend. Business leaders want to get involved in SOA in a variety of ways, said Sandy Carter, IBM's vice president of SOA and WebSphere strategy. "It is a best practice to have an executive sponsor that has business knowledge or acumen to focus on how SOA can bring value to the business."

The best way to sell an executive is to start out with well-defined projects that have well-defined ROIs, such as replacing error-prone or complex processes, said Fremantle.

"One of our customers put in place SOA because they saw instant cost savings of US$250,000 per year, and the project cost just $50,000," he said. "They picked the right project where ROI paid off quickly and no department's budget or people were threatened."

However, developers should take care not to over-promise on what they can deliver. "Last year's theme was, 'Let's seduce the business unit and tell them incredible things like that we will be developing applications within hours.' That was a lot of promises and smoke and mirrors," said Matsumura, who is not alone in his assessment.

"The industry took the SOA concept and turned it into more than it was; the acronym became over-hyped a bit," said Rourke McNamara, director of product marketing at TIBCO.

Buying into SOA during a downturn

Past should not be prologue: ROI is now crucial for funding SOA initiatives. "The funding philosophy has changed [for] 2009," said Jerry Smith, CTO of Symphony Services.

In 2008, programming managers could make the case that SOA was an investment that would ultimately decrease maintenance and long-term costs while increasing agility and usability, he explained. "CFO's won't make that investment right now."

"Folks that were heading down the SOA path already are continuing to invest, but there has been a dramatic drop in the number of people starting SOA in 2009," McNamara said, citing recent surveys by Evans Data Corp. But developers can still make the case for investment, Smith believes.

Tying SOA efforts to margins, revenue and customer satisfaction is what is resonating with CFOs today, Smith said. If developers pick services that clients will subscribe to and pay for, they will have an easy ROI proof point, he explained. Services that take costs out are also low-hanging fruit. "If developers can use SOA projects to keep revenue flat, they will still be ahead of the game."

Another argument for continuing project funding is customer satisfaction, Smith said. "CFOs are afraid of losing revenue," and any customer-satisfaction survey that implies 12-to-18 months of diminishing revenue will be taken seriously, he explained. "From a sales and marketing perspective, it is, 'If we don't do this, we'll lose our competitive edge in the marketplace.' "

"No one will be building applications from the ground up without reuse 10 years from now," said McNamara. Programmers should be looking at a catalogue of services before they build something, he explained. The automotive industry gained efficiency a decade ago when it began reusing parts from catalogues instead of designing and ordering new ones, he said. "You don't need 10,000 different screws in a single car."

Businesses already measure revenue per employee, and they should now be concerned with revenue per service, Smith said. "Show that there is future value for the company based on a sustainable SOA innovation model. It is easier to walk to the table with that research."

While ROI is a key factor, people need to feel that they are benefiting. Otherwise, ROI means nothing, observed MuleSource CTO and co-founder Ross Mason. "End users need demonstrated value."

Baby steps

Developers can build sustaining SOA and get to scale by following a pragmatic maturity model that has well-formulated and identified projects supporting a business need. Then they should show the results, said Tim Hall, director of Hewlett-Packard’s SOA Center products. "It has a viral impact when you approach from that perspective rather than an ivory-tower type of approach."

Picking projects carefully also benefits long-term success. From an organizational perspective, SOA should be a step-by-step approach where success is documented at each stage, said IBM's Carter. "It can be demonstrated across one group to the next project that this is the successful way to implement."

"One thing that you can do is to have the person who did that project become an evangelist for future projects," said WSO2's Fremantle. Successful teams can help mentor other parts of the organization, he added, noting that SOA cannot be mandated.

Top-down approaches driven by architects without developer buy-in end up failing, said Fremantle. "When SOA hits developers, they think, 'What does this mean? How do I change the way I code?' " he said. "Many failed projects have been done in a waterfall like way."

The top-down approach is great “for redoing a project you have done before, but if you are doing something new and people aren't up to speed, there is a significant challenge," Fremantle said. The project structure did not allow developers to take advantage of learning from mistakes, he noted.

"Successful projects I have seen have been bottom up," he observed, noting that ROIs are also hard to achieve if you start top down due to heavy upfront costs. "Those customers don't meet ROI [and] put organization changes in place, and people feel threatened. You can see how it quickly spirals out of control."

Coordinating contributions for successful SOA

As projects grow, governance comes into play, Fremantle said, adding that governance does not always have to be implemented in a "heavyweight way." Companies should have a simple way for every developer to share what they are doing in a SOA, and to communicate with other people about those services, whether it is as simple as a wiki or a full-blown service registry, he said.

The second thing to do is to have some kind of quality metric for each service, according to Fremantle. Each service would have a simple checklist of interoperability, support and testing information, he noted.

"The more quality measurements that you have in place from day one, the more developers trust that the services that are being built are resilient and useful," said Fremantle. Automating complexity and policy enforcement should come as a second step, he said.

"SOA governance is one of the key things about adopting this type of architecture," said HP's Hall. Governance lets organizations set goals and objectives, in addition to helping stakeholders collaborate and coordinate activities, he said. Policies provide automation and compliance to best practices regardless of cultural issues, he added.

Registries are expensive, but they add value by preventing conflicting services, said MuleSource's Mason. "The industry needs to change. Things have been prohibitive to the masses to hold onto SOA without spending lots of cash. In this climate, that is going to fly even less," he opined. MuleSource develops an open-source registry called Galaxy.

"Big bang" approaches, where companies implemented SOA top down, were false starts that individual companies could not take on, Mason said. "Companies needed a large vendor from start to finish, and [they] handed over the reins of their software systems."

IBM's Carter also advises against overly ambitious SOA implementations. "SOA is an evolutionary, not revolutionary, journey," she said. "In 2005, customers had the notion of a 'big bang'—that effectively all they had to do was to get an ESB (enterprise service bus) and repository in place. There are more business-focused deployments now."

Carter offered the financial industry as an example where SOA is a driver to help businesses understand how to reuse parts of processes when they experience mergers and acquisitions. For those specific objectives, she said that SOA provides the underpinnings of a dynamic architecture that is more responsive to change.

When developers do not start off small, they may fail to achieve anything. "People who think they'd solve SOA transformation by dropping [an] ESB into an environment will end up in the trough of disillusionment and be fairly unhappy," said TIBCO's McNamara. The successful SOA implementers are not the ones that started out and said, "Dump everything and do it all differently," he added.

Organizations need to rationalize SOA, advised Software AG's Matsumura. "There is no better time to rationalize than during the downturn." Targeted SOA implementations can help reduce operational costs and help align IT infrastructure to the needs of the business, he explained.

Aligning IT to the needs of the organization will help alleviate some of the frustration business users have with the time that it takes IT to deliver new functionality, said McNamara. "In order to do new things, business users must wait 12-to-18 months. By moving to this approach … companies are able to deliver requirements and applications that businesses are asking for, significantly faster."

SOURCE : http://www.sdtimes.com/link/33238