SOA in Action

What's Web 2.0 have that SOA doesn't?

Judith Hurwitz recently weighed in on the Web 2.0 phenomenon, observing that it has some of the echoes of the recent dot-com era: "...there were problems. First, most of the companies entering the market had no business model at all. The entrepreneurs in the space all looked to a handful of companies that had first mover advantage and were able to become leaders. ...Fast forward to Web 2.0. Entrepreneurs in this market look at some of the early successes like YouTube, My Space, and Facebook and see dollar signs. However, most of the companies yearning for billions actually have no commercial business model."

Nevertheless, Hurwitz continues, "Web 2.0 completes one of the key components of a service-oriented architecture – the interactive presentation and collaboration services. In fact, this will be one of the foundational ways that customers will create collaborative composite applications."

Web 2.0 carries with it a number of qualities that can speed along SOA projects: the ability to have Web pages continuously refresh, leveraging the XML-based Ajax development platform to support iterative client development, the ability to create Web applications without server interactions or dependencies, and the ability to link components together into mashups, or client-driven composite applications.

Hurwitz predicts that Web 2.0 will evolve out of the adolescent and 20-something "cool" space to ultimately shake up the more stodgy enterprise environment. "One of the impacts of Web 2.0 is that it begins to turn the balance of power upside down," she writes. "It enables emerging companies without a vast infrastructure to begin to create compelling software that can appear on the Web. This will be aided by the emerging business model of Web 2.0 – short development cycles where the community provides feedback to the developers."

Let me add that there is another case of deja vu all over again is happening here as well. Before SOA was SOA, it was XML Web services -- created in response to the demands of the dot-com, e-commerce driven culture that emerged in the late 1990s. (And really never went away.) The original intent of XML Web services was to smooth the interactions between e-commerce sites. XML was the lingua franca that would bring industries together, while services such as UDDI registries would act as the "Yellow Pages" of global e-commerce. The entrepreneurial frenzy that is taking place around Web 2.0 will soon be coming to an enterprise near you.

ebizQ is hosting a Webcast, led by Gartner's David Mitchell Smith and moderated by ebizQ's Beth Gold-Bernstein, on the convergence of Web 2.0 and SOA. Details on the Webcast, to be presented October 31st at 12:00 p.m. US Eastern Time, are posted here.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

In the SOA world, are 'services' interchangeable with 'applications'? In a new post, Dave Linthicum cautions that there is often confusion about what constitutes a 'service' versus a full-fledged SOA-enabled 'application.'

"Services are not applications. They are small parts of an application," Dave advises. He also cautions that services are not to be construed as "subsystems," but rather, as small parts of subsystems.

Thus, designing a 'service' calls for a different approach than application design. Dave says in the SOA projects he's seen, there has not been enough attention paid to "service design." He notes this is becoming essential as we increasingly move to the use of services to assemble and integrate software. SOA-based service design is a whole differnent animal.

There are five key considerations that go into SOA service design:

1) Define the purpose of the service. "What will the service do, and who is the intended user?"

2) Determine the information to be bound to the service, including both metadata and schemas. "This means you need to understand how information is leveraged by the service, and what functions require what data," Dave says.

3) Determine the functions (methods) encapsulated inside the service. This may consist of behaviors you would like to expose, such as "check inventory." Dave advises use of a traditional functional decomposition chart at this stage of the design process.

4) Define any interfaces into the service; both machine and human. "This means we need to determine how the service will interact with the calling applications, and through what mechanisms," Dave says. Rich client interfaces that invoke human interaction should also be considered.

5) Define how the service is to be tested. Testing is often "a very important but often neglected step," Dave points out.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

"IT architects in the SOA world still have no idea what BPM is, and they still don’t know what they don’t know. Process owners on the business side don’t really know what SOA is, although they’ve heard it’s good. They just want to improve business performance, however it gets done." - Bruce Silver

There's been a lot of talk in recent months about the impending conversion -- or lack thereof, depending on one's point of view -- between business process management and SOA.

In a new interview, Rob Levy, executive vice president and CTO of BEA Systems, said the convergence between SOA and business process management (BPM) is inevitable. He put it this way in an interview with Rich Seeley of SearchWebServices: "I believe in the next generation of SOA applications two things are going to control everything: BPM and metadata. You know what the metadata means and you have ways to control your business process management. You now have the way to make business applications happen."

