7 deadly sins of SOA |
 |
By Brein Nally, Assistant Editor and Rich Seeley, News Writer
12 Jun 2008 | SearchSOA.com |
|
|
Orlando, Fla. – Service-oriented architecture (SOA) is now a mainstream practice, but implementation can be derailed by seven common mistakes, according to analysts at the Gartner Application Architecture, Development & Integration Summit, held here this week.
|
|
|
|
|
SOA is crossing from competitive to mainstream. It will soon be hard to find any services from vendors without SOA.
Yefim Natis
Analyst, Gartner Inc.
|
|
|
|
|
|
|
|
|
|
"If you have not heard of SOA, you must have been living under a rock," Yefim Natis, Gartner Inc. analyst, told attendees who packed the Orlando World Center Marriott Resort & Convention Center to learn more about the architecture, which Gartner sees becoming ubiquitous. SOA is no longer an edgy concept experimented with by a few daring architects, it is now the way business software applications are developed and delivered, the analyst said.
"SOA is crossing from competitive to mainstream," Natis said. "It will soon be hard to find any services from vendors without SOA."
That was the good news. The bad news is that mistakes can endanger enterprise SOA implementations.
In his talk on "Patterns and guidelines for starting with SOA and moving to advanced SOA," Natis listed seven dangerous mistakes that he urged his listeners to avoid.
1. Danger of leaving it to the techies
SOA is about business as much as it is about traditional application development, so it is a mistake to leave implementation to coders who have little or no understanding of the business goals. As analysts have been saying for years now, it is important to get business people involved in SOA project from the start. One encouraging sign was that this week's Gartner conference appeared to be drawing more business people than past events.
2. Danger of irrational SOA exuberance
Implementations can get bogged down if project leaders, in their enthusiasm, try to do too much too quickly and end up getting overwhelmed. This leads to the danger of starting too big—taking on too many SOA projects with too many services. "Don't rush to SOA," Natis cautioned. "If you have 20-30 services, you are doing well. If you have 200-500, you know there is a problem." He urged his audience to "advance gradually" along the SOA maturity curve. And he warned: "It is possible to get yourself into trouble at all [maturity] levels."
3. Danger of wrong-sizing SOA efforts
To get the scope and focus of SOA right it is important to remember that the A in SOA stands for architecture. This is where architects and project managers play a key role. While vendors urge investing in software infrastructure, Gartner advises investing in management and design to make sure the SOA project fits the business needs. Good management is important. "As SOA becomes more advanced," Natis said, "the degree of management becomes quite significant."
4. Danger of forgetting data
All business applications from routine patient records lookups in hospitals to multimillion dollar millisecond transactions on Wall Street are about getting data and processing data. SOA requires a carefully thought out data model. Because applications commonly require data from business partners outside the four walls of the enterprise, Natis said it is important to plan "to access data other than your own."
5. Danger of the 'not invented here' syndrome
Because SOA is about reuse, it is important to move beyond the old concept that new applications require new code. That view defeats the purpose of services reuse. "The success of SOA is in use of already existing services….discourage people from re-inventing the wheel," Natis warned.
6. Danger of starting in the wrong place
SOA needs to start from the beginning with the services and applications that business needs. There is little value in developing cool services that no one on the business side wants to use. "Only implement a service to which there is a client," Natis said.
7. Danger of choosing anarchy or dictatorship
SOA is not an isolated project, like the skunk works development efforts popular in the 1990s. Nor can SOA be imposed on either IT or business as a directive from on high. SOA needs to be a cooperative venture with buy-in and participation from all the people who will be working on or with the business applications.
"SOA is not a technical issue, it is a people issue," said Darryl Plummer, Gartner managing vice president, in separate session. But it is important that it be a cooperative effort between IT and business people. "Business people should be in the SOA process," Plummer said. "Not take over the process, but involved in it."
Natis also warned against taking a one-size-fits-all approach. "One solution doesn't work well for all business aspects," he said.
Natis urged attendees at the conference to "treat SOA as a strategic initiative," but not treat is as if any one approach will work for every business application. "SOA does not mean homogeneity—that would be inflated expectations."
|
