Whether you’re from the ” All Hail, it’s SOA” cheerleading camp or the ” oh hell, it’s SOA” detractors squad, one thing’s for sure: SOA is solidly rooted in the land of now.
“SOA is not coming; it’s here. There’s a 99% chance some SOA has infiltrated your company already, whether or not you chose to go there,” says Frank Kenney, research director at Gartner Research. “Just about every technology is built on SOA these days,” he says. SOA is touted for its efficiency and agility, and if at least some of the stuff is already in place, indeed in every place, why isn’t anyone getting to clock out and go home early?
“SOA is the latest phase of a constant evolutionary march toward greater functional decomposition and distribution on the network,” explains Paul Strong, distinguished research scientist at eBay. “Modularity and reuse offer greater flexibility, agility and return on investment. However, it also drives you towards managing more and more things, managing the explosion in the number of relationships between them, and managing the life cycles of both the [services] and the relationships.”
It’s the problems within the relationships that keep most IT people up at night, and those usually begin with defining the affair.
“Reuse is the consistent focus among CIOs in the United States, but it isn’t the issue among CIOs in South America, South Africa, the Middle East, and the Asia-Pacific,” observes Kenney. Outside the States, he says, the worry is not over saving IT staffing costs, which can be quite minimal, it’s over milking every last advantage from what the company already has in “parts, processes and people, even old legacy assets.” “Here it’s about reuse, there it’s about business processes,” says Kenney. “But it’s the combination of BP and reuse that’s really interesting.”
That may be true, but reuse is still part of the coupling so how is one to get from the proposal to actually marrying the various and sundry elements? “As a general rule, to achieve maximize benefits, reuse those services that your programmers use in many applications,” advises Julie Craig, senior analyst at Enterprise Management Associates (EMA). “Better advice would be to find yourself the best SOA architect you can find, and let him or her make those decisions.” Like a high-dollar wedding planner, an SOA architect can spare you mistakes and embarrassments while making the big event relatively painless, mostly by eliminating any unforeseen and unwanted surprises.
“As the SOA program takes shape in an enterprise, complexities tend to increase as the concept of reuse is not practiced and monitored at times,” says Dr. Santosh Mohanty, head of Global Technology Excellence at Tata Consulting Service (TCS), a leading global IT services and consulting firm aka SOA architects.
According to Mohanty, establishing an SOA governance mechanism will define and establish the policies and procedures to manage ownership of services, streamline the mechanism for communicating about the services available, ensure reuse and measurement of design-time, run-time and change-time metrics. “This enables enterprises to proactively manage any cost overrun effectively and ensures that the SOA program is under control,” he says.
Assuming you wish to plan the reuse efforts yourself, or that you wish to oversee your SOA architect with an inkling of knowledgeable authority, where should you begin?
Start with understanding the pros and cons of SOA overall. “Software design – not just SOA design – is always a trade-off of maintainability, performance, risk mitigation, and cost,” explains Craig. “Reuse can reduce costs and add benefit because you are reusing tested, proven services instead of writing them multiple times. When you maintain them, you maintain them once, instead of repeatedly, which also reduces ongoing cost.” “On the negative side, it can engender risk of poor performance, especially in SOA designs where multiple services can ‘find and bind’ to a production system – a risk that can be mitigated by governance of the use of services,” she says.
The next step is discovering which components make sense to reuse first. Keep in mind that it isn’t necessary to do everything at once.
“We strongly advocate an incremental approach to SOA, and in fact that has been the dominant approach to adopting SOA,” says Larry Fulton, senior analyst at Forrester Research. “Like anything else new, there are startup and training costs, but we’ve seen organizations achieve better flexibility, time-to-market and service re-use with only a handful of services, in twelve to eighteen months’ time.”
Obviously, even a baby step must be taken in one direction or another. So, which foot goes where?
The basic line-up of components for reuse, according to Sandra Rogers, director of SOA, Web Services, and Integration Research at IDC, is “infrastructure and technology services, information or data services, and then common-place functional routines.”
Rogers says many organizations start with infrastructure or technology services, such as security, monitoring, and auditing to immediately help free up business application programmers to address more added value activities. This can also help ensure consistency to enterprise protocols and create an environment that is much more efficient in addressing changes to these routines. “As a side value, it helps reinforce more reuse of services in general by supporting a more secure and governed environment,” she says.
“Other key areas of reuse are those that provide common information views. For example, ‘get customer contact information’ could be a very common routine used in many places-whether billing, sales, customer support, order processing, and more,” she explains.
This move once again reinforces that all routine actions consistently get the same clean and approved information. Creating a foundation of data services can thus be a huge benefit. “Those enterprises looking to leverage what are being referred to as ‘mashups’ will also reap benefits of having specific views formalized into services,” explains Rogers.
Other tasks such as an order process or credit check routine is another common place to gain efficiencies, especially when there are third-parties involved. “It also once again frees up individual divisions from the need to maintain systems that perform such standard processes,” she said.
In a nutshell, reuse requires that all the shared elements and services be discoverable, accessible, trustworthy, and able to scale to demand. “Such issues, combined with overall organizational dynamics related to support and funding, need to be addressed if organizations expect reuse and shared services to be adopted throughout the enterprise,” warns Rogers.
There are more subtle forces at work than just implementing technology, however. “Timing-wise, look to SOA when you have specific problems that SOA can solve. Look at it as an organizational investment, not just an IT investment or a science project,” advises Craig. She suggests you watch your back in the process as an SOA move, like any IT initiative, has to be viewed with a highly critical and business-savvy eye. Craig recommends the following specific steps:
Before you start, make sure you have skilled resources in-house who understand SOA and its benefits. Executive buy-in is equally important as technical capabilities, because SOA’s benefits start small and grow over time. Executives have to view that time as an investment in the future, not as a failure to deliver.
Make governance a part of the project from day one, because “SOA has a ‘wild fire’ effect – once it catches fire, it tends to spread very quickly within a company,” she says.
One last piece of advice: Craig says don’t try to pull off a “big bang” initiative. “Start small, with a non-mission-critical project and tackle bigger projects over time,” she says. But be aware that you must keep on the move.
“Static relationships are just not an option when you need to be agile and to move at Internet/Cloud/Hype-Word-Du-Jour speed,” Strong says with a grin.