Levy added: "If you think about it, in the future an application would not be an application the way we see it today. It will be the usage of business process and policy rules against the container of available services."

Bruce Silver, who has been watching and commenting on the BPM space for some time now, published an analysis of BEA's SOA-BPM strategy last month. He quotes BEA's Alfred Chuang, who observed that while "BPM can be effectively deployed without SOA, there is a strong synergistic benefit in combining BPM’s set of coordinated activities with the architectural benefits of SOA." SOA provides an enterprise reach to any BPM effort, he adds: "As more departments come online, more managers have a hand in controlling the IT environment. And as the system’s growth necessitates more changes, the BPM solution will soon be suffering the coordination, integration, and management problems SOA was invented to solve."

Posted by joemckendrick in SOA  |  Permalink  | Comments (1)  | TrackBacks (0)

An SOA effort can bring about a "virtuous circle" of service development and reuse that can lead to impressive ROI. I recently had the opportunity to speak with David O'Connell, senior analyst at Nucleus Research. O'Connell had just authored a qualitative study on SOA and the use of registries, and had some interesting observations about this essential stage of SOA development.

Namely, that without a registry, an enterprise is unlikely to see ROI from its SOA project. But, registries are not common in the formative stages of SOA. "People generally adopt SOA in an incremental way. They typically first do it with a proof of concept project. At this point, a registry's not all that important."

However, as the SOA gains critical mass in the enterprise, a registry becomes vital, O'Connell added. "If you decide an SOA can do some powerful things for your company, then there are two paths. One path is to introduce a governance aspect through a registry. The other path is that either the CIO doesn't see the SOA coming, and ends up having lots of SOA assets out there, and not knowing exactly how they're getting utilized."

What O'Connell is saying jibes with my own research on the topic. Last year, working with Webservices.Org and Systinet, I helped put together a study of about 1,000 Web services and IT professionals, and found registry adoption is fairly low among most companies -- because most companies have just started exploring SOA.

Overall, a total of 48% of respondents said they either rely on informational methods or have no method at all of communicating the availability and location of a Web service. A quarter, 28%, said they have no method, and 28% communicated information about their Web services on an “informal” or “word-of-mouth” basis. About a third, 34%, will post information about their Web services on an intranet site.

Among advanced SOA sites however, registry adoption rises significantly, the Webservices.Org/Systinet survey found.. While 17% of companies early in the SOA game have a registry, this percentage soars to 44% among advanced users -- those deploying 20 more services on an enterprisewide, reusable basis.

As an SOA effort gains steam, and the number of available services increases, a registry can help promote reuse and sharing, and therefore significantly cut development costs. "As a result, increase the number of services that you have, and you have a virtuous circle, where the more services that you have, the more custom code development time you eliminate, and the higher the ROI is on your SOA," O'Connell points out.

In addition, he added, "registry can help you with governance by modifying who uses what services when, and also what business cases a particular service is applied to. What you don't want to have happen is have a service deployed or modified badly in such a way that it disrupts the operating environment, and even causes an application to shut down, lock data, or lock the functionality of the network. Then everybody would freak out, asking, 'What is this SOA thing? May be we should puts the brakes on it.' Registries can introduce control."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

There has been considerable hand-wringing over the potential performance impact of SOA, and especially XML, on server environments. In a new think piece posted at Search WebServices, ZapThink's Jason Bloomberg sheds some light on the challenge of high-performance SOA -- and yes, he uses "high performance" and "SOA" in the same sentence.

Granted, SOA is a services abstraction, and "every abstraction comes at a price," Bloomberg observes. "Loose coupling, composability, agility, and the other benefits of SOA all introduce performance overhead." At large sites with a lot of users and traffic, SOA performance is a huge challenge.

Performance planning and enhancement didn't start with SOA, of course, and Bloomberg advises that architects and other SOA developers fully understand traditional capacity planning and performance management tools. "There's no way we'd be able to figure out how to scale Web services if we hadn't already worked out how to scale traditional Web applications," he writes.

