SOA in Action

Web services security standards have been proliferating in recent years, but SOA security is still a murky area. Among standards, the brightest light is WS-Security. However, the most recent Evans Data Web services survey finds that only seven percent of companies have fully embraced WS-Security.

A new article in AjaxWorld Magazine describes the factors that should be considered in SOA security, pointing out that current integration tools are built for ease of use, but are disconnected from the nitty-gritty of security. As a result, "it's easy to develop a security solution that is over-engineered, complex, poor-performing, and possibly even insecure."

AjaxWorld makes these recommendations:

Plan ahead: : Determine security requirements early in the process, not at the last minute. "From the beginning, you will need to determine what requirements may exist for authentication, authorization, integrity, non-repudiation, auditing, and confidentiality. Talk to your customers and end users and find out who will be levying security requirements."

Know your enterprise Infrastructure: "Never architect in a vacuum or assume anything about the existing enterprise security infrastructure. Security-wise, there will undoubtedly be systems such as LDAP directory servers, policy servers, and Public Key Infrastructure (PKI), with which you will have to integrate."

Stick to standards: "Now that there are accepted standards - such as WS-Security and its associated token profiles used for identity propagation (WS-Security SAML Token Profile, WS-Security X.509 Token Profile, WS-Security Username Token Profile) - as well as emerging specifications in standards bodies (WS-SecureConversation, etc.), there should no longer be any reason to create a home-grown security messaging syntax."

Emphasize the flexibility of Web services: Web services will often "be called and used together in ways we may not always anticipate. ...focus on Web services transaction management, centralized auditing, and detailed, descriptive error handling."

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

Since I began this blog almost two months ago, I have mainly focused on the internal integration aspects of Web services and SOA. That's where everyone's attention is these days. However, there is just as much to talk about with external-facing service integration as well. And, sooner than later, most companies will be grappling with the challenges of deploying services to partners and customers.

The similarities and differences between internal SOA and external service deployments were recently explored in depth in a recent ebizQ Webinar by Jim O’Leary and Mark Denchy of Extol International, which I moderated. (A replay of the Webinar is available to all ebizQ members and is archived here.)

O’Leary and Denchy talked in some detail about the collaboration broker model, which serves a role similar to that of integration platforms such as WebSphere or BizTalk, but addresses partner integration issues, as well as non Web services communications.

It may be some time before Web services replaces traditional EDI, O’Leary pointed out. “We don’t expect that to happen in cases where there’s an existing EDI infrastructure,” he pointed out. “People have a tendency not to fix what’s not broken. And EDI is certainly very good at what it’s intended to do.” Where Web services will pick up traction, he said, is “for new systems, new B-to-B interactions. Informational requests that are non-transactional are very good fits in general for Web services.”

Many of the same tools and protocols used for internal SOA integration can also be applied to external-facing Web services. However, when it comes to requirements, O’Leary draws a distinction between external Web services and more internal SOA. “The requirements for Web services and business integration are really distinct from those that surface in a SOA context,” he said. “In business integration, we need Web services primarily for integration of partner and enterprise services and data resources, and also for exposing business processes as services for internal or external consumption. Generally speaking, you can consider requirements for Web services in business integration as a subset of those in SOA.”

What’s driving external service deployments? “Increasing rates of Web services adoption are being driven in mid-sized companies because of those supply chain pressures,” O’Leary said. He said efforts are being heavily influenced by “supply chain partners, particularly on the demand side, in driving mid-sized companies to adopt Web services for business integration, and that’s for both near real time B2B information access, and also for connection to internal applications, especially those offered by commercial application vendors.”

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

Who said SOA couldn't scale to Monstrous proportions? I recently spoke with Joan Lawson, director of global integration for the Monster job site. Monster has recently expanded its reach to 24 countries across the globe, and needed a service oriented architecture that would stretch across the separate regional units that now comprised its new global reach.

Lawson's global integration group is responsible for integration between the various regions Monster covers, as well as integration between applications within a region. "Each region has its own job search site, which we know in North America as Monster.com," she explained. Each region also has its own application stack, "which are typically Siebel CRM and Oracle ERP systems," she added.

Prior to the SOA implementation, new orders would be manually routed to an Oracle financials system for invoicing, Lawson explained. Job postings were then distributed to appropriate regional units via a point to point extract, transform, and load process. "Due to a global marketplace and offshoring trends, our customers were demanding real-time integration of jobs and resumes across the various regional platforms," Lawson said. "The challenge was integration of jobs and resumes real time, across all of our regional job search sites. An employer entering a job in North America may also have a job available in India."

The integration challenge was similar with jobseekers posting resumes, she continued. "if you're a person who is interested in working in many places around the globe, you want to be able to enter your resume in one location, and have it be available to employers around the globe.".

