April 8th, 2008
Quality assurance for SOA requires a different mindset
Forget QA as you knew it — as it seems to do with everything else, SOA upsets the apple cart.
Quality assurance assures more trust in SOA — and SOAs need trust
SOA has a lot of moving parts, so more traditional QA processes — in which software is developed, tested, and handed off to a QA team for more testing in a very serialized manner — will not work. “Given the distributed and complex nature of SOA, it is virtually impossible to ’stage’ an SOA environment,” says Wayne Ariola, VP of Parasoft.
In a new article, Wayne compares the QA process for SOA to that of embedded systems. He points out QA in the SOA world requires what he calls a “process cadence” that “initiates the quality process as soon as services are defined,” based on a collaborative and building-block approach.
Wayne makes the following recommendations:
- Promote visibility. SOA is all about trust. The enterprise needs to be confident that all parts of the SOA are in working order. “Visibility will ultimately promote trust,” Wayne says. “Trust will ultimately promote reuse of these business assets.”
- Supply an automated infrastructure for reuse of testing assets. Just as SOA is about providing reusable services to the rest of the enterprise, testing artifacts should also be “reusable.” As Wayne explains, “You do not want people redoing, recreating and rerunning the same tests over and over again. You want to make sure that test assets are created, shared, leveraged and extended properly among team members in order to achieve maximum efficiency.” An automated infrastructure for storing testing assets — such as a repository — can help accomplish this goal.
- Promote bottom-up quality. QA needs to extend beyond the service and messaging layer to the underlying applications. Wayne urges the efficient application of coding standards, static analysis and unit testing to underlying assets — and make this transparent to the rest of the enterprise as well.
- Leverage top-down quality as well. Wayne advises plenty of attention to the messaging layer as well — including activities such as verifying WSDLs and BPEL files, as well as building security best practices into the software development lifecycle.
- Emulate as much as possible. Complex SOAs stretch to endpoints across the spectrum, including service customers inside and outside the enterprise, which cannot be tested directly. Such an extensive environment needs to be emulated.
- Improve, improve, improve. As with all QA processes, continuous improvement is the name of the game. Keep on measuring and tracking, Wayne advises.
April 6th, 2008
Something strange in your SOA… who you gonna call?
In the US presidential campaign, Hillary Clinton’s ads have been asking who is the most qualified to be picking up that 3am emergency call.
Why is a service malfunctioning? Who knows?
When it comes to SOA, who should be picking up those 3am SOA problem calls?
Forrester’s Randy Heffner says many organizations are uncertain who should best be handling these calls. Often, one team or another may be charged with handling any malfunctioning services, but end up dragging in everyone else in for perplexing problems. I recently had the opportunity to host an ebizQ online session on this challenge, with Randy and AmberPoint’s Ed Horst.
SOA has a lot of moving parts, and digging down to spot the root cause of a service problem is not always easy. SOAs are multilayered creatures. Is it the service itself that’s creating an issue? Is it the database? Is it one of the servers? Who knows?
In his talk, Randy advised that unless teams want a lot of late-night calls, SOA management tools need to address what he calls “deep service” management.
Randy pointed out that SOA management tools all do a fairly good job of altering administrators to problems with a service. Even in a complex service implementation — it could be Java, .NET, messaging middleware, or legacy connectors — when trouble is afoot, a good management tool will do a good job of sending an alert out.
Now, Heffner says, “great, we’ve identified there’s a problem with a service, who we going to call?”
With complex SOA implementation, and multiple teams, the only answer that will be coming from everyone within their respective teams saying, “it’s not me — my stuff is working fine.” That’s because everyone has a view limited to their piece of the infrastructure, Randy says.
Randy urges configuring SOA management strategies and solutions to conduct “deep service management.” Typically, SOA management solutions employ solutions that don’t look beyond the SOAP interface. A new generation of tools that are emerging, however, that can look beyond the service interface to the databases, services, and messaging layers beneath.
“Your SOA management solution, however you construct it and buy it, must handle SOA-based service requests that have complex service implementations,” Randy said. This could involve services that invoke Java Message Service, MSMQ, Java RMKI, or CORBA, he elaborated. Or, there may be an ESB or app server behind the service.
Many deep service SOA management approaches can start with agents that many SOA management solutions provides, Heffner said. Then, there are also an increasing number of management solutions that run natively on various platforms.
They key is to employ these solutions — with or without agents — to gain better visibility into the systems behind the services, he said. “SOA management solutions may have various ways to construct or correlate a picture, such as dropping tags into a message… or, you might have to do a little work in the configuration…”
The benefit is that as problems with services arise, problems will be better isolated, and administrators will know which team to call for assistance, such as the database team. The alternative is all-night sessions rooting out problems with all the various teams behind the service. And, ultimately, such deep service management delivers benefits beyond root cause analysis, such as capacity management — another issue that arises as SOAs gain steam.
April 4th, 2008
The sometimes stormy politics of service-enabling
I’ve been meaning to link to Dana Gardner’s latest piece on SOA cultural issues for some time now, so here it is. SOA is messy for now — but that’s okayAs his title so aptly puts it: “We know that SOA depends on culture shifts, but — like the weather — we still don’t do much about it.”
Dana observes that SOA has failed as an energizing force because it’s effects are unclear or unexplained:
“SOA’s great promise is to help align people, process, and processing. But something remains in the way. SOA lacks a political context. It lacks power over the people, and so far the power of the people has not been much interested in embracing SOA and its effects. Why should they? We haven’t told them what the real-life effects of SOA are.”
Because it touches so many processes and parts of the business, SOA is inherently a complex undertaking. Dana points out that organizational politics gets in the way every time, however.
Another point I want to add is that SOA has been mainly an IT-driven activity. To a large extent, we’re looking to IT managers to sell transformation to the business, and often, it’s something beyond the scope of many IT managers’ responsibilities or organizational capabilities. And, actually, IT managers shouldn’t be selling “SOA” to their businesses, they should be selling improved or streamlined processes.
Add to that the constant vendor chatter of how their customers will somehow automatically be “upgraded”to SOA within new releases, as if that in and of itself will somehow override the fuss and muss of organizational politics. Again, vendors seem to be leaning on IT managers to go out and work miracles across their enterprises.
SOA will and is being accomplished in fits and starts, here and there, in islands that eventually will form into interconnected archipelagos. But for now, it’s messy — but that’s okay.
As Dana reminds us, “the politics of change in large, complex organizations remains a mystical, quizzical patchwork of leaps, lunges and stumbles… Let’s not necessarily blame SOA or IT, any more than we should blame the rain….”
April 3rd, 2008
World’s biggest compute job… to be done by pen and paper
The US Census Bureau, which is charged with counting and analyzing the nation’s 300 million residents in 2010, has just admitted that its technology is not ready for the job. And what was originally touted to be the first “high-tech count in the nation’s history” will still be a highly manual process.
According to this report today at CNBC, US Commerce Secretary Carlos Gutierrez purportedly told Congress that the bureau “will scrap plans to use handheld computers to collect information from the millions of Americans who don’t return census forms mailed out by the government.” The report also notes that the change cost an additional $3 billion, for a total estimated cost for the count exceeding $14 billion.
That’s because the bureau will be hiring and training 600,000 temporary workers to go from door to door to collect the data. And then there was the $600 million to purchase the handheld computer systems. As the CNBC report mentions: “Census officials are being blamed for doing a poor job of spelling out technical requirements to the contractor… The computers proved too complex for some temporary workers who tried to use them in a test last year in North Carolina.”
Ironically, the US Census Bureau was the first large-scale user of automation, which began with the use of punch-card sorters for the 1890 census. It took about eight years to tabulate the 1880 census, a time that was cut to two and a half years for 1890. The total population of 62,622,250 was announced after only six weeks of processing.
UPDATE: Blogging colleague Michael Krigsman, who knows a colossal failure in the making when he sees one, weighed in on the Census snafu.
April 2nd, 2008
Leapin’ Linthicum!
Anyone who has seen Dave Linthicum in action at IT conferences knows this guy is one ball of fire. He entertains, cajoles, incites, and educates on the perils and possibilities of SOA and integration.
Dave is also my SOA blogging counterpart over at InfoWorld, and a seasoned CTO and CEO of technology startups.
Now Dave, who had merged his consulting firm with ZapThink only a few months back, has taken another leap of leadership in the SOA space, as CEO of StrikeIron.
I’ve talked about the StrikeIron value proposition quite a bit in this blogsite for the past few years. I also wrote about the company a couple of years back (in an analysis for Webservices.org) as an embodiment of the entrepreneurial vision of SOA, versus the more bureaucratic discussion that seems to surround SOA these days: governance, control, top-down, centralized management, etc.
StrikeIron’s message has been that SOA, Web services and Web 2.0 make it realistic for companies of all sizes to rent and sell services and leverage data in a global, enterprise-to-enterprise context. StrikeIron represents the realization of the Global SOA.
That’s why Dave now gets to occupy one of the more interesting perches in the industry — at the convergence of the currents of SOA, Web 2.0, and the mashup economy.
My colleague Dana Gardner also ponders Dave’s latest leap, noting Dave will still serve in an advisory capacity to ZapThink.
Congratulations, Dave!
March 27th, 2008
Sluggish economy may spur more, but smaller, SOA projects
Will 2008 be a year of retrenchment of our expectations of SOA, or will things really take off?
There’s a debate as to whether a slow economy would help or hurt SOA. It’s worth noting that the case for SOA, in tandem with Web services, was forged during the worst IT spending slump in a generation — the 2000-2002 time period. Companies and IT professionals were attracted to the SOA/Web services concepts because they offered the attractive advantage of building or exposing existing applications at minimal cost and disruption. As the economy went into growth mode, SOA was increasingly pitched as a growth agent. If things slow down again, we may see SOA return to its roots — the cost-savings/economies-of-scale mode of thinking.
Tony Baer, for one, says SOA expectations may be entering a bear market. He posits that economic sluggishness may temporarily turn off more grandiose visions of enterprise SOA and foster more of the incremental, low-expectation route:
“Recessions tend to discourage the kind of long-term thinking that grand enterprise architectural exercises are supposed to support. In that sense, SOA has been caught up in the middle – roughly six years after the current incarnation of the concept emerged with Web services, there remains considerable debate as to whether it makes sense to take a project or architectural approach.”
Not that adoption of SOA itself will diminish anytime soon. In fact, a new survey out of Forrester Research (reported by Rich Seeley) finds more companies than ever are on the SOA bandwagon. As the study finds:
In 2005, the survey found 53 percent of enterprises were “using or planning to use SOA.” By 2006, that number had grown to 62 percent, and in 2007 it reached 66 percent. More importantly for the theme of the latest survey, enterprises with an “enterprise level strategy and commitment to SOA” went from 18 percent in 2005, to 22 percent in 2006, and 26 percent in 2007.
What will happen in 2008 if companies feel a need to scale back spending? As Tony suggests, a sluggish economy may cause companies to be less willing to pony up funds for big-time SOA projects. In such an environment, the best route to SOA may be through lower-visibility service-oriented islands spawned through grassroots movements.
Actually, this realization has been building for some time. Even in the best of times, organizations need to see the ROI (or a reasonable facsimile thereof), and this is much easier to find on a project-by-project basis. ‘Business agility’ is a ghost of a goal that is almost impossible to benchmark and measure, but ‘x hours of development time saved’ is self-evident.
Tony reports on a conversation on this topic he just had with Progress Actional’s Dan Foody, often a good source of wisdom of all things SOA. Dan said it’s time to dispell “the notion that SOA had to be done exactly right, the first time…. The trap we got caught in was that you have to be perfect from day one,” he says.
In his own recent post, Dan recommends avoiding the terms ‘agility’ and ‘reuse’ when discussing SOA. Instead, focus on SOA’s cost-savings abilities. “Consistency, avoiding duplication, and consolidation are all instrumental to managing costs. And SOA gives you these,” he said.
Randy Heffner, the author of the Forrester study, feels that if IT budgets were to tighten, this may actually spur SOA development, for the same reasons:
“There are conditions under budget stress that actually encourage the use of SOA,” he said. “For example, one benefit of SOA is that it extends the life of legacy applications. Say we were going to rewrite this application and spend $X millions, but we figured out we didn’t have to because with a fourth of the money we could get where we needed to by SOA-enabling a legacy application.”
Dan sees more movement toward an iterative approach as a result of a spending pinch, “which is to model only as much as you need to build services now while still providing freedom to act when circumstances change.” Again, spot on. And isn’t that what SOA is all about anyway?
March 26th, 2008
The best way to sell SOA? Try Web 2.0 techniques
There’s no question that SOA has been a tough sell in many organizations. Conversely, the response to Web 2.0 has been almost a cult-like following — many end users can’t get enough of these online tools.
SOA, Web 2.0’s boring cousin
How can SOA proponents glom onto some of this enthusiasm? Some experts say that the lightweight, user-friendly techniques seen in the Web 2.0 experience can serve as SOA’s best selling tool. Some even say that eventually, the two worlds may even blend to the point where they are indistinguishable.
These points were raised in a very compelling online panel discussion on the growing convergence between SOA and Web 2.0, hosted by Beth Gold-Bernstein, my colleague over at ebizQ. Beth was joined by luminaries including ZDNet’s own Dion Hinchcliffe, ZapThink’s Ron Schmelzer, and Doug Wilson, CTO of portals and collaboration products at IBM.
Doug Wilson pointed out that “it’s not always obvious for people to see the connection” between SOA and Web 2.0. However, at the end of the day, Web 2.0 addresses the same problems SOA is addressing:
Aspects of Web 2.0, such as mashups, “are the juxtaposition or combination of information from multiple back end services. In fact, mashups are a compositional mechanism by which an end user or programmer can bring multiple sources of information or transactions to bear on one problem. This goes right to the heart of SOA and SOA composition.”
Doug stated that enabling users to easily compose services that make calls to back-end systems will go a long way to helping businesses see the value in SOA.
For some, SOA may meld into Web 2.0, and the result will be a global SOA, with various islands comprised of enterprise SOAs. Dion Hinchcliffe put it this way: “Look at the Web as it is today — it has now become the world’s largest service oriented architecture. Over 600 companies have opened their business up as Web services.”
However, currently, the tools and protocols being used for Web 2.0 engagements are “not what we’re using in the enterprise,” Dion observed. “We’re seeing this rise to Web oriented architecture that’s happening outside our organization — they’re using REST instead of SOAP.”
Will Web 2.0-style approaches eventually permeate through enterprise walls? It’s inevitable, Dion continued. Web 2.0 is “leading to a realignment in the way we look at SOA. When I talk to many SOA architects, they’re trying to figure out where this fits in. We are seeing some differences and some changes to the way we might want to do things on the infrastructure side.”
However, Ron Schmelzer pointed out that Web services and SOA are two very different things, meant to serve different purposes:
“The concept of SOA actually predates Web services by at least five or six years. The main proponents of service oriented architecture at that time created architecture around CORBA. The use of Web services technology is only appropriate for certain circumstances; it’s not appropriate for all uses of service oriented architecture. For example, I wouldn’t want a mobile device sitting on a network consuming heavy Web service and protocols.”
Web 2.0 and SOA also have different philosophies, Ron added. “SOA is about empowering the enterprise, and Web 2.0 is about empowering the individual,” he said. “The ideas of Web 20 and SOA are definitively different. They espouse different ideas. SOA is primarily architectural, which means it’s an approach a methodology a style and a design. Web 2.0 is a broad-based movement that covers a variety of topics.”
In combination, however, Web 2.0 and SOA are a power to be reckoned with. “We want the user to become increasingly more familiar with in the broad Internet, and bring that experience into the enterprise,” Ron said. “At the same time, allowing the enterprise to free up its assets, and empower the business user.”
The complete panel Webcast can be found here.
March 24th, 2008
In a down economy, expect subprime SOAs to suffer
If the economy languishes as media pundits say it will, we may see a story of two SOAs. Those that are making a difference to the business and will continue to do so, and those that I’ll classify as ’subprime SOAs’ that will quickly have their oxygen cut off if their organizations feel a financial pinch.
There’s been plenty of speculation in recent months as to whether the IT sector can hold up through any economic downturn. The consensus I’ve been hearing is that this is not 2001, with the dot-com bust leaving tech companies with huge overhangs of inventory, and companies tapped out from years of Y2K-related spending. Companies came out of that period with lean and mean IT spending, which remains to this day — and thus there will not likely be huge cutbacks in this sector. (In fact, recent research from the National Association of Computer Consultant Businesses (NACCB), finds no evidence of slowdown in IT staffing, which is at “an all-time high.”)
But there are plenty of opposing views on how SOA projects would fare through a general downturn. I recently spoke with ZapThink’s Ron Schmelzer, who has been sounding the alarm for some time — not about a downturn, but about a shortage of skills available to build and manage SOAs.
Would SOA prevail during a lousy economy? Ron expects a mixed picture to develop: those companies that aren’t doing too well with SOA will likely not see the value in these efforts and cut back, while those that are well supported and well-tuned to the business are likely to see continued growth, no matter what economic storms rage outside.
And, as Ron puts it, the support and success an SOA will receive will depend a lot on “where a company stands on the crossing-the-chasm curve. If they’re late maturity and laggards, and they’re cutting back, then they’re not going to pioneer in architecture.” In other words, forget SOA, just keep firefighting and doing maintenance-type things. (Ironically, as I’ve said before on this blogsite, these are the companies that need SOA the most.)
More forward-thinking companies will see any slow period as an opportunity for SOA, Ron says:
“If they’re smart companies that are ahead of the curve, early innovators, then they ‘ll see a downturn as a good opportunity to move forward with SOA. While other people are going to cut back, we can drive ourselves further ahead without having to spend more. I think those organizations are going to accelerate their SOA efforts.”
Down economy or not, it’s a great time to invest in architecture, Ron says, “because investing in architecture means economies of scale, reduction in redundancy, increase in reuse, increase in visibility. We’re not talking about buying a $10-million CRM package, we’re talking about making an investment in yourself; this is the best time to do it.”
Ron and ZapThink colleagues Jason Bloomberg and Dave Linthicum will be talking about these and other issues at a series of industry-focused workshops over the coming month, in Newark, London, and Las Vegas.
March 22nd, 2008
War declared against JBOWS architecture… but is it something we can live with?
In a new post, Nick Malik declares all-out war… against JaBOWS, or Just a Bunch of Web Services, architectures. ‘What I hate is the notion that SOA can be reduced to tools’He urges IT executives and professionals to get active as a community in the effort to stamp out JaBOWS before it chokes the very SOA efforts that were supposed to simply and streamline IT architectures.
Nick says he’s grown sick and tired of the all the talk and promises of SOA, yet nothing happening but more spaghetti:
“As a community, we have sat silently by as the pundits have sold products that fail to deliver on the promise of SOA. We have watched, many of us in horror, as the goal of changing behavior, and changing infrastructure, has fallen victim to ‘yet another tool’ to solve the same problem.”
As Nick put it: “What I hate is the notion that SOA can be reduced to tools; that you can introduce a tool and suddenly all the bad (human) behavior stops. I want to dispel that notion right now.” The way he explains it, the road to JBOWS is paved with good intentions. (By the way, Nick’s JaBOWS and my JBOWS acronyms are interchangeable.)
As Nick puts it, it happens like this across organizations:
- If you take a group of well-meaning and intelligent engineers…
- Give them a process that looks like a normal software development process, train them on it, and they believe that this process works…
- And add SOA…
- You get JaBOWS (Just a Bunch of Web Services).
The good news is JaBOWS is not a terminal condition, Nick says. The key is to move toward “a comprehensive Enterprise SOA transformational program” that emphasizes reusability. No enterprise architect, developer, or IT executive can do this on his or her own, however. Nick urges SOA proponents to better share knowledge and approaches, and work harder to raise awareness within their own establishments. “As a community, we have to do a better job of defining what it means to build an Enterprise SOA,” he says.
The first step in this awareness campaign is to acknowledge that the slow and tortured adoption for SOA thus far has nothing to do with tools, as vendors may want you to believe. “It is a process and people problem,” Nick states. Attempts to leverage tools to address existing processes is what is creating JaBOWS.
As Nick explains:
Enterprise SOA goes way beyond ‘making two apps talk using a Web service interface.’ It is a systematic approach to developing an Enterprise-wide Service Oriented Architecture that actually allows information, process, and functionality to be composed in new ways, ones that were not foreseen by the authors of the services. Until you have this, Web Services are just ‘interoperable COM.’ Without Enterprise SOA, you have JaBOWS.”
Nick also relates that Microsoft has been battling the JaBOWS syndrome in its own internal SOA efforts: “In Microsoft IT, we are using something we call ‘Solution Domain Architecture’ or ‘SDA’ to build an approach to services that, we hope, will result in the creation of an Enterprise SOA. SOA is the benefit, SDA is the way to get there. And the reason to use SDA: to avoid JaBOWS.”
CIO’s Scott Wilson picked up on Nick’s clarion call to crush JaBOWS, and posits that Nick may be seeking perfection in a quite imperfect world. While Scott agrees that many SOA projects fall down the slippery slope toward JBOWS, he says there may be many ways to address a problem, and tools are just as legitimate a means as anything else.
In some situations, the right tools will actually help the move to Enterprise SOA, though it not be not be textbook SOA, he says. In fact, SOAs don’t have to be 100% pure and elegant:
“I feel about SOA as I do about ITIL [IT Infrastructure Library]: it’s a concept that needs some flexibility to be useful in every instance. Imposing restrictive stamps on what it is and is not makes a lot of sense within a given organization, but I’m not sure it’s a good idea for the concept as a whole.”
In other words, Scott is saying, if something works for the business, even though its ugly or messy, why fight it? “Making compromises in architecture isn’t always wise, but it doesn’t always debase us, either; there are times when compromises are the best thing for the business.” He adds that this is “a choice that CIOs face all the time.”
True, no two SOAs will ever look alike, and many will be ugly conglomerations of clunky services, hopelessly non-interoperable systems, and unsupportive business units. But, in the long run, Enterprise SOA holds tremendous value as an agent of transformation. The challenge now is that too many businesses with low-functioning JBOWS architectures think they have SOA, and are wondering, ‘where’s the value?’ And, as a result, dismissing SOA before things even have a chance to get off the ground.
March 17th, 2008
Keeping SOA, the silo killer, from creating new silos
Wasn’t SOA supposed to bring us all together? What about all these SOA “islands” that are now sprouting up across our enterprises?
There’s no such thing as one single enterprise SOA
I just had the opportunity to co-present a Webinar with IBM’s Leif Davidson on this very question. The Webinar is based on the results of a survey of 244 companies, conducted by ebizQ in January.
The survey finds that there’s no question that enterprises are firmly committed to service oriented architecture as a strategy going forward - and they’re willing to put budget dollars into the endeavor. Fifty-three percent indicated they were increasing SOA spending over 2007 amounts.
But the survey also shows that there’s no such thing as a single, all-encompassing SOA effort that covers every service initiative from every corner of the enterprise. Rather, most SOA or enterprise service efforts are “islands” of integration that arise within individual business units, designed to address specific problems.
The challenge is that these separate SOA efforts have different formats and technology foundations under development or implemented within their walls. Many use application servers to support enterprise services, others leverage composite applications on middleware, and others rely on enterprise service buses. In fact, the survey showed that a large swath of enterprises — a third — are taking multiple approaches under the same roof to building and supporting SOA, including the above-mentioned approaches.
The survey also found that most of these service deployments aren’t yet interfacing with mission-critical systems. But this is changing rapidly, as the number of services designed for reuse proliferate. The survey finds steady, unrelenting growth in organizations maintaining large volumes of SOA-based services - the number with more than 100 services in production is expected to almost double, from nine percent to 16% over the coming year.
The bottom line is that there is no single approach to SOA. SOA requires a mix of solutions but the eventual result should be a more reliable, simple and flexible infrastructure and business.
There are two interconnected levels to addressing the problem. First, on a technology level, is federation. One out of four companies have already moved to a federated infrastructure to support multiple instances of ESBs or intermediaries. Trying to manage a growing SOA through a single ESB would be unsustainable. The survey also shows that those with federated infrastructures are more likely to be able to move from siloed SOA to enterprise-scale SOA.
Then, on a business level, there’s governance. Effective governance will make the difference between ending up with a tangle of services — JBOWS — or a functioning SOA that truly supports business endeavors at any endpoint across the enterprise. The survey finds that many organizations recognize the urgency of governance, but many still leave this up to the IT department — especially among smaller companies.
The new Webinar in which Leif and I discuss the implications of the survey results can be found here at the ebizQ site. (Registration required.)
March 16th, 2008
Analyst: why even the best SOAs are ’stalling’
“It has become clear to me that SOA is not working in most organizations.” -Anne Thomas Manes
Many SOAs are ’stunningly beautiful infrastructures,’ but have yet to deliver value
When Anne talks, people listen. That’s why this line in her latest blog post stood out. Anne has been tracking the integration and SOA business for some time, so I’m sure she would not say something like this lightly. She started off pointing to a heated discussion taking place across the blogosphere based on Ron Schmelzer’s latest piece on establishing SOA as an abstraction, not an interface. Anne said she has been following the discussion intently, but concludes that, at the end of the day, “the technology discussion is irrelevant.”
The most efficient technology in the world won’t come to pass if it doesn’t have business support behind it. Anne said she is in the midst of a major research study on SOA adoption, and found even the companies that are far ahead of the pack with service-oriented architectures have not delivered anything of great value to the business yet.
In other words, if SOA practitioners were surgeons, they would be performing flawless operations, but still not fixing the patient.
As Anne put it:
“I’ve talked to many companies that have implemented stunningly beautiful SOA infrastructures that support managed communications using virtualized proxies and dynamic bindings. They’ve deployed the best technology the industry has to offer — including registries, repositories, SOA management, XML gateways, and even the occasional ESB. Many have set up knowledge bases, best practices, guidance frameworks, and governance processes. And yet these SOA initiatives invariably stall out. The techies just can’t sell SOA to the business. They have yet to demonstrate how all this infrastructure yields any business value.”
The issue, Anne points out, appears to be that SOA is still siloed within the IT organization, and the transformative effects have not yet spread to the business. Line of business managers, she observes, are not ready to share services, the crux of SOA value. Anne says so far, she has only come across one company that has been able to connect SOA success to business success, through the establishment of “strong positive and negative incentives that encourage people to adopt a better attitude toward sharing.”
Anne’s conclusions fly in the face of other studies and vendor case studies that say companies are seeing some success from their SOA efforts. However, these studies and case studies are projecting tactical successes (such as cutting development time for certain types of interfaces for specific functions), versus more strategic successes that impact the business as a whole.
One thing to keep in mind is the fact that companies shouldn’t expect SOA to be an overnight success from a business perspective. In fact, I get a little suspicious of studies or other claims of soaring SOA successes at this early stage in the game.
Is the best route to SOA not in achieving piece by piece, incremental tactical successes, that eventually build support for the effort within the business?
Enterprise SOA is a long-term transformation project. It may take years before businesses start to see these efforts bear fruit, in terms of agility — meaning the capability to change and adapt and support processes on demand, with little fuss and waiting for IT to build new interfaces or rewrite applications. The other sticking point that it is difficult to capture and measure data related to strategic business benefits. Benefits such as flexibility and agility tend to be squishy, and influenced by other initiatives taking place within the business.
The business side needs to be educated that SOA is a goal worthy of shooting for. And key performance indicators need to be tied into SOA efforts. But SOA is a journey, not a destination, and organizations that expect overnight benefits to the business are bound to be disappointed.
March 16th, 2008
Voice over SOA sounds promising — will vendors deliver?
Can SOA add automation and intelligence to the way calls and other communications are routed throughout the enterprise? This may be the next great frontier for SOA — and, at long last, a tangible benefit of architecture for the business.
Digital communications, enhanced by SOA
Last month, fellow ZDNet blogger David Greenfield posted some insightful commentary on the growing convergence between SOA and what is now called unified communications, or UC (bringing together various digitized communications channels, including PBX, voice over IP, video, email, and instant messaging). David spoke with Microsoft’s Eric Swift about the possibilities such a mashup will bring, and what Microsoft may offer in this space.
Microsoft has been treating SOA (via Oslo) and Office Communications Server (OCS) as separate initiatives, but they’ll need to be brought together somewhere along the line. (Information on Microsoft’s UC strategy here.) David said Swift “pointed to the numerous APIs that developers already have into OCS and how they can build on those interfaces to create speech-enabled applications, for example. But that’s not the same as providing a SOA interface and Swift knows it.” As David noted, developers “just can’t be expected to learn the intricacies of establishing a voice connection. Microsoft needs to offer them a high-level interface if OCS is going to extend into business process.”
David has just followed up on these observations in a new report, published in InformationWeek, in which Microsoft’s Swift confirmed that Microsoft is indeed planning to offer a desktop-based product that blends SOA and UC. In fact, Microsoft is one of a number of vendors who are increasingly melding voice communications capabilities with business processes, and doing so via SOA.
Why the sudden interest? Where and how can SOA-enabled telephony make a difference? Via SOA, business processes could be configured to automatically launch communications with relevant players across the enterprise. David cites a survey of 447 IW readers which finds that contact centers are the natural venue for such capabilities — such as “helping resolve customer complaints by automatically notifying principal parties.” Other examples include automatically initiating conference calls to address a change in a business metric, or in the event of a system failure.
David detailed how SOA-enabled communications would deliver value:
“There’s a growing trend amongst enterprise communications vendors to enable their communications servers to be controlled through a Web Service architecture. This would allow a [Microsoft’s mashup tool] PopFly-like product, for example, to mashup stock alert and a voice response system so in the event that company’s stock fell beneath a predefined threshold, an executive attending the 3GSM conference could receive an SMS on the phone and then be brought into a conference call right form his/her mobile. Alternatively, a laptop user at the same 3GSM conference could receive an IM and click on an embedded link to be brought into a conference call.”
IW’s survey also found that 13% currently have integrated communications into their business processes, and another 20% plan to do so within the next two years. So about a third have an active interest in the approach.
This emerging space and the possibilities are not lost on telecommunications vendors. For example, Avaya offers “communications-enabled business process,” or CEBP, and Cisco builds communication capabilities within its “service-oriented network architecture” (SONA) offerings. IBM is partnering with Nortel in this area.
However, vendors may have issues with the proprietary nature of their offerings. David notes that “all require IT to use their underlying telephony servers and messaging servers… Avaya goes so far as to build its own ESB to communicate with other messaging services.” Only Nortel offers interoperability with third-party hardware, he says.
The ability to provide a common interface to the same applications from across all channels — whether its via interactive voice response, Website, or via internal interfaces to call centers — has been a key goal and benefit of Web services of SOA. Linking these and other communications with business processes makes it a really compelling advantage.
March 11th, 2008
How to tap into the largest SOA in the world
Despite mega-investments in a variety of integration technologies and strategies (including SOA), businesses have seen very little return for their efforts. That’s the view of ZDNet blogging colleague Dion Hinchcliffe, not to mention plenty of other industry observers.
However, unlike the naysayers, Dion says all is not lost. While traditional SOA (based on SOAP and WSDL Web services) really haven’t proven to be agile solutions, things will be different with the new generation of SOA that is emerging.
Don’t call it SOA, however — the appropriate term is WOA, or Web-Oriented Architecture. WOA leverages the World Wide Web, which Dion describes as “the largest SOA presently in existence.” The services that are built for WOA are built from lightweight Web 2.0 standards and methodologies, especially REST and enterprise mashups. He also describes enterprise-based SOA as “local networks.”
Dion discusses the differences between SOA and WOA in more detail. He notes that “both approaches leverage HTTP, self-describing data formats such as XML, are concerned about the use of open standards, and can be used to build systems of arbitrary complexity.” However, while SOAs “tend to have a small and well-defined set of endpoints through which many types of data and data instances can pass, WOAs tend to have a very large and open-ended number of endpoints; one for each individual resource. Not an endpoint for each type of resource, but a URI-identified endpoint for each and every resource instance.”
He also observes that while “SOA was designed from the top-down by vendors to be tool friendly, WOA was emerged form the bottom up from the Web naturally, and has the best support in simple procedural code and an XML parser.” Plus, very importantly, while “traditional SOA is fairly cumbersome to consume in the browser and in mashups, WOA is extremely easy to consume just about anywhere.”
Dion has tapped into a rich convergence that is drawing the worlds of Web 2.0 and SOA closer together. Making service development and management easier for business users increases the chances of SOA success — SOA is supposed to be business-driven, after all.
March 10th, 2008
IT governance and SOA governance: little in common
People frequently put IT and SOA governance in the same bucket, and suggest that it won’t be long before the two will be one in the same. However, the two actually have little in common, according to one industry commentator.
In a new post over at the EDS site, Fred Cummins observes that while IT governance is focused on managing technology, SOA governance is about managing business services.
And that’s a big difference, he says. SOA governance is not simply better IT governance — it’s “enterprise governance.”
I often liken SOA governance to running a homeowners, condo, or coop association. Namely, everyone (meaning lines of business across the enterprise) is an owner, and everyone agrees to abide by policies that are administered by a management group, which provides common services such as maintenance and landscaping.
In a business, all business units are owners of the SOA, but management and policy enforcement are turned over to a governance committee that worries about how the services are maintained and delivered. In theory, the IT department may be but one of many “owners.”
March 9th, 2008
Best memory in the US? Let’s really put it to the test
This news item just in from Reuters:
“A 31-year-old software engineer recalled the correct order of an entire deck of playing cards in 2 minutes and 27 seconds on Saturday to take the title of having the best memory in the United States. Chester Santos of San Francisco beat two other finalists to win the USA Memory Championships in New York…”
Congratulations, Chester. But memorizing the order of playing cards is just child’s play compared to the challenge that has grown in this industry.
Here’s a real challenge: Can you identify and describe, from memory, all 78 of the major Web services standards and protocols (WS-ReliableMessaging, WS-Addressing, WS-BrokeredNotification, WS-this, WS-that) that now exist? (Here’s a cheat sheet.) And, at the same time, can you identify which are bona fide standards from standards bodies and which are vendor creations?
Now, there’s a mental athletics test that’s bound to leave even the best of the best scratching their heads in bewilderment.
March 7th, 2008
Consultant: SOA not good enough yet for government work
The government — particularly at the federal level — is seen as a leading force in the move to SOA. Government agencies are constantly under pressure to deliver more with less and are saddled with massive warehouses full of legacy systems. Thus, SOA seems like a natural route to take.
In January, we reported how one analyst firm recommends that technology contractors embed SOA into their federal government bids. The government wants lots of standardization, which SOA delivers.
However, some observers question whether SOA is ripe enough for the sensitive nature of some government work. Warren Suss, for one, questions how far SOA can go in government at this time. In a new commentary in Government Computer News, he cites a recent chat with Gen. Charles Croom, director of the Defense Information Systems Agency (DISA):
“Croom, for one, asks vendors who come knocking at his door a tough question: ‘Where are you applying SOA to your own internal processes?’ He says he’s usually met with a blank stare.”
Suss notes that Croom is very hot on the idea of applying SOA methodologies to his operations, though DISA is still in the embryonic stages of such efforts. Still, he observes, “limited industry experience in large-scale SOA deployment limits the set of mature SOA systems and processes available to the government.” (You hear that, vendors? Stop with the blank stares…)
Government SOA initiatives may also be hamstrung by security, but not for the reasons one might think.
Agencies such as DISA are purchasing Web-based commercial applications, including search engines and mapping programs, but installing them on protected government networks rather than as commercial Web services as they were designed to be. “This strategy gets users’ hands on the tools and services, but it is doubling the work and cost because the government has to set up a mirror image of industry’s computing environment, including operations and maintenance services and help desks, inside protected government computing and network enclaves.”
March 6th, 2008
Needed: Platforms that support Rich Internet Applications + SOA
We’ve been watching the Web 2.0 and SOA worlds grow increasingly closer together, and, more than anywhere else, the point where they meet is in front end applications, such as mashups and Rich Internet Applications (RIAs).
In a new article, Nolan Wright puts forth the formula for making this all happen: RIA+SOA=Convergence. However, there aren’t a lot of solutions that tie RIA and SOA together yet. As Nolan observes: “There has been a lot of buzz around rich Web 2.0 applications, but they will not become mainstream until the next generation of web platforms emerge - fully integrated platforms that enable RIA + SOA.”
Why is it important to have RIA + SOA platforms? Aren’t developers building and deploying RIAs and SOA-based services all over the place with the tools they have? Nolan says things aren’t so clear-cut:
“Currently, in the standards-based world of HTML, CSS and Javascript, RIA developers have to assemble multiple third-party libraries and frameworks in order to build a rich user interface. This ‘a la carte’ approach to building RIAs places an unnecessary burden on the developer. Instead of focusing on building applications, the developer must spend time finding, integrating, and versioning the various pieces of their RIA development platform. The same holds true on the SOA side; developers are left to figure out how to create services and how to integrate them with their RIA front-ends.”
Nolan goes on to provide examples in his article of the composition and capabilities an RIA + SOA platform should support. Nolan’s company offers such a platform, which, of course, was the catalyst for his article. But the integration of RIAs and front-end mashups with enterprise services on the back end is a phenomena that is quickly becoming a standard part of SOA.
March 4th, 2008
Is SOA still of value if nothing gets reused? How about if everything gets reused?
What if you built a service-oriented architecture and nothing got reused? Is it still of value to the business, or is it a flop?
Reuse may be the means, but not the end
Ask many experts, and the answer will be a straightforward, yes, SOA will deliver value to the business in multiple ways beyond reuse of services. (Others will say it doesn’t, but that’s a subject for many other posts.) Decreased infrastructure redundancy and increased time to market are two big areas where SOA has potential to deliver.
However, there are three sticky questions around reuse: First, should reuse be a goal in itself, or does it play more of a supporting role to more business-focused higher-level benefits? Is it like trying to measure the number of times employees open up Excel spreadsheets through the day, versus measuring the insights and actions they take as a result of the data they get out of their spreadsheets?
The second question is even more vexing: is reuse even essential at all to SOA success? Suppose there are services that are only used by one application each? These services may offer streamlined interfaces that provide independence from the application underneath, saving countless hours of toil and disruption when the app changes.
Third, suppose business units across the enterprise go wild with reuse, to the point where it gets difficult to track who is using what and how often? The SOA appears to be a raging success, but how is it helping the business? Is it amounting to anything? Is so, how can that be measured?
AMR’s Ian Finley said too much emphasis is being put on reuse as a value driver, as observed in a follow-up interview on AMR’s recent SOA study: Another danger seen from the SOA survey is that the main benefit that the vendors sell around SOA — code reuse — is not the real benefit that early SOA adopters have gotten. Often the code from project A is irrelevant to project B…. That focus on reuse can cause organizations to dismiss SOA’s benefits because they’re looking at the wrong metric.”
Dave Linthicum has been warning companies against adoption of reuse as a value metric for some time. Most recently, in response to Finley’s statement, he bluntly added:
“The core issue is that reuse, as a notion, is not core to the value of SOA…never has, never will. Not that you won’t achieve reuse, and that there is benefit, but that the value of agility, or creating an architecture that’s changeable around the needs of the business is far more valuable than any services you can share. To the point of this post, people chase SOA understanding that reuse is the core value. Thus, when it’s not they consider SOA a failure…. We need to stop selling reuse as a core benefit of SOA.”
James Taylor, who has been blogging prolifically from Dialog 08, reports that he had a chance to break bread with IBM’s Sandy Carter and ILOG’s Pierre Haren, and the subject of service reuse came up.
James notes that Pierre said that the main value of SOA today is in collaboration and understanding not in reuse. Sandy, who had some examples of customers getting a lot of reuse, “generally supported Pierre’s point, that reuse is not essential to the SOA value proposition. After all, many previous architectures promised reuse and it never seems to get delivered.”
The consensus appears to be that “reuse may well come, whether through reused services or reused rules between services, but the power of SOA to bridge the business and IT is key,” James observes. The question becomes how to measure the impact of that bridge.
February 26th, 2008
Survey: companies investing millions in SOA, but don’t exactly know why
AMR Research just released snippets of its latest survey on SOA spending trends, and finds big money is flowing — but many of the companies spending the money may not exactly know what they’re investing in.
The typical company adopting SOA spent $1.4 million on software and services in 2007, AMR estimates. AMR also said it found tnat SOA adoption is broad based and growing rapidly—China, Germany, and the United States all showed adoption growth rates of over 100%.
However, while the money for SOA will keep flowing through 2008, an interview with the survey’s author reveals that there may be little rhyme or reason to the spending. “Hundreds of millions of dollars will be invested pursuing these markets in 2008, much of it wasted,” said AMR analyst Ian Finley, quoted in InfoWorld.
Why is the money being wasted? Finley says there is not single driving focus for SOA. Instead, companies end up investing in SOA for a range of reasons, often unrelated individual priorities.
The survey found that the primary drivers for SOA investment were to meet the need to change investments faster, cheaper, and with less risk (22%), to meet requirements of individual projects (18%), and to reduce IT costs through reuse (17%).
While code reuse ranks as a reason to go with SOA, Finley doesn’t see it as the ultimate advantage of SOA. Rather, the changed mindset that SOA brings to development and management is the real value — a value hard to quantify, of course. In addition, agility — through faster time to market — is the benefit early adopters are discovering. However, improved agility is also hard to quantify.
February 25th, 2008
‘Give businesspeople a reason to care about SOA; give them BPM’
“Give businesspeople a reason to care about SOA; give them BPM [Business process management].”
That’s the advice given by Kaushal Mashruwala in an article just published in Financial Express. Kaushal makes a lot of sense, because BPM is a strategy that business executives and managers identify with very closely (as the success of their jobs depends upon it).
Will business process management make SOA more digestible?
SOA, as discussed many times at this blogsite, has issues with business acceptance — or even awareness, for that matter. As Jack van Hoof put it not too long ago: “I haven’t meet one single business manager who begged me to please deliver him an SOA-based solution.”
All too often, Kaushal points out, SOA is seen as a buzzword, and, to a large degree, “just another way to implement an application.”
However, add BPM to the mix, and infusing it with SOA, business managers will have more power to change, through technology, the way their businesses are run, he observes.
“The management philosophy of BPM empowers business people to think about the processes that affect their day-to-day lives and operations. It gives them a new role in defining requirements, on their terms, and creates a common language for business and IT to address real implementation level concerns. This role of BPM as the business face of SOA is not just a possibility. It’s happening now.”
Perhaps we won’t have to force the issue of fusing SOA and BPM, it may be occurring naturally. As posted a couple of weeks back (with a rousing talkback discussion), BPM, SOA, and Enterprise Architecture may be all the same thing underneath in the long run anyway. As Richard Lendvai commented, “It’s architecture, period.” He goes on to add that “architecture in general is about the enterprise’s capability to work in an orderly manner, be specific in designs end to deliver results to the business. It has little to do with modelling, paradigms and other hype-stuff.”
Joe McKendrick is an author and consultant with deep knowledge and insights regarding trends and developments in the technology industry. See his full profile and disclosure of his industry affiliations.
Recent Entries
- Quality assurance for SOA requires a different mindset
- Something strange in your SOA… who you gonna call?
- The sometimes stormy politics of service-enabling
- World’s biggest compute job… to be done by pen and paper
- Leapin’ Linthicum!
Most Popular Posts
- World's biggest compute job... to be done by pen and paper
- The best way to sell SOA? Try Web 2.0 techniques
- Sluggish economy may spur more, but smaller, SOA projects
- Leapin' Linthicum!
- Something strange in your SOA... who you gonna call?
- In a down economy, expect subprime SOAs to suffer
Top Rated
- World's biggest compute job... to be done by pen and paper+6 votes
- Keeping SOA, the silo killer, from creating new silos+3 votes
- Sluggish economy may spur more, but smaller, SOA projects+2 votes
- IT governance and SOA governance: little in common+2 votes
- The best way to sell SOA? Try Web 2.0 techniques+2 votes
- Something strange in your SOA... who you gonna call?+2 votes
- War declared against JBOWS architecture... but is it something we can live with?+1 vote
- Confronting the SaaS skeptics+1 vote
Premier Vendor Content Whitepapers, webcasts & resources from our Power Center Sponsors
- Virtualize and Optimize Your IT Infrastructure
-
Attend this premier online event on April 10th and learn how strategies like virtualization can reduce your costs and make your business more competitive, flexible, and efficient at every level.
- Sign-up now for the upcoming premier online trade show from PC Connection!
- Performance Results: Intel Centrino with vPro technology and Intel Core 2 Duo Processor
-
"Intel® Centrino® with vPro&8482; Technology and the new 45nm Intel® Core&8482;2 Duo processor delivers greater than 2x the performance over older generation Intel® Centrino® components when your system is multitasking.
- View, compare, and get smart>>
Archives
ZDNet Blogs
- All About Microsoft
- The Apple Core
- Between the Lines
- BriefingsDirect
- The Core Truth
- Dev Connection
- Digital Cameras
- Ed Bott's Microsoft Report
- Emerging Tech
- Enterprise Alley
- Enterprise Anti-matter
- Enterprise Web 2.0
- Googling Google
- GreenTech Pastures
- Hardware 2.0
- Irregular Enterprise
- IT Facts
- IT Project Failures
- John Carroll
- Laptops & Desktops
- Lawgarithms
- Linux and Open Source
- Managing L'unix
- The Mobile Gadgeteer
- On Sustainability
- Rational Rants
- The Semantic Web
- Service Oriented
- The Social Web
- Software as Services
- SOHO Networking
- Storage Bits
- Team Think
- Tom Foremski: IMHO
- The ToyBox
- The Universal Desktop
- Virtually Speaking
- ZDNet Education
- ZDNet Government
- ZDNet Healthcare
- Zero Day
Popular white papers
- Successful IT Outsourcing to Russia SolovatSoft
- Watts and Volt-Amps: Powerful Confusion American Power Conversion (APC)
- How to Choose an Offshore Outsourcing Development Partner SolovatSoft
- Cool Features for SQL Server 2008 Quest Software
- The Great Debate: Buy Versus Build -- Oracle's Pre-built Analytic Applications Versus Building a Custom Warehouse Oracle
- Rapid E-Learning: Maturing Technology Brings Balance and Possibilities Adobe Systems