Bloomberg recommends addressing potential performance bottlenecks at different levels above and beneath the services abstraction layer. For example, service and infrastructure virtualization "can provide cost-effective approaches to dealing with variable performance issues, essentially by abstracting a specific part of the infrastructure. Virtualization is especially useful for dealing with unexpected spikes in demand, but the complexity of virtualizing heterogeneous resources can often limit such approaches' effectiveness."

The SOA governance framework also can play a key role in SOA performance, Bloomberg adds. "The broadest, most agile approach to SOA performance is to plan for it as part of the governance framework for the SOA implementation. ...craft policies that will maintain the required performance levels while empowering users as much as is practical." This will create predictable limits for overall performance, he adds.

Posted by joemckendrick in SOA  |  Permalink  | Comments (1)  | TrackBacks (1)

By now, I'm sure many readers have seen the latest line of Apple television/video commercials: the cool, laid-back, relaxed "Mac" guy standing alongside the uptight, somewhat nerdish "PC" guy. The PC guy, Woody-Allenish, is neurotic and full of issues, and even catches the latest "viruses" going around.

I wonder if there could be a similar commercial drawn up for an "SOA" guy versus a "Web 2.0" guy. The SOA guy, of course, is corporate through and through, obsessed with policies, procedures, and security. The laid-backed Web 2.0er, on the other hand, is just busy mashing things up and having a good time.

Ultimately, the SOA and Web 2.0 guy are going to have to learn to work much more closely together, and perhaps their opposing styles will complement each other.

Industry watcher Dion Hinchcliffe has been talking about this meeting of the minds for a while now (his blogs can be found here and here.) Dion is a leading proponent of the thought that both SOA and Web 2.0 are essentially one in the same, as both offer the availability of reusable and rapidly deployable services offered over the network.

Some pundits have speculated whether Web 2.0 -- which includes all the sexy stuff such as Google and wikis -- may eventually usurp more structured and deliberate efforts as SOA. Other industry skeptics -- especially Nick Carr, the skeptic of skeptics -- wondered a few months back how well Web 2.0 could really serve the enterprise.

Dion, however, posits that the convergence is taking place between SOA and Web 2.0 in the form of "Enterprise 2.0." Dion hit the nail right on the head about a year ago when he asked, "Is Web 2.0 the Global SOA?"

As he described it:

"If you do a superficial comparison at least, Web 2.0 is all about autonomous, distributed services, remixability, and is fraught with ownership and boundary/control issues. And yet, Service-Oriented Architecture (SOA) is all about, you guessed it, autonomous, distributed services, composite functionality, and is fraught with ownership and boundary/control issues. Sound similar, no? It does seem that we have a classic case of fractal architecture on our hands. Is Web 2.0 actually the most massive instance possible of service-oriented architecture, realized on a worldwide scale and sprawling across the Web? The answer folks is, apparently so."

Dion recently provided examples of traits that will define Enterprise 2.0 architectures, such as: supporting "choice of customer deployment of functionality as a service, and in installed mode," "is architected and priced/sold as a series of services," and "provides process management, configuration, conversion, integration, testing, systems management, end user training tools to minimize implementation and support labor."

Very much in line with the goals of SOA. Stay tuned.

UPDATE: ebizQ has just announced a Webcast, led by Gartner's David Mitchell Smith and moderated by ebizQ's Beth Gold-Bernstein, on the convergence of Web 2.0 and SOA. Details on the Webcast, to be presented October 31st at 12:00 p.m. US Eastern Time, are posted here. .

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

There's been some talk across the industry lately that SOA could usurp the functions of enterprise resource planning systems.

Rich Colton, application integration manager with Washington Group International, doesn't necessarily agree that SOA will vanquish ERP. Nevertheless, his company is deploying service-oriented architecture to effectively fill in the gaps left by ERP systems.

I recently had a chance to chat with Colton about this emerging role for SOA. His company, based in Boise, Idaho, provides engineering, construction and management for projects ranging from bridge construction to weapons destruction. The company had gone through a number of mergers in recent years, and therefore was left with multiple proprietary, custom-built and packaged applications. But a single environment did not exist that could fulfill the various roles these systems played.