Monster also had a "second pain point," and that was in its ordering processes, Lawson continues. "We needed to be able to integrate order data from our sites, our Monster.com sites, to our Siebel CRM application, to our Oracle ERP system. Our customer service reps want to be able to cross-sell and upsell customers." An additional project, called the business gateway, served as a B-to-B Web environment between Monster and employers.

To address these challenges, Monster developed its SOA via Oracle Fusion middleware, including Oracle's Enterprise Service Bus and BPEL Process Manager. When a customer posts a new opening, Lawson explained, the SOA middleware delivers the order to the applications within the various regional units. The ESB and BPEL components "enable that integration of data from our customers right through to the employers' site -- their home site as well as any target sites," Lawson explained. "If an employer sends a file feed of a job that's going to be available in North America as well as in Czech Republic, that will flow all the way through."

Lawson's team employs a mix of application adapters and Web services to make this all happen. Monster's system uses adapters to interact with APIs for the Siebel CRM and Oracle ERP systems, and "our own job search platforms are primarily .NET environments, and those applications offer Web services," Lawson said. The BPEL aspect comes in for mixed business processes, she added. "In some cases, we need to use a business process. So we use BPEL Process Manager. There's often some human workflow component that needs to occur in a process." Services deployed within the Oracle middleware include search functions, job interactions, resume interactions, or applicant interactions.

What's the biggest challenge in an SOA implementation effort? Educating participants in the new ways of SOA, says Lawson, who has also implemented SOA-based projects prior to joining Monster. "Any time you're initially involved in enterprise integration in a company, the challenges you run into are educating people, evangelizing, getting people to be willing to work with you, and getting them to give up some of that ownership of data and processes," she says. The most critical aspect is "educating people in the benefits of sharing data, of sharing processes, and giving up some control."

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

There's been a lot of heated discussion lately within the industry on whether reuse can drive the value of service-oriented architecture, or whether the concept has flopped.

I recently had the opportunity to join fellow ebizQ bloggers Elizabeth Book, Ronan Bradley, Dave Linthicum, and Neil Ward-Dutton in an effort to shed more light on the value of reuse in service-oriented architectures. (The podcast is available below.)

The vote was, apparently, five to nothing in support of reuse. However, the theme running through the discussion was that reuse is an important mechanism for the success of SOA, but is not the primary benefit in and of itself.

Neil observed that the success of service reuse boils down to supply and demand. While SOA services are relatively easy to create from a technical perspective, the supply may be far outstripping the demand. The reuse paradigm "is really about is supply versus demand," he said. "You can't create a market from just creating and throwing stuff out there, when there's no demand. And the only way to really understand demand is to tie into the strategy of the organization with an enterprise architecture approach, really understand where the business wants to go, then look at what actually needs to be built."

Dave agreed that reuse was not the endgame of SOA, but rather a means to take "architectures are completely unworkable messes for the most part" and "turn them into something that's better aligned with business, that's changeable as the business needs change, and something that's workable and cost effective in the organization. ...Reuse is going to be a side benefit of that."

Ronan also said reuse was a critical component to SOA, agreeing that it was the means to an end: "We're seeing more people moving away seeing from reuse itself as the primary benefit, and starting to move towards terms like improved infrastructure, improved agility and even better alignment to business. All these to my mind are consequences of being successful with reuse. In order to develop and deliver on a successful business plan for SOA, I think it's important we stay the course, and continue to look at how we drive up reuse."

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

Clearly, there's something for every industry in service-oriented architecture. However, financial services and telecommunications -- which have products and services heavily wrapped up in information technology -- have been leading the way in SOA, as they have in most other integration intiatives in years gone by.

While manufacturing tends to be a bit more conservative, its likely to be much more demanding of SOA when it does arrive. While enterprise SOA can be achieved with fairly wide margins for error or lower levels of availability, manufacturing SOA must be ironclad and industrial-strength. Fortunately, many of the ingredients needed for manufacturing SOA are already in place.

Colin Masson, Alison Smith, Dennis Gaughan of AMR Research recently put together an analysis of the special challenges involved in developing SOA within the manufacturing sector. "Manufacturing SOA requires much higher fidelity services, event definition and monitoring, and deterministic orchestration of services, or execution of triggered and scheduled workflows," they wrote.

A copy of the full report is available to registered ebizQ members here.

The time is ripe for SOA in the manufacturing space, AMR Research analysts believe. Here's why:

Pent-up demand for new software. AMR Research's latest survey of 900 companies finds that after years of under-investment, manufacturing operations investments are the number-one priority for enterprises this year, ahead of ERP systems. "Almost two-thirds of the manufacturing investment will be on in-house custom applications development, or the extensive customization of various manufacturing applications," the analysts write. "It’s a market ripe for efficient development of composite applications and service providers."