"We have not found an ERP system that meets the engineering/construction industry's requirements," Colton says. "Several have tried, including both Oracle and SAP. We found they really didn't offer the kinds of products that we need in different areas, such as project management, project controls, estimating, or materials management. We ended up having to use the best of breed in different areas. Up until now, it's required a lot of duplication, triplication, and more, of information from one system to another."

Washington Group employed Oracle Fusion middleware to move to an SOA that would abstract many of the functions used across the company into a common service layer. "By integrating these systems, we can -- on the back end then on the front end -- build some business processes that aren't being executed within the legacy application execution systems, and have it done in a layer above that. We can then update the appropriate systems where needed."

What was Washington Group's greatest challenge in its SOA deployment? Colton says that his team faced many issues around getting .NET and Java EE environments to interoperate. Washington Group's back-end systems run on Java EE, but they need to connect with desktops at the front end. "We write most of our Web services and our back ends in Java for the Java EE environment. Our client side may be .NET as well as Java clients. We have to ensure that our Web services are consumable by both environments."

"What we found still is that the vendors choose which portion of the standard they want to implement. So we've had to work though those issues."

Colton also reports that efforts to encourage reuse of the components have also borne fruit. "The issue is understanding your business, and what components you need to build that you're going to orchestrate," he relates. "That's what we've done. We've built some reusable components that we use in a number of different processes that we've developed, and we've been able to use those same components over and over again -- so we don't have to rewrite those components."

For example, Colton's team helped develop a document control service that gets widely reused across the company. "Document control is a big part of our business, because we interact with so many clients, subcontractors, vendors, and government agencies. Every project has to manage every piece of information going in and out. We track it all; whether it's paper or emails."

Washington Group uses EMC's Documentum system to accomplish this. "In the past, to use the Documentum API, we had to build point-to-point connections between applications the Documentum backends. With Web services, we only had to implement that API in one place, then built a series of components around a Web service that our applications can use. These applications just call the Web services, instead of building an API in their environment."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

What is the best predictor of SOA success? Most SOA success stories to date have a common demoninator, in that they have a robust and disciplined governance framework in place. The enterprise knows what it wants and what to expect from its SOA efforts.

IBM's Scott Simmons just posted this informative piece on how governance can make the difference between service-oriented architecture and service-oriented anarchy.

"Success with SOA does not 'just happen,'" Simmons writes. Instead, all successful SOA stories have a common theme -- "they have implemented a governance approach to support the design, development, deployment, and operations of an SOA solution framework."

An SOA governance strategy should have at least four characteristics:

1) Give it teeth: According to Simmons, "the definition and enforcement of policies and procedures to support SOA design, development, deployment, and management of services with a corresponding set of methods, techniques, and tools to support SOA and the tactical and strategic requirements of the business."

2) Give it a center of excellence. An SOA center of excellence should bring in experts from both IT and the business.

3) Get an executive sponsor. An SOA effort needs an executive with clout who can represent the effort at higher levels of the organization -- very important at budget time.

4) Think long term: Simmons says that SOA is a long-term project, with long-term results. "SOA is an incremental and evolutionary change to IT and the organization, and benefits from an iterative implementation."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

What do SOA and enterprise data warehouse have in common? As it turns out, lots. They serve the same purposes, require the same type of governance structure, deliver the same kind of ROI. Most importantly, they need each other.

Consider the similarities: Both enterprise data warehouses and SOA battle the silos. Both are about getting the right information at the right time. Both emphasize "reuse" as a primary value -- SOA reuses application components that get written and validated once and deployed many times; EDW reuses data that has been written and validated once and gets deployed many times. Both require a strong, enterprise-focused governance structure that involves the business and builds support. Both need metadata repositories to succeed on an enterprise scale. Both may have negligible ROI the first time around; but economies of scale grow exponentially as assets are shared or reused.

Teradata has been talking about SOA as an enabler for new applications getting deployed against its warehouse for a couple of years now, and IBM also made the connection earlier in the year when it fused the concepts of enterprise information management and SOA. To recap some observations I made in Webservices.Org at the time: SOA needs enterprise information management. Enterprise information management needs SOA. SOA will bring EIM alive across the enterprise, and EIM will be the killer application for SOA. Enterprises need to cut through the silos and be able to cost-effectively publish data from any application, running on any system, regardless of original data format.