Manufacturers were using "composite applications" long before SOA. There is no single dominant model for manufacturing software, and solutions are highly fragmented, the analysts say. "Building composite applications was a necessity in manufacturing before the invention of the SOA acronym, and manufacturing is positioned to be the first demonstrable beneficiary of broad SOA adoption," they observe. "A large manufacturing company may operate a fleet of 40 or more plants, many of which acquired through mergers, and the software application landscape within each plant is likely to be dramatically different. This complexity has been, and will continue to be, a major driving force for vendor adoption of SOA in the manufacturing operations arena."

"Higher fidelity" is required for manufacturing systems than what is currently available. "Enterprise SOA, BPM, and BAM architectural thinking is firmly grounded in the "low-fidelity" world of business systems," the analysts state. Manufacturing SOA will need to leverage existing manufacturing services to meet the pressing demands of real-time production and supply chain management. To succeed, manufacturing SOA will need a manufacturing services definition and repository, real-time event definition and monitoring, real-time operations process management, and real-time operations intelligence. The current crop of business intelligence and data mining tools are geared to "low-level uptime/downtime" associated with data warehouses, the analysts say.

The analysts urge, however, that manufacturing SOA not be implemented in a vacuum. "Manufacturing SOA, while having unique requirements and a compelling business case, must not be delivered in isolation to the broader enterprise SOA," they write. "Companies must look to define enterprise architectures that encompass both plant-level and enterprise systems. To ensure this, manufacturing must be well represented on the enterprise architecture team."

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

Fellow ebizQ blogger James Taylor sees a growing convergence between the service delivery architecture enabled through SOA and business process outsourcing -- especially as it relates to the delivery of business analytics capabilities.

He also cites a new report from Forrester's William Martorelli which discusses the convergence. In the analysis, Martorelli says SOA -- in the form of a layered service-delivery architecture -- can isolate BPO vendors from the complexity of customer environments. "Ultimately, vendor investments in this enabling platform will make BPO vendors better suppliers, and understanding BPO's importance will make customers better BPO consumers," Martorelli said.

James says that Martorelli needed to say more about "decision automation," however. He notes that there is a requirement for an external and updateable business rules engine, and that "the rules must be exposed in a way that allows the customer of the BPO provider to manage the rules. The critical capability is that the customer can continue to control the rules, even while the BPO runs the process."

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

SOA is a multi-year journey, not an overnight sprint. In my last post, I described Commonwealth Bank's gradual, success-by-success approach to SOA. Along that same theme, British Airways (BA) also advises that wider use of its budding SOA could still be up to five years away.

In this very brief summary, Paul Colby, CIO of BA, said the airline was using SOA around parts of its employee self-service staff portal, according to Paul Colby, CIO of BA. But before going deeper into SOA, the company will wait for standards and best practices to be solidified, he added. "If SOA in three to five years' time enables you to articulate that process design with your systems and enables you to change your systems with more flexibility, that's great... but I don't think anybody is anywhere near there."

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

Moving into SOA involves the orchestration of many combinations of services and technologies that can deliver an endless range of new applications to the business. Given all the messages bombarding the market, one can be forgiven for thinking that the time to jump full-force into SOA is yesterday.

However, some experienced SOA pros advise a go-slow-and-think-carefully-about-what-you're-doing approach. One such seasoned veteran, Stuart Johnson, general manager for integration and service-oriented architecture at Commonwealth Bank of Australia, has been overseeing an SOA effort since 2002, and found that while his technical staff was ready to service-oriented the entire bank, the business side was perplexed, or even unaware of what SOA was all about.

As recounted in this article in CIO Insight, Johnson said that when the whole effort began back in 2002-2003, his staff quickly got up to speed on fine-grained, atomic Web services, and they quickly started to push for building complicated composite services that would combine many services. However, Johnson resisted these urges. "I wanted to keep the technology as simple as possible. SOA is already the next buzzword, but a huge SOA architecture will make it difficult to build anything."

For example, the bank's technical and business analysts wanted to push to use services to expose more data online to customers and to partners on back-end systems.

In fact, the bank did not launch its first orchestrated service until 2004, and this was only after careful study and consultation with the bank's major vendor, Microsoft. The first service was designed to help customers open a direct-deposit account, which requires a series of steps that took as long as six weeks, and potentially access up to 40 different data sources. The bank employed SOA within this process to verify customer identity, make sure there was money in a checking account before a checkbook was issued, and to issue a bank card.

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

The title on Ronan Bradley's recent post, "FBI Accuses Some SOA Vendors" caught my eye, thinking that maybe more vendor CEOs got caught "pretexting" board members and journalists. Or, perhaps they were simply being accused of inflating customer expectations about what SOA will do for them.

It turns out that the FBI itself had inflated expectations about SOA, and has become a little more realistic about the limitations -- and possibilities -- of service-orienting.

Ronan observes that the FBI had its share of technology debacles, including the FBI Virtual Case Manager, which cost a cool $104 million in tax dollars. The latest attempt, using SOA methodologies -- is project" Sentinel," a new digital information sharing modernization project. However, moving to SOA involved another "a rapid and painful learning curve" for the FBI, as Ronan puts it.

Ronan surfaced a recent article in Government Executive which described the FBI's pain in detail. "We were in a frenzy about [SOA] a year or so ago, when we were writing Sentinel requirements," Jerome "Jack" Israel, the FBI's chief technology officer, is quoted as saying. But the SOA revolution has been postponed in favor of gradual change. "We've gone from maybe hyped-up about it to the cold realization that 'Hey, this SOA is a lot harder than industry is making it out to be,' " Israel says.

What happened? First, the Web services standards aren't quite developed yet, and vendors were continuing to incorporate proprietary elements into their SOA products, Israel is quoted as saying.

The FBI's efforts to service-oriented its internal systems may have gone to a slower track, but the bureau has seen impressive results from a more outward-facing -- and smaller-scale -- SOA project. The agency launched a Regional Data Exchange, or R-DEx, a series of information sharing pilots with regional databases. Under R-DEx, the FBI has created plug-ins to Justice Department databases for four regional law enforcement data sharing associations, with more to come -- using an SOA registry built with off-the-shelf IT products.

Because the project is built using SOA methodologies, the bureau has already been able to pull out and swap some of R-DEx's components, including an underused portal function and search engines, project manager Margie Lonergan is quoted as saying.

An interesting effect of this swappability is that it has kept "vendors on their toes," she added. The knowledge that they're easily replaced, "entices them to make sure they stay best of breed."

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

Why do some organizations seem to excel at SOA, even in the earliest stages, while others have a hard time struggling with it? Ken Vollmer, analyst with Forrester Research and a keynoter for ebizQ's upcoming SOA in Action virtual conference, has some observations on the common threads SOA winners share. I caught up to Vollmer the other week, and he shared some insights on what it takes to make SOA succeed.

First of all, Vollmer makes it clear that the potential benefits from service-oriented architecture are too big to ignore.

For example, he explains, "I can think of two financial institutions that were able to achieve a 60 percent reduction in time required to develop new application functionality. I don’t know of too many CIOs that shouldn’t be very interested in that, because it’s a huge savings in costs. If they’re really under pressure to do things with less, they should be looking at service-oriented architecture."

At the root of such success, he says, is a factor that separates out forward-looking enterprises from more stagnate organizations: corporate culture. "There are some organizations that are flexible and forward-looking that are able to bring this technology in, work with it, experiment with it, get it working, and then actually start generating some significant improvements," Vollmer points out. "Some organizations are just better at SOA than others. Will the advantages of SOA be the same across the board? Absolutely not. Because there’s too many other factors that can impact the final result."

Nevertheless, shifting to an SOA way of thinking can result in positive changes. "One bank CIO told me that his development group had been thoroughly indoctrinated in a new model-driven way of doing things, and has been able to totally wipe out his application backlog," Vollmer said.

If you are one of the unfortunate many who are mired in more hidebound, or even moribund, corporate cultures, don't give up hope, Vollmer adds. Start a small, incremental SOA effort, and show results -- such as finishing projects in less than half the time normally expected -- at a fraction of the cost, of course. The businesspeople will start lining up outside your door, and success will breed success.

But again, every organization will see its own variation on the SOA success theme, Vollmer says. "There are huge differences in how organizations function. Every culture is different." But the change is inevitable, as enterprises that are ahead of the SOA curve gain efficiencies over their competitors. Just as new manufacturing techniques kept winners ahead of the pack for decades, new technology processes -- such as SOA -- will be felt in the market. "We don’t want to keep manufacturing things the way we did in the past; we would never get anywhere."

Ken Vollmer's keynote at the upcoming SOA in Action conference will be on Thursday, November 16th, from 10:00 to 11:30 am ET. For more details, click here.

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

Last week, I posted details from the latest ebizQ survey that demonstrated a that runtime automation tools greatly improved overall satisfaction with SOA governance efforts.

What, exactly, is at the root of this satisfaction? Dan Foody, CTO of Actional and Sonic products for Progress Software, recently described the "blind spots" that runtime automation tools help to overcome.

Blind Spot 1: Service Behavior. While development and deployment time governance tools can validate metadata such as WSDL and message content, they can't validate that a service behaves according to the rules, Foody says. Runtime governance tools enable you to "point and click to declare auditing, security, and other policy behaviors."

Blind Spot 2: Process Awareness. "Every time a service is reused, it essentially becomes part of a new application - a new business process - and that business process may have an entirely new set of rules to obey... You can't assume that development and deployment time governance checks on a service are enough." Here, Foody says, runtime governance tools can apply their governance policies not only to individual services, but across entire end-to-end business processes, regardless of when the services were deployed.