Through Web services, end-users can direct queries and access analytical applications. Such components can provide a service interface that centralizes the computation and sifting of data, versus traditional SQL commands. A Web service may access the right data sources and do the analysis to provide a customer’s profitability history, or calculate the probability of losing the customer, or even seek out abnormalities to detect fraud.

Posted by joemckendrick in SOA  |  Permalink  | Comments (1)  | TrackBacks (0)

"We are taking our technology investment and re-engineering customer-related services as a set of Web services. We have smashed large monolithic applications into smaller components. Componentizing all our available product sets is a big and ongoing job, and has changed the way we work in terms of IT development and delivery.’

SOA has become a process of creative destruction, as reflected in the above quote from John Finch, director of development and delivery for the information solutions division at Experian. VNUnet has just published an article describing how Experian leveraged SOA-based processes and technologies to develop a Customer Event Management system (CEMS) to support its base of leading financial institution customers.

The goal of the system is to enable financial institutions to rapidly assess and process new accounts using Experian's online services. The credit giant's services are being delivered as standard components through Experian Web services, including Detect (application fraud prevention) and Delphi (credit scoring). The CEMS was built with the .NET Framework, and is currently being tested by a major financial customer.

Interestingly, Experian is employing a souped-up version Microsoft's Visio, a graphic tool for application development, to help visualize the SOA deployment. "We can sit down with customers, assemble processes, press a publish now button and produce executable code. In just a few steps we can build a new application," Finch is quoted as saying. "If they don’t like what they see on the screen, we can re-engineer it." Call it just-in-time application development.

Another interesting twist cited in the article is the fact that Experian's mainframe environment is also a participant in the SOA-based CEMS project. XML calls are made directly to the mainframe, though it is a often challenge to meet service-level agreements this way, Finch said.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

In a new ebizQ Webinar, Jorge Mercado, lead architect of the software architecture group for the MedicAlert Foundation, talked about the challenges and benefits behind his organization’s successful SOA deployment. (Available here from ebizQ.)

MedicAlert, which currently has 30 services in production, embarked on the SOA path for two reasons, Mercado explained. First, the organization sought to achieve interoperability not only between its own internal applications, but with partners as well. MedicAlert’s mission is to provide up-to-date personal health records to hospitals, doctors’ offices, EMTs, and other medical professionals and establishments. Second, MedicAlert sought more agility in its business, which could be achieved through the faster turnaround of new applications.

The system, called E-HealthKEY, is intended to provide the foundation’s partners more seamless access to pertinent medical information. “The level of interoperability that is provided by implementing an SOA is really what we’re after,” he said. “Keeping information in our repository and our repository alone is a good thing, but that’s not where we want to be in the future. We want to be able to share information with hospitals, doctor’s offices, labs, and pharmacies. Being able to provide readily available access to your personal health records is our goal.”

MedicAlert’s architecture is built around a business policy engine that contains all pre-existing policies. Web services can be deployed against the engine. The advantage, Mercado said, “you don’t have to recreate the policies from scratch for every new Web service you build.” Web services are built with both .NET and the Java Platform, he said.

Interestingly, MediAlert’s strategy was to start small with its SOA effort. “We did that really out of a need to solve immediate business requirements. We started small so that we could get results quickly. And as the business needs grew, and as time allowed, we then engaged more of a top down approach, which takes more into consideration the finer details about what the business wants out of a service.”

However, he added, the bottom-up approach only works for so long, until the effort needs to be addressed by the business at large. “Once you get the opportunity to engage a top down approach, or a meet-in-the-middle type of approach, you want to make sure that your services are modeled and designed properly. You can only achieve that if you get the business folks involved. You have to understand how 'this particular service needs to perform these functions in this manner.'”

Posted by joemckendrick in SOA  |  Permalink  | Comments (1)  | TrackBacks (0)

I've been ruminating over the results of a recent InformationWeek survey, which the publication entitled "The Dark Side of SOA." I'm not sure where the gloomy title came from, since the survey seems to generally point to some pretty bright expectations from service oriented architecture implementations.

Yet, for initial implementations in the survey of 273 technology executives, there were few cases were these expectations were met -- seven percent, to be exact. Another 24 percent report they weren't happy with the way things were working out.