Blind Spot 3: Rogue Services. Don't assume that every service goes into production after a proper review process, Foody advises. The result is "rogue services" (or "junk services" as Ben Moreland called them, per my previous posting on this site). A runtime governance product can track the presence of such services in the registry, as well as applications using the service. "The most advanced runtime governance products can even automatically quarantine rogue services and service uses until they're approved - eliminating the risk of rogue services," he said.

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

Often, committees are the best way to slow down and obfuscate things. But when it comes to SOA, you may want a committee to interject itself between service creators and your registry. A committee with teeth may be the best way to keep "junk" services out of an enterprise service registry.

James Kobielus just published a very thorough update in Network World on the state of SOA governance, and I was pleased to see The Hartford's Ben Moreland prominently featured. I have had the opportunity to speak with Ben on his SOA work, and The Hartford is clearly one of the SOA leaders within the insurance industry, if not across the board.

The Hartford has a very strong governance effort, led by an SOA steering committee consisting of application architects. In their bimonthly meetings, committee members assess proposed new services "based on such criteria as supportability, reusability and adherence to the company’s SOA reference architecture." The Hartford also employs a workflow manual to drive the process, Kobielus reports.

Moreland is also aware of the issues around services pushed into the registry without IT support to back the service up and maintain it, and therefore requires that IT sign off on all proposed services.

“We don’t want a junk drawer of unsupported services in our SOA registry,” Moreland is quoted as saying.

This process keeps business and IT groups from proliferating "junk" services to the group’s master Universal Description, Discovery and Integration (UDDI) registry, the article noted. Moreland hopes to automate much of the approval process through workflow tools that integrate with its UDDI registry.

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

Microsoft clarified its service-oriented architecture stance at its recent SOA and Business Processes Conference in Redmond. The vendor -- which has led the way with most of the prominent Web services standards that have morphed into the primary SOA enablers -- says its approach is to tackle SOA at the operational and tactical level, versus a massive enterprise-wide rollout.

John deVadoss, director of Architecture Strategy at Microsoft, calls this focus "Real-World" SOA, a not-so-subtle slap at the top-down enterprise endeavors suggested by other vendors. In a Q&A posted at the Microsoft site, deVadoss urges SOA planners to build incrementally, one project at a time, to build up a successful portfolio of services. It's important not to set out to build SOA just for the sake of doing SOA, he said.

"The fundamental problem with the big-bang mega approaches to SOA is that they almost always end up being out-of-sync with the needs of the business," he said. "This approach has been a key factor in fueling industry discussions around the lack of alignment between business and IT on the topic of SOA."

DeVadoss said Microsoft is a proponent of the "Expose/Compose/Consume" model to SOA: First, there's exposing assets -- "you need to service-enable your existing assets. SOA is not about rip and replace, it is about leveraging your existing assets," he said. Then, SOA is about "composing these services – people call this orchestration or choreography, and sometimes workflow – but the key idea is that you have the infrastructure to empower your people, employees, customers and consumers, to use the services in the real-world."

Finally, he said, "the rubber meets the road when you enable consumption of the services, and so you have what we think of the consume layer."

DeVadoss also provides this advice on getting started with SOA:

1) Set out to deliver value to the business. The goal is not to "do SOA."

2) Take a "middle-out" approach. DeVadoss said that "top-down, big-bang mega approaches do not work in the real-world. Bottom-up approaches are not manageable. But there is an approach that we see successful customers adopt – what we call the 'middle-out' approach. They start with clear business challenges and focus on creating business value."

3) The "build-it-and-they-will-come" approach won't work. DeVadoss said he's seen SOA teams spend 18 months to 30 months building a services infrastructure, only to find the business has moved on. "We recommend customers partition their use cases into small sets and build out the entire use case end-to-end, from the data through to the consumption. Partitioning your functionality helps you track changing business needs much more effectively."

4) Demonstrate value in rapid iterations. "Time-to-value is a critical metric, a healthy metric," DeVadoss pointed out.

5) Use a "snowball" approach. "How do you build a big snowball? You start with a small snowball," said DeVadoss This is probably the most important take away with respect to leveraging SOA to drive business value."

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

One of the classic pieces of advice that gets applied to many technology or business endeavors is not to try to "boil the ocean." The same applies to building out service-oriented architecture. Many success stories so far have started developing and deploying their SOAs incrementally, project by project, ROI by ROI.

Select a service area that can deliver quick ROI, and put it in place as a proof point that can demonstrate the viability of the SOA approach to the rest of the enterprise. This, of course, is a bottom-up approach. Some SOA proponents say because SOA transforms the enterprise, a top-down organization-wide approach is what's needed. Often, SOA starts as a bottom-up, incremental initiative, then evolves to a corporate-wide top-down approach as the ROI is realized.

A new report in ComputerWorld looked at one company, the IT operations group at Siemens AG, which first built services around automating and streamlining the processes for fulfilling internal requests to IT for new equipment and passwords.