Interestingly, the survey fuses the categories of 'SOA' and 'Web services.' The problem with this fusion is that many organizations may have a significant amount of Web services, which aren't necessarily orchestrated or managed as part of an SOA -- they're JBOWS, or Just a Bunch of Web Services.

I had the chance to talk with Infravio's (or webMethods') Miko Matsumura about what this survey is telling us. Miko pointed out that the survey demonstrates organizational barriers more than technical barriers. "There's a prevailing notion that reuse isn't occurring because of discovery, because people don’t know about things -- but that turns out to be actually not the case."

Actually, "the reality is that people don’t fully engage SOA because of mistrust, and political reasons, and because of silos. And silos evolve not because people are dumb, but because people are pretty smart. They know who their bosses are, they know which kingdom they below to, and they k now that the enemy may not be the product they compete against in the market, it may be the other division In the company that gets more budget than them."

For example, Miko said, about 55% of respondents said one of the challenges is that SOA introduces more complexity into IT systems. "What does that mean, introduce more complexity?" he asked. "It means it introduces someone else’s interest into my workflow. So the developer says, 'now I have to deal with complying with these standards for interoperability, whereas before, I didn’t have to. That’s more complexity. Now I have to deal with getting approval from another business unit, whereas before, I didn’t have to. Complexity really means introducing somebody else’s viewpoint."

Such as being married introduces more complexity than the single life. In the case of enterprise SOA, "it's like being married to 40 people," he quipped.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

One of the things I want to accomplish with this blog is, as the title suggests, is bring you accounts of "SOA in action" -- to look beyond the bits and bytes and see how and where organizations are putting SOA to work on a day to day basis to grow the business.

That's why I was drawn to this account of International Truck's foray into SOA, just published in InformationWeek.

The challenge: International Truck had all types of back-end legacy systems that the company wanted to surface into a "Common Vehicle Tracking system" that could track truck production in near real time, and flag any defects or bottlenecks in production. If successfully deployed, such a system could save International Truck up to $3 million a year. But getting at the information -- which was spread across various ERP and homegrown systems -- was a challenge.

What's interesting about this deployment -- and I'm sure is the case at many enterprises -- is that the VP of IT knew that standards-based software would not be available for everything the company needed. Instead, they would have to rely on a hybrid of standardized and customized service interfaces to make it all work.

The credo I'm hearing a lot with SOA is to simply, as Nike says, 'just do it.' Standards may take some time and gnashing until they mature, and in the meantime, companies should forge ahead with their efforts. No two SOAs will ever look alike.

At International Truck, developers built two Java EE-based interfaces to a homegrown order management system and Baan ERP system. Plans are to extend these interfaces to customers and trading partners. Eventually, the company expects to be able to swap out the order management system with little or no disruption to the tracking system. Sounds like they're moving ahead in full gear.

Posted by joemckendrick in SOA  |  Permalink  | Comments (1)  | TrackBacks (0)

Lately, there's been a lot of consternation across the industry questioning the whole "reuse" paradigm around SOA. The greatest value in SOA -- at least in the early phases -- comes from the ability to 'write once, deploy often.' Business units seeking functionality through services do not need to reinvent (and pay) for the wheel; that wheel may already be in production, maintained, and tested in another part of the enterprise.

However, no good idea goes unquestioned, and, lately, some have been asking whether businesses can, or even willingly, effectively reuse (or share) services. This argument, of course, cuts right to the heart and soul of SOA. In a recent issue of his newsletter, .NET and Web services guru David Chappell observed that the same issues that dampened reuse in object-oriented programming now plague service oriented architecture. For the most part, these are organizational roadblocks, he wrote. Not only are there financial disincentives to sharing code over the wall, but "creating services that can be reused requires predicting the future. Doing this is very difficult–how can a service’s creators accurately guess what future applications will need?" The 'If you build it, they will come' approach is tough to turn into real reuse."

To look at the value and adoption of reuse, LogicLibrary has just issued a study of its early adopter customers, and found the concept is providing a return on investment. (A PDF of the report is available here.) The study found that respondents had, at this point, anywhere between 10 to 60 services in production, with an average of about 26 services.