Thomas Buse, section manager of concepts and processes for Siemens, said that "once users from various departments started using that system for new workers, they asked IT to similarly automate and improve the processes in their departments." He added that in the process, Siemens cut the time required to implement new processes by 83%. The company releases four to eight new business processes to run on its SOA every six to 12 weeks.

A related article also describes an incremental approach to SOA taken at Clear Channel Communications. The media company began its SOA efforts two years ago with the creation of a portal with single sign-on access to its PeopleSoft applications. Justin Myrick, solutions architect at the San Antonio-based company, said that his team "picked a fairly small project to get going on, something we thought we could complete pretty quickly. We had great success in getting our environment set up. In three months, we got this project out live. Then we chose another project to get started and then had two in parallel after that."

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

In my last post, I talked about ebizQ's latest survey of 313 enterprises, which reflected the state of governance within budding SOAs. (Listen to the Webinar here.)

As Beth Gold-Bernstein so aptly put it, "the press may be starting to get tired and getting ready to move on to the next big thing or hype, but in reality, most organizations are really just starting to get serious about SOA."

SOA has been around as a oft-discussed and well-hyped concept for at least three years, but only just over one out of four respondents (28%) say they've actually got services deployed. Another 21% consider themselves to be in the pilot stages, while 24% are in exploration of SOA.

In most cases, companies have less than 10 Web services in production. As Beth pointed out, the industries taking the lead in deploying SOA include financial services and banking, insurance, technology, and communications -- industries that typically are at the cutting edge. "These are often the early adopters of new technologies. Interestingly, they were also the early adopters of integration technology. That's not a coincidental finding, that early adopters of integration technology are drawn to SOA. They already have the infrastructure, and they’re looking for better ways to do that; they’re ready to move on."

What these survey results tell us is that enterprises are just starting to experiment with the possibilities of what service-oriented architecture can offer, and there is still a lot more we don't know than we do know. Enterprises still need to formulate their governance strategies, and establish ways to measure the results of their efforts, both from an IT efficiency standpoint (more easily measured) and a business standpoint (more difficult to measure.)

One thing is certain, however -- we know who the early adopters are -- financial services, telecom, and technology companies -- and we can watch and learn from their misteps and sucesses.

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

Most companies that have functioning SOAs in place are pretty sour on the state of their governance solutions. While about 17 percent say their governance is sufficent, another 40 percent say it is not sufficient. The rest aren't quite sure yet.

However, in cases where automation is introduced to facilitate governance, the picture changes. Those sites that have runtime and design-time automation are far more likely to report high levels of comfort with their governance solution than those who rely on manual enforcement.

These are the findings of a survey of 313 companies, presented in a recent Webinar by Beth Gold-Bernstein. (The Webinar is archived here.)

"It turns out that the biggest differentiator between those that feel their governance solution is sufficient, and those who believe their governance solution is not sufficient, is the degree of runtime automation," Beth explained. "Those that have runtime automation have an automated solution that is managing governance policies whenever these services are being accessed and run have far higher levels of confidence." She added that "while design-time automation is good, runtime automation is going to be absolutely essential as organizations move down the path to SOA."

The new survey also had some additional surprises. For example, that business goals -- versus IT efficiency -- are driving most SOA deployments at this time. Almost two out of respondents, 64 percent, said that the goal of their SOA effort is to "increase business agility," followed by "IT reuse" at 57 percent. "Business process optimization" followed with 55 percent, and another 44 percent sought the advantages of composite application development.

"When we looked at what the most popular combinations were, they were increased business agility and IT use, increased business agility and business process optimization," Beth said. "That led us to the conclusion that SOA adoption is really business driven, it is not just for reducing IT costs. SOA is more of a business initiative than an IT initiative."

Of course, it's still early in the SOA game, and the survey confirms this as well: Almost half of all respondents have fewer than 10 services actually deployed, while fewer than 20 percent have at least 50 services in production.

But it's never too soon to start thinking of governance, as explained by Brenda Michelson, who joined Beth in the Webinar. "I believe that governance enters the SOA picture when the first policy is set," she said. "Typically, this is during the technology proof of concept, and the first policies are on the design side, service interface design, and what technology protocols you’re going to use – Web services, REST, XML, HTTP. An organization might need to introduce runtime governance in their first project."

Following her analysis of the survey results, Beth made a good case for runtime automation for governance: "Current governance enforcement is primarily manual, and apparently, the most respondents do not think this is sufficient, and they are right to worry. Manual practices will cause significant issues in managing the effects of policy changes, especially as the number of employed serices increases... The demands for SOA governance will overwhelm the capacity for manual controls and enforcement. Automated solutions for both design time and runtime governance are necessary to manage large-scale SOA implementations."

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

More and more frequently, it's getting to the point where you can't talk about Software as a Service without invoking SOA, and, likewise, SaaS is becoming a larger part of SOA conversations.

Many of you may already be users of Salesforce.com, for example, in which applications are accessed and data managed over the Internet for a per-usage fee. Or, many of you may be more "casual" SaaS users of on-demand collaborative services such as Webex or PlaceWare.

Earlier this year, I authored a survey for the Oracle Applications Users Group (OAUG) -- in cooperation with Unisphere Research -- on the topic of Software as a Service. Of the 576 companies (mainly Oracle enterprises) in the survey, almost two out of five respondents, 39%, reported that they used SaaS applications, at least occasionally. This group is split between “daily” users (23%) and “occasional” users (16%).

Annrai O'Toole, CEO of Cape Clear, says SOA is a big and growing market, but he sees the main paradigm shift in enterprise applications centered around SaaS. In his latest blog post, Annrai says he wouldn't be surprised if SaaS adoption encompasses at least 80 percent of enterprises within the next decade.

As SaaS, combined with SOA methodologies, mature, Annrai predicts that enterprises will move away from the big ERP-style applications in droves. "For complex, multi-user, multi-system-integration enterprise apps, there aren't many real SaaS alternatives to Peoplesoft/Oracle or SAP today," he writes. "And even if there were, there are some significant hurdles to overcome. However, we really believe that both of these factors are changing -- there are a whole new breed of SaaS alternatives to the incumbents arriving and these companies are bringing with them a set of strategies that will credibly enable customers to switch off those big complex SAP/Peoplesoft/Oracle installations."

Granted, it may be painful to attempt to move off a well-established enterprise application to a more on-demand model. But Annrai believes SOA will remove much of this friction. "SOA and SaaS go hand-in-hand in opening the doors to this world -- this is where SOA/SaaS rubber meets the road."

The interaction between these two forces will take place at the integration level -- which is the biggest roadblock for SaaS for many enterprises. "This issue is complex, not just because the data formats are complex and semantically rich and that the business rules are equally byzantine, but also because the integrations must securely and reliably traverse the firewall," he said. SOA will also pave the way for data and business rule migration in an SaaS context. Moving these rules from an internal ERP application to an on-demand service is also a non-trivial task.

Annrai observes, however, that "a lot of newer SaaS applications are going to be built on a SOA platform." Witness the success of Rearden Commerce -- built entirely on SOA -- as an on-demand provider of business and travel services to large corporations.

"SOA is making it easier to build these new applications, quicker to add new functionality to them, and integrate them with existing applications that customers already own," Annrai observes. In addition, many of the ERP packages are evolving to Web services standards themselves, replacing the more proprietary EAI adapters.

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

Ameriprise Financial's credo is "dream, plan, and track." The brokerage and financial planning firm, which was spun off from American Express a year ago, has always emphasized a long-term or lifecycle approach to managing customer accounts.

"Dream, plan, and track" has also become the credo of the firm's SOA effort, now in its seventh year. (Yes, Ameriprise's "dream, plan, and track" has a similar ring to our motto of "plan, build and manage" SOA here at the SOA in Action site.)

Tracy Legrand, chief architect for the financial planning firm Ameriprise Financial, talked about his firm's SOA progress at a recent press conference for IBM's latest SOA product rollouts, which include a registry and repository, along with 26 other products.

In 1999, long before the term SOA was even around, Legrand's team set out to address data integration issues through a hub-and-spoke implementation employing MQSeries messaging. These days, a hub-and-spoke implementation would be called an enterprise service bus, Legrand said. "It's very simply a way to connect services across the company, and allow them to communicate with each other." These days, the MQSeries messaging has been supplanted by SOAP/HTTP calls.

Back to "dream, plan, and track." Ameriprise's dream was to move its SOA effort from the realm of bits and bytes and make it a business proposition. "We realized is that in order for SOA to deliver the full business value, it has to become a business strategy," Legrand said. "If it stays as a technology strategy, what you find is that you get limited benefits from SOA.

Next is plan. "In financial planning, what that means is you establish a personal relationship with a trusted advisor, you identify your goals, and you determine what's needed to achieve those," Legrand related. Likewise, the planning aspect of SOA centered around funding the SOA in ways that will deliver maximum return to the business. "We focused on what are the key business services," said Legrand. "The services that we started with are customer management, asset management, and the notion of money movement - the ability to move between products, between funds, or accounts."

The SOA effort followed a roadmap which brought SOA functionality to new applications or services as they came online. "We didn't take a scorched earth approach, where we said, 'let's stop all of our investments, and rebuild the architecture as SOA," Legrand said. "Instead, we focused on what are the key business services that we need to support the business strategies of being more nimble, reliable, and a quicker time to market."

The next step was track. "In financial planning, you track progress against your personal goals, and you adjust them as necessary," Legrand said. "In SOA, we ended up doing the same thing. We started in 2000 tracking against a set of business metrics. The metrics that we tracked were things like reuse, time to market, and cost avoids." Governance became a key part of the tracking equation, since "it's important that you're governing the project investment against a roadmap of where you want to go. What are the services that you care about getting implemented in a robust, reusable way, what are the services that you can let be more specialized in nature?"