The study's authors, Jeffrey Poulin and Alan Himler, start off by injecting some common sense to the ROI formula they developed -- that reuse is not “free.” In fact, the cost of building a reusable service is up to 50 percent more than the cost for a similar piece of proprietary software for one-time use. They observe that "setting up the people, training, processes, tools, and components that fit into that architecture requires an initial investment and commitment from the development organization."

The study goes on to find, however, that with reuse, this initial investment quickly pays for itself. The study looked at more traditional component-based reuse, then at SOA-based service reuse. The study's authors conclude that after an initial learning curve, the development costs for reusing an SOA service are about half the costs required for traditional component-based development and integration, which represents about a 90 percent total savings over development from scratch. They go on to calculate that SOA-based services show a positive ROI after only 1.3 uses, compared to an ROI after 1.7 uses of a component in traditional development. In other words, an SOA component will pay for itself the first time it is reused within another business process.

This study is one of the first to quantify that there are economic advantages to reuse/sharing through SOA. The value of SOA is increasingly being proven. However, as David Chappell points out, your organizational ducks need to be lined up in a row.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Can SOA testing be made more intuitive? ebizQ colleague Brenda Michelson recently posted some interesting observations on progress being made on this front.

As with all complex undertakings, visual representation is the best path for efficiency and understanding the relationships between services that are being assembled or mapped to business processes. It has worked well in software development itself, and, for that matter, anything else involving computers. Witness the success of anything GUI-ized over the years.

Let me add these thoughts: What can't be aided through graphic visualization needs to be automated, especially in the emerging world of SOA testing. Over the years, I have had opportunities to chat with folks active in the SOA testing space, including Narendra Patil of Optimyz and Wayne Ariola at Parasoft. They point out that while organizations are just getting started with the deployment of multiple, managed groups of Web services or SOAs, testing such services could prove to be far more complex than it was in the world of siloed applications. A growing number of Web services requires a multiple testing scenarios that grow in volume by geometric proportions.

As Nerendra put it in a discussion we had a while back: “If you have 10 WSDLs, and each has 10 Web services operations, then you're talking 100 combinations. And if each operation just has 10 test data points, then you're talking 1,000 combinations. Sending 1,000 requests and getting responses and manually verifying them is a one-by-one, very sequential process.” (The complete interview is posted here at Webservices.Org.)

Visualize -- and what you can't visualize, automate. SOA is a network effect, with many moving parts relying on other moving parts inside and beyond the firewall.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

When it comes to service-oriented architecture, the prevailing assumption is that IT will be talking and working in synch with the rest of the business. However, IT tends to be a pretty diverse group in and of itself -- will IT people be talking and working in synch with other IT people?

Service-oriented architecture differs from most other integration projects in that it's an effort that reaches outside the IT silo, requiring participation from all ends of the enterprise. Surveys I have seen and have conducted find that most SOA projects are still occurring within the domain of the IT department. However, inevitably, business-side executives need to take a co-ownership role in the process for SOA to deliver on its potential.

The first challenge, however, may be bringing together participants from across a very wide IT spectrum. Ann Bednarz, writing in Network World, spoke with several thought leaders on the challenges of bringing together enterprise architects, application developers, network specialists, data managers, and storage administrators into a common purpose. Easier said than done, she observes: these groups are "traditionally distinguished by their own tools, methods, and domains."

I've seen many instances in which organizations have had several groups of architects, all working for different purposes. Sometimes, on rare occasions, they may actually talk to each other. SOA demands a new way of thinking about the way these various groups communicate. As Dan Foody, CTO of Progress Software, pointed out in the article, SOA moves problems to different parts of the application stack -- from the network level up to the application level, for example. "Things you might traditionally do in the network infrastructure are problems that can no longer be solved the same way -- whether it's compression, load balancing, failover or intrusion detection."

Foody adds that "the tendency of the application teams is to assume that the network won't provide all of this, so there's a natural inclination to do it all themselves." Ultimately, this will stymie SOA scalability and manageability.

As a result, there may be turf battles over control of various aspects of services being rendered via an SOA-enabled infrastructure. However, Foody and other experts urge all IT participants to keep the business perspective front and center. Stop thinking about "applications, packets, and messages," and think more in trems of "customers, orders, and fulfillment," Foody advises. SOA is a long-term transition that will reshape the business, and IT -- all parts of IT -- need to be full partners with the business side in this journey.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Does "reuse" bring value to enterprises? Does Java EE have a future in SOA? Is SOA in danger of being swept away by the "Web 2.0" paradigm?

Over the past few months, there has been a lot of heated discussion swirling around some of these fundamental "givens" of service-oriented architecture. One can be forgiven for wondering if SOA was already teetering on the edge of irrelevancy, long before it had a chance to prove its potential.

Evans Data approached some of these questions in a survey of 400 development managers earlier this summer. The survey, which originally was created with a Web services theme a few years ago, has been increasingly gravitating to SOA topics as well. I analyzed the results and authored the final report for Evans, which found significant growth in various aspects of Web services and SOA.

First off, the survey found the percentage of functioning SOAs (defined for survey purposes as "a series of standardized, shared, loosely coupled services representing one or more business processes") has almost doubled. Twenty-four percent of respondents are saying they currently implement SOA, an 85% increase from 2005.

While actual number of services is a crude measurement of the scale of SOA, this is, nonetheless, on the rise as well. Thirty percent of respondents expected to be using more than 20 services over the next year, a 58% increase over current levels.

While there is a raging debate about the value of reuse, the survey found the practice is on the rise. Respondents to this survey seemed to think reuse was a pretty good thing -- three out of ten said the ability to reuse services is the greatest cost advantage to Web services -- leading the list of various cost benefits. (Reduced integration expenditures followed in second place.) The survey also found that more than 50% of enterprises now share services between two or more business units -- a 20% increase since the last survey in mid-2005.

Then there are the questions over the fate of the Java Platform as the world moves to SOA. Burton Group's Richard Monson-Haefel may be predicting Java EE's ultimate demise, but that didn't show up in this year's survey. In fact, the survey found a rise in adoption of the Java platform for Web services and SOA. Three out of four companies expect to be working with the Java Platform by next year, a 12% jump from current levels -- and still a step ahead of .NET, by the way.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

This is a new era for service-oriented architecture. Companies are moving from the learning and pilot stages to actual functioning implementations. Real money is being invested, and real problems are being addressed.

How far can we go with service-oriented architecture? Where should we start? What are we missing? Where’s the payoff? How disruptive of a force will SOA become?

Today, we christen a new site, SOA in Action, to help answer these questions and more. This will be the place where you can find articles, podcasts, research, white papers, Webinars and more, on planning, building and managing SOA solutions. On November 14th and 15th, there will be a two-day virtual conference on SOA in Action, which will feature case studies and panel discussions from those who have successfully implemented SOA solutions.

There are a lot of promises now swirling around SOA, not only from vendors, but from analysts as well. Earlier this year, Aberdeen Group issued a calculation that businesses can collectively save about $53 billion in integration costs if they adopt more standardized SOA approaches, mainly through IT productivity gains and cost savings. Gartner says the market is booming, estimating the worldwide application integration and middleware market at more than $8.5 billion in 2005, and is growing at a rate of seven percent a year. Of course, SOA has plenty of detractors as well.

The purpose of this site, SOA in Action, is to demonstrate that service-oriented architecture ROI can be achieved. Within this blog, you will find stories, links, experts' predictions, and plenty of opinion on what challenges lay ahead, and just as importantly, what is working and what isn't working in SOA deployments. As the tagline says: “plan it, build it, manage it.” Each phase of the process has its challenges, and we will explore these challenges.

To quote ebizQ colleague Beth Gold-Bernstein, “we’ve seen an interest in SOA catapult over the last few years… it seems just about everyone is thinking about it,” she said in a new ebizQ podcast. “The bottom line is you’re not going to achieve the promised benefits of SOA if your projects fail…”

Through this site and blog, I intend to help illuminate the way to achieve the benefits of SOA. You may have seen some of my works in ZDNet, Webservices.Org, or in Database Trends & Applications.

I look forward to interacting with you over the coming months to talk about, and hopefully bring clarity to the opportunities and challenges SOA presents.

Posted by joemckendrick in SOA  |  Permalink  | Comments (2)  | TrackBacks (0)