Legrand estimates that Ameriprise has saved almost $10 million in cost-avoidance over a three-year period just from one of its leading services -- customer management. He cautioned, however, that "cost avoids were a difficult measure to calculate, because you get into discussions about the road not taken. What would the road not taken have cost us to build these services? So you end up needing to create a set of mechanisms that help you value, what was the value of that choice? What was the value of investing in that service at an enterprise level, versus a portfolio level?"

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

For years, one of the big complaints about ERP -- and other enterprise software packages -- is that once installed, business processes would have to be bent, twisted, and reshaped to conform to the software, and not visa-versa.

Ideally, SOA urges that enterprise applications be broken down into both coarse and fine grain components, so that it's the software that gets bent, twisted, and reshaped to conform to a business process.

Is it finally time, then, for the business to have its day in the sun? Eric Boduch of Vitria Technology, for one, thinks its high time. In a recent article in Enterprise Systems Journal, Boduch says the time has come to start building what he calls "business process applications." (He calls them BPAs, but BPA also stands for "business process automation," an overlapping concept. Plus, it's best to avoid introducing new acronyms into the lexicon.)

The advantage to business process applications, Boduch writes, is that they are pre-built to "automate industry-specific, customizable processes based on industry standards and best practices." Such components should be built on an industry-by-industry basis, since each industry has its own specific goals, pain points, and partner networks.

Boduch offers industry-specific examples of how it would all work. However, it's not clear who would be assembling these new breeds of applications -- whether they will be custom-created for each situation, or if third party software firms (perhaps ERP vendors themselves) would put these solutions together.

Manufacturing: A business process application tailored for manufacturing "can manage the complete lifecycle of an order across distributed fulfillment centers. With visibility into the order at any point across the supply chain lifecycle, a user can aggregate and separate orders across multiple systems and divisions, and expedite the update and notification of back order information."

Telecoms: Telecoms can leverage business process applications "to automate and orchestrate selling, order entry, service activation, provisioning, and billing care processes across systems, people, and partners," Boduch says. Business process applications, he adds, "could facilitate a 'flow-through' end-to-end process for order fulfillment and reduce the impact of inevitable process exceptions."

Health Care: Business process applications can help address some of the inefficiencies that plague this heavily regulated industry, Boduch says. A business process application for health care "can automate and simplify the management of critical, complex health care transaction processes that span multiple systems, formats, and trading partners." The business process application should serve a platform for health care information exchanges that bring together providers, intermediaries, third-party administrators, financial services, members, and other partners.

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

How is SOA being received out in the trenches? A couple of recent conferences have brought forth both good news and bad news about the state of acceptance of SOA by technology professionals.

Okay, let's get the bad news out of the way first. A recent survey out of Australia finds that about 70 percent of respondents prefer to customize existing applications over taking on an SOA or even Web services project.

What's the problem here? Insufficient staff resources and lack of available skill sets are the main barriers. But read between the lines, and there seems to be a matter of will as well. Overall, the survey of 80 senior IT executives, conducted by InterSystems at a Gartner event, found "there is no single method of connecting to or extending IT applications that most respondents were confident they could quickly and cost effectively use." The report added that "when it comes to Web services, service-oriented architectures, workflow functions and business process automation, executing within a six-month period and doing so cost-effectively, is beyond the capability of most organizations." Support from management -- or lack thereof -- is likely to play prominently here.

Now, some good news. ComputerWorld reported a number of positive reports around actual working SOA implementations coming out presentations at BEAWorld. For starters, Shaygan Kheradpir, CIO at Verizon Communications said SOA has eliminated the communications barrier between the telecom's IT department and the business side of the house.

And now, from the same article, a really big ROI story. At Aflac, the insurance carrier is running a Web service that allows 11,000 insurance agents to access different types of data, so it doesn’t have to print and mail such data. Kurt Anderson, administrator of the myAflac portal, says the Aflac SOA application cost $600,000 to build, but will result in savings of more than $3.2 million annually.

Details are sketchy on exactly what went into the SOAs within these organizations, but there's no doubt these efforts received a lot of support from the upper ranks of management. The InterSystems survey points to potential sticking points that may make it difficult to make SOA live up to its promise. Namely, IT and development departments are stretched to their limits with cascading -- and often conflicting -- demands from the business side, and often have to turn to what works and can quickly be put in place. SOA is not an overnight project, but a long-term journey that may not show immediate ROI. Plus, additional investments will need to be made in training and skills development; not to mention user education. Lots of user education.

We're reaching the stage where we're going to start hearing lots more success stories (and not-so-successful efforts as well), and these will be reported in this blog. And, importantly, we'll be seeking to identify the common denominators that make SOA work.

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