SOA in Action

There's been a lot of rancor across the industry and blogosphere about the viability of SOA from the top down -- instigated as part of a huge business change -- versus bottom-up, in which individual SOA efforts pop up across business units, with the possibility of federating these efforts down the road.

But, sometimes, it's just so much easier when the CEO is laying down the law. That was the experience with Farm Credit Canada (FCC), a provider of financial services for Canadian agricultural businesses. FCC's approach was very much driven from the top down, instigated by the CEO, who brought in a new CIO specifically to move to SOA. As a result, the establishment of SOA principles for developing and managing applications was in place within 90 days.

FCC employed SOA methodologies to restructure itself from a silo organization, with each silo supporting applications for a particular business function, to a “service-centered” model, where applications are constructed according to service oriented architecture (SOA) principles.

As described in a new report in MIS Quarterly Executive, the transformation of FCC to a process-centric organization is scheduled for completion by the end of 2011. FCC moved to SOA with a six-step process:

1) CEO driven: "The CEO initiated a culture change initiative that underpinned his vision of creating a customer-centric organization."

2) Process revolution: "The organization focused on what needed to be done to integrate the corporation’s processes and systems to enable it to provide a great customer experience."

3) IT itself was transformed. "The CIO assessed the current state of the IT organization, and all current IT projects were halted while this was done." Siloed approaches were abandoned in favor of an architecture-centric approach supported by SOA principles.

4) A proof of concept was undertaken "by implementing a carefully chosen business process with SOA."

5) Governance: "The organization undertook a detailed redesign of other processes, and working through the governance issues of managing a process-driven IT organization."

6) The benefits to date of transforming the IT function and its technology were articulated. The CIO identified a range of benefits, from improved communication between the business and IT, to the development of reusable IT assets.

Complete PDF available here. (Free registration required.)

____________________________________________________________________

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

Over the years, many companies have turned to app servers -- both Java Enterprise Edition and Microsoft .NET framework -- to handle, under the covers, the "plumbing" of messaging, standards, and protocols. App servers were seen as the easiest on-ramp to SOA.

However, how much of a role will app servers play in the SOAs to come? Do companies even need app servers?

ebizQ is conducting a survey on application server usage, and the impact of SOA on app servers. This survey explores how enterprises plan to implement new types of applications such as SOA, Web 2.0, mashups, open source, etc. Will you continue to use application servers? Take our survey and you'll be entered to win $100!

Click here to access the survey.

___________________________________________________________________

Posted by joemckendrick in SOA • SOA Research and Analyst Reports  |  Permalink  | Comments (0)  | TrackBacks (0)

Open source platforms offer a compelling value proposition for SOA deployments, and two case studies presented at the recent Red Hat summit demonstrate how this value can be realized.

Writing in CIO, CIO's Esther Schindler provides accounts from SJ, the Swedish railroad, and North State Communications.

SJ integrated its ticket sales with online auctions, to move seats not sold 48 hours before departure would be auctioned online. The railroad turned to SOA to make this capability possible within its enterprise framework.

North State Communications turned to SOA to facilitate a billing system transformation. The company employed ESBs and JBoss to automate the way it makes services available to customers.

Pierre Fricke, director of SOA product line management for JBoss, said companies are only just starting to consider open source platforms for SOA. He expects the trend to accelerate by 2010. (Thanks to Matt Assay for the pointer.)

Open source is bringing SOA capabilities to what have been unserved or underserved markets -- such as small to medium businesses. Since the inception of SOA in its current form about five years ago, large commercial vendors have concentrated on the high-margin, deep-pocketed companies. Open source commoditizes SOA offerings, making it more affordable to more companies.

__________________________________________________________________

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

Forrester analyst Randy Heffner, who has made frequent appearances here for ebizQ events, has just released a report that describes the best way to "build a SOA." (Full report available here at ebizQ.)

Or actually, as Heffner points out, the multiple ways to build a SOA. "There is no one best sequence for building an SOA platform," he writes. "Even though most SOA platforms start with messaging technologies such as HTTP, SOAP, REST, and message queuing, there is no one dominant way or sequence in which to build an SOA platform. The wide diversity among various organizations’ existing software infrastructures, combined with each firm’s different priorities and drivers for SOA, lead to a wide diversity of investment streams for building SOA platforms."

Plus, Heffner adds, incrementally is the best way to go. Businesses keep changing, as do SOA products, so "the majority of firms evolve toward their SOA platform."

According to Heffner, Forrester recommends the following five steps for building an SOA platform:

1) Identify existing infrastructure’s SOA capabilities. In other words, know what you already have, Heffner says. This helps avoid duplication, especially when it comes to spending money on new products. "Identify which functions your existing products provide fully or partially."

2) Identify priorities for new SOA capabilities. Pull out or develop application roadmaps and estimate how SOA-based services will map against these plans, Heffner says. "identify the major types of service implementation styles that will be required for the high-priority services you must build over the near term. For example, service orchestration or legacy integration might be a high priority for your SOA platform, in which case, the first step is determining whether your existing infrastructure can fulfill these requirements. If there are gaps, you can then investigate SOA specialty product categories, such as ESBs or integration-centric business process management suites, to learn how they might close the gaps."

3) Identify your long-term needs for SOA capabilities. This determines what kinds of products a company buys down the road, Heffner says. "Identify your high-level long-term needs for your SOA platform. For example, you may be able to get by for now with lightweight SOA management capabilities (e.g., simple monitoring of service implementations) based on your existing IT management tools, but you will likely see a future need for the stronger SOA features and functions that an SOA management solution provides (e.g., managing service contracts for SOA-based services)."

4) Match your platform plans to your organization’s investment strategy. "Most organizations buy products in connection with specific projects," says Heffner. "However, we see an increasing number of firms that intentionally position such purchases as merely the first stage of a growing investment in the selected products, with each subsequent solution project expanding the investment to meet its needs."

5. Evolve your SOA platform in line with the business value of solution delivery projects. "Find the investment that, within the current project’s bounds of affordability, meets near-term SOA requirements fully," Heffner advised. This is "the approach that best keeps an SOA evolution on track and that has the most palatable investment model."

____________________________________________________________________

Posted by joemckendrick in Management • SOA • SOA Research and Analyst Reports  |  Permalink  | Comments (0)  | TrackBacks (0)

In today's news, ebizQ reports on a new bulletin issued by Butler Group which made the case that any and all SOA depends on governance. However, as Butler Group states, governance is more than putting a bunch of technologies in place, be they registries or repositories. The real issue is on an organizational level -- often, services are put into production long before governance comes along, and then everything has to be retrofitted.

As we have found in surveys conducted here at ebizQ, most early SOA efforts do not have governance of any kind in place -- typically, organizations hold off until they have some type of critical mass of services before they consider it worth investing in governance. As Butler's Rob Hailstone put it: "Most organizations deploying SOA leave it too late to implement effective governance. The longer you leave it, the more difficult it becomes to 'retrofit' governance to an operational SOA environment. However, the effort must be made if the SOA initiative is not to descend into chaos."

The recent ebizQ survey, conducted in partnership with SAP, finds that even companies with the most advanced SOA deployments – in terms of enterprise reach and number of reusable services – have yet to formulate governance strategies or methods to measure the value of their SOA to the business. The survey finds that only one out of seven companies currently have active governance efforts underway.

The low level of governance is perhaps not that surprising, since many organizations are just starting their SOA implementations. What was eye-opening about the survey, however, was that even among the most advanced sites surveyed, two out of three companies do not yet have comprehensive governance programs in place. In addition, many respondents see their current or planned governance programs as being ineffective, the survey finds. Even among the most advanced SOA efforts, governance is not delivering its full value.

I recently joined SAP's Christian Hastedt Marckwardt in a Webcast discussing the survey results, and the evolving role of SOA governance. (Click here to access the full Webcast.)

_____________________________________________________________________

Posted by joemckendrick in Management • SOA • SOA Research and Analyst Reports  |  Permalink  | Comments (0)  | TrackBacks (0)

What are people working on these days, SOA-wise? That's the question put forth by SOA entrepreneur extraordinaire Dave Linthicum, who reports that the pace of SOA is slow, but steady.

Companies are not jumping head-first into new approaches and technologies, but are carefully planning and considering where they are going. Every SOA is coalescing into a different and unique combination of patterns (like snowflakes, DNA, and landfills). And while that doesn't mean a rush to embrace SOA, that's a very good thing.

Dave says he's seeing five essential activities underway at many locations:

Modeling and implementation: "Holistic modeling of the SOA and all of its working parts."

Security design and implementation: "Figuring out how you're going to secure and govern your SOA."

Semantic understanding and metadata modeling: "Identifying all application semantics and defining the common metadata model."

Service design and implementation: "Designing services properly, implementing them, and tracking them."

Orchestration and process modeling: "Modeling processes, and implementing them directly from the model."

Note the strong emphasis on modeling. This is important in making the architecture clear and tangible to the business users. Dave adds that SOA practitioners "are not yet looking for 'key enabling SOA technology,' at least not yet." As shown by the above five areas of concentration, the focus is on setting up methodologies, defining deliverables, determining how all of these artifacts are related, and education.

____________________________________________________________________

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

We all know what we need to know about SOA, and learn more every day (especially if you visit the ebizQ site on a daily basis, right?).

But how much do you know about some of the inner workings of SOA? Or the history of some of the standards and practices?

ebizQ has created a challenging quiz to test your SOA acumen. In 10 tough multiple choice questions, you will find out where you fall on the SOA IQ continuum. For example, how acquainted are you with the origins of SOAP and XML, or the essential commands of REST?

Score an 8 out of 10 or above, and you'll rate a place in the "SOA Boardroom"!

Take the quiz here.

_____________________________________________________________________

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

Fellow ebizQ community activist Brenda Michelson provides a glimpse of panels the SOA Consortium will be hosting at the impending Gartner AADI and EA (Application Architecture, Development, and Integration and Enterprise Architecture) Summits, to be held in O-Town, FLA.

Todd Biske will be involved with both panels, so you know it will be good -- extremely reasoned and informative.

On Wednesday, June 11 at AADI, Todd, along with Melvin Greer and Mike Tavis, will be talking about measuring the value of SOA. The panel, to be moderated by Gartner's Daniel Sholler and SOA Consortium's Richard Soley, will explore companies' experiences in justifying and measuring the value of their SOA activities, including developing initial business cases and continuously demonstrating the benefits.

On Friday, 13 June at EA, John Williams, Maja Tibbling and Marty Colburn will join Todd to discuss SOA & EA lessons learned from the trenches. This panel will be moderated by Gartner's Bruce Robertson and Richard Soley. Panelists will look at the links, synergies and dependencies between SOA and EA. They will address the big question of the moment: How does SOA fit into the EA picture?

_____________________________________________________________________

Posted by joemckendrick in Management • SOA • SOA Events • SOA Research and Analyst Reports  |  Permalink  | Comments (0)  | TrackBacks (0)

We've talked quite a bit here and throughout the ebizQ-sphere about the convergence between SOA and enterprise data management, and how services can be employed to source and leverage data for various analytics.

In a new interview with Michael Meehan, Kirstan Vandersluis, founder and chief scientist for XAware Inc., directs the discussion to a new type of service emerging -- the "data service mashup." As the name suggests, he is talking about employing lightweight Web 2.0 methodologies to build front-end apps that pull needed data into a dynamic presentation for the business end user.

But it's a lot more than the on-the-fly Google Maps-style mashups we've been seeing in recent times. As Vandersluis describes it, a data services mashup is "a mashup in terms of pulling data from multiple sources into a logical unit. So it's a mashup in terms of data. It's not a visual mashup. That's a whole different ballgame. We're pulling data from virtually anywhere into a logical unit. We're trying to take a bunch of back-end data systems, which are typically very complex, and make it look like something much more rationalized in terms of an XML Schema that somebody put some thought into designing."

The model Vandersluis is proposing is built around an XML schema. He notes that "the applications are relying on the contract, which is defined by the XML schema."

Data services mashups may work in conjunction with, or even serve as an alternative to data warehouses and data marts in some situations, Vandersluis also said. "It's just a different way to do things and there are trade offs.... The one benefit to our approach is it's all real-time. We're sending the sub-queries out in real-time to whatever systems you want."

So if initially you pointed all your data services at your data warehouse, and you find out later that's not real-time enough, you can change the data sets that are being mashed up, so one of them hits an operational data source.

Vandersluis and other data service mashup proponents have their work cut out for them. Understanding and adoption at the business level has been "spotty" to date, Vandersluis observes. "I think it's more a matter of how well they understand service-oriented architecture, which is the typical use case of a data services layer."

Organizations that are embracing SOA are more likely to be early adopters of data services mashups, he says. In addition, there is impetus at sites developing rich Internet applications. Such Web 2.0-ish are more likely to see a large volume of services, versus the more centralized and business-focused services that will be part of SOA.

____________________________________________________________________

Posted by joemckendrick in Data Management • Enterprise 2.0 • SOA  |  Permalink  | Comments (2)  | TrackBacks (0)

SOA comes in many shapes and sizes, but most times when the discussion comes up, it's about the challenge of service-orienting some aspect of core mission-critical systems. To date, of course, most SOA and Web services deployments have been on the periphery. Sometimes, these peripheral projects have been referred to as "lunchroom Web services" -- only a prelude to the grander SOA yet to come.

That's why it was interesting to run across this article, published in Thomas Erl's SOA Magazine, that brings up the topic of service-orienting the periphery as part of the overall enterprise SOA strategy.

At the periphery are "edge" applications, databases, and systems are probably more numerous and pervasive than the systems found at the enterprise core. They may consist of repositories, embedded systems, open source databases, and distributed or departmental servers. Often, they are low or no-budget efforts that address a specific point solution.

The challenge is bringing these systems and their processes into the main enterprise SOA effort. The article's authors, Paulo Rosado and Rodrigo Castelo, say there's a good business case to be made for service-orienting these edgy (or "shadow IT") systems, because while edge apps may be cheaper and faster to implement, they end up costing enterprises a bundle in maintenance and overhead.

These siloed projects cost more than more centralized projects, and eventually mushroom into more headaches for the centralized IT department. What seem like small, off-the-radar projects eventually end up with "ever-rising maintenance and support expenditures," the authors say. Ultimately, they estimate, the total cost of ownership could run up to be five times as much as centralized apps and systems. Plus, they explain, "ignoring shadow IT incurs the risk of hindering your SOA evolution, overlooking potential application innovations that could streamline business process and increase revenue, and increasing expenditures in the long run due to retrofitting, and also potential security and governance breaches."

Rosado and Castelo provide four key questions that need to be asked as part of any attempt to bring edge systems into an SOA effort:

• How fast can you deploy new services in your SOA environment, and at what cost? This is an important metric to discover, since time-to-market of new services will determine how well SOA is adopted at the edges. Issues around scalability, SLAs, access, and authorization (detailed below) will also affect speed of service deployment.


• Is your SOA environment ready to deliver new services with no SLA impacts on your core systems? Perform tests on your infrastructure to see how well it scales, Rosado and Castelo advise. "Because once you provide shadow IT the requested services, you need to assure their quality of service and the SLAs of your core systems, which are now serving requests to the outside. Shadow IT systems may initially be used by only a couple of end-users but can then be rapidly adopted by an entire department. An onslaught of requests will decrease your core systems' responsiveness, making them unusable by your shadow IT and any other systems dependent on them. In the worst case, this can overload your core systems and cause them to collapse."


• Can you control which systems access which services? "Once you expose services to your shadow IT, you must somehow ensure that only granted systems can access them."


• Can you transitively assure authentication and authorization once you lose control over the information? Rosado and Castelo advise adding a layer to the SOA to manage fine-grained governance issues. "More important than just controlling which systems can access which services, is controlling which entities in your organization can access and change the information that is now accessible through your edge applications."

____________________________________________________________________

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

In physics, they say the simplest solution to a problem is usually the right solution. Applying the laws of physics to SOA, then, it stands to reason that enterprise service buses (ESBs) are the simplest path to SOA within organizations -- and perhaps in many cases, the right path for the organization.

There's been plenty of concern that an economic downturn would skim already bare-bones IT and integration budgets; therefore making it more difficult to launch SOA initiatives that cut across the enterprise. ESBs are a vehicle that can help break the "complex links directly between applications, which are reducing agility, and consuming chunks of the IT budget just in maintenance," says IBM's Lief Davidson.

Lief recently sat down with ebizQ's own Peter Schooff to discuss how SOA managers can employ ESBs to get around any budget crunches incurred from today's tough economy. (Link to transcript and audio file here.)

"The business needs to become simpler and faster to address the various business problems and, hopefully, with a reduction of the complexity that IT is being bound into today, more of the budget can actually be spent in delivering innovative new value rather than keeping existing systems running." This is where ESBs come in, Lief said.

There's been a lot of discussion across the industry as to how far organizations that don't necessarily have the resources or executive political can pursue SOA. Add budget crunches, and SOA becomes an impossible sell -- even though it does provide cost savings and containment in the long run. ESBs may provide a way to kick-start SOA in any climate.

_____________________________________________________________________

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

In a new post, Alex Cameron, an EDS Fellow, notes that most well-established products and services have what is called a "dominant design" methodology behind them. For example, in the vehicle manufacturing industry, "the enclosed steel body car is a classic dominant design." The innovative growth and experimentation stage for the industry has long passed, and most, if not all, auto manufacturers agree on a common design. This can also be applied to aircraft, motor cars, lamps, typewriters, and integrated circuits -- you see little, if any, deviation by maverick manufacturers.

This same evolution from fast-paced innovation to dominant design has been taking place within the software industry -- much of the design has coalesced around Unified Modeling Language (UML).

In the next phase of software evolution, Cameron suggests that the industry is coalescing around service oriented architecture as the dominant design for integrating systems together.

"The concept of services and loose coupling is the product of a high level of innovation in the area of software architectures. The past saw mainframe centric architectures, Client Server, N-Tier, Layered Architectures, EAI, BPM and many others; all innovations towards solving a common problem, that of developing and integrating software components to form an information system architecture. However, none of them could be called a dominant design, simply because none had a follow-on and distinct phase of process innovation. In the case of a Software Architecture we could see this as a rise in "standards" that are adopted to control its implementation."

Cameron adds that SOA has taken software design well beyond what previous models have achieved. "We are now seeing the emergence of SOA Governance, SOA Maturity models and the like - I can guarantee no one has heard of a Client-Server Governance Model or Maturity model!"

It makes sense to conclude SOA has reached the stage in which it is the dominant design model. Of course, there are also plenty of analysts and pundits declaring SOA to be somewhat of a failure. So everybody and nobody is implementing SOA. But think about it -- if vendors and practitioners want to standardize and enable interoperability between disparate applications, interfaces, and services, what's the alternative to SOA? How else would they be doing it?

______________________________________________________________________

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

For some time now, I've heard consultants and analysts propose launching "centers of excellence" or "competency centers" to better manage newer IT initiatives such as SOA is one that has been proposed by consultants for some time now. Not only does such a body help kick-start SOA efforts in the business, but it's also a way to keep such efforts above organizational politics and fiefdoms. The SOA effort can proceed without being encumbered by individual department or management agendas.

Excellent idea. However, such efforts have been slow to evolve, and may be difficult for smaller to medium-size businesses to get in place. ebizQ's recent survey on SOA governance, conducted in partnership with SAP, found that only nine percent of respondents had established some form of competency center/center of excellence to promote and keep SOA efforts on the right track. Almost all of these were larger companies with revenues exceeding $1 billion or more annually. (Our Webinar on the survey results can be viewed here.)

While getting management to commit time and resources to an SOA center in and of itself may be an uphill battle, there may be value in extending the reach of such centers to enterprise data integration as well, according to John Schmidt, VP of Informatica and Chair of the Integration Consortium. This center may be described as an "Integration Competency Center," or ICC. In a chat with Beth Gold-Bernstein, Schmidt provides some guidelines to help businesses of all sizes implement an Integration Competency Center (ICC). He describes the elements that go into an ICC:

Financial management: "The ICC operates as a shared service. This is a set of best practices around charge back for shared infrastructure and individual services."

Architecture: "The ICC does not do enterprise architecture, but is responsible for the information architecture. They work with the enterprise architecture group, and 'connects the dots,' by mapping schemas to physical data sources to enable the translation, transformation, and integration. This ICC is the central federated repository."

Business Process Management. "This is not BPM per se, but this includes service flow modeling, information flows, business event modeling, and common definition of business events."

Integration methodology: "The process of running an ICC, defining it, organizing it, all the things you need to run an integration group, and how it will interact with other IT groups."

Metadata management: "The ICC group is responsible for data assets. Metadata ends up being a federated model."

Modeling management: "This includes techniques around canonical data modeling, what are the best practices, how do you build them."

Integration Systems. "This is about running integration systems as a specific class of applications – all the discipline of how your manage, plan and operate the system."

_____________________________________________________________________

Posted by joemckendrick in Data Management • Management • SOA • SOA Vendors  |  Permalink  | Comments (0)  | TrackBacks (0)

When most people think of the US Peace Corps, images of volunteers drilling wells and building schools in impoverished corners of the globe come to mind. Service oriented to the hilt, in the old-fashion sense of the phrase. This view is accurate, but these efforts still require a information technology infrastructure to best allocate and deliver its resources.

Until recently, that was provided by a mainframe system sitting in a silo in Washington, DC. A new report in Government Computing News describes how the Peace Corps moved to a service-oriented architecture methodologies to help keep track of and provide information services to its varied overseas activities.

Ram Murthy, director of application systems at the Peace Corps, recognized that a highly distributed organization -- spread across 70 countries -- needed a far more distributed IT infrastructure than the mainframe system it formerly relied on. Overseas users were unable to access the mainframe.

As is the case within many organizations public and private, Murthy encountered plenty of headwinds. Government managers were skeptical of the value of SOA to an organization such as the Peace Corps, because they thought SOA required 24x7 connectivity to Web services, and many Peace Corps officials were in areas that didn't even have electricity. Murphy successfully countered that the emphasis of the SOA wouldn't be on providing constant connectivity, but providing services when they are called. A more asynchronous view, if you will.

“We use the same principles of SOA, breaking it up into multilayer data services, business services and so on. But what we’ve also done is make sure that the framework supports disconnected mode,” Murthy said.

The Peace Corps' SOA effort began in 2006, when Murthy’s team was authorized $1 million in funding to start moving applications off the mainframe into a more distributed computing environment based on the .NET framework. The result was three applications that support posts and volunteers in the field: Crime and Incident Reporting, Site Enhancement and Development, and the Volunteer Information Database Application (VIDA).

_____________________________________________________________________

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

Financial services companies have had a tough ride over the past year, so anything that can be done to better take advantage of their information technology assets to streamline operations and increase the situational awareness and agility of the business is a good thing. That's where SOA and business process management (BPM) come in.

JPMorgan Chase, of course, is right at the epicenter of the financial storm that has been ravaging the industry, and the company's dominance and stability is due in no small part to its ability to smartly leverage SOA and BPM.

At ebizQ's recent Financial Services Live Panel, Ron Ambuter, CTO of the BPM Workstream Group at JPMorgan Chase, described how his company has been able to adapt and adopt technology and methodologies to help reduce costs, improve customer experiences, and maintain a competitive edge. Ronan Bradley, analyst with Lustratus Research and former CEO of PolarLake, led the discussion, and was joined by Keith Swenson, chief architect at Fujitsu Computer Systems, and Hub Vandervoort, CTO of Progress Software. (Archived recordings and transcript available here.)

Ambuter described how JPMorgan Chase was interested in the concept of reusability, which would help the organization "get better leverage out of the efforts that we were making to build and buy applications by reusing components instead of rebuilding and rebuying them over and over again."

With the troubles the industry has been having around subprime mortgages, writedowns, and tighter credit, it's likely

regulation and oversight will only increase, particularly in regards to risk management. Bradley questioned whether the prevalence of regulation holds back or encourages SOA adoption. Ambuter said regulatory mandates have accelerated his company's drive to SOA, noting that "the concept of SOA allows us to react probably quicker, and more expeditiously, more cost effectively."

The panel also discussed the challenges around extending managing services and infrastructure across multiple groups within organizations. Financial services organizations, of course, typically have multiple lines of business, from securities to brokerages to mortgages. Ambuster explained that organizational issues were his greatest challenge as well in implementing a cohesive SOA and BPM strategy at JPMorgan Chase. "We have rules and responsibilities that are compartmentalized by groups of folks, and we realize that as you go into this stuff, education and cross-pollination of information is critically important. It's not just the technology folks that need to understand this stuff, it's the risk folks, and it's the governance folks and it's the finance folks, and it's the business side folks."

Vandervoort agreed that "it's easy to get bogged down in trying to get alignment on a lot of different points across all the groups." He recommended three approaches to the problem, including "getting your transports aligned between business entities so that you can use eventing-oriented mechanisms to communicate across domains"; establishing SLA and security policies that ensure visibility; and establishing a common enterprise data model.

"You have to get your semantics aligned among the members," he said. "And that doesn't have to be a common vocabulary in its entirety, but certainly what we regard as the data in flight, those things that fly between domains and different working groups have to be highly normative."

Aligning SOA and BPM is also important. "While SOA is basically a technology trend, BPM is essentially a management trend," said Swenson. "A lot of people look at BPM and they get confused between the management trend and the technology trend. A lot of technology product companies have looked at BPM and looked only at the technology and come up with a kind of a programming language that they claim to solve the problem, which is great for the IT side of the house, but it leaves the business side out of this. As far as the adoption of BPM goes, one of the biggest barriers to adoption of the real business process is essentially the fear that the manager will lose control of the process."

Complex event processing is also a key initiative financial services companies need to undertake. As Vandervoort observes, "financial services is moving kind of in a logarithmic increase in velocity... things are ten times faster than they were a decade ago. When you go from three days order to settlement or trade to settlement to now under two hours trade to settlement, if I'm doing nightly reporting, I'm way out of alignment. Whereas ten years ago, that was three times faster than the speed of the pipeline. Today, you the ability to run awry in risk, terms, and exposure terms has been seen multiple times in the industry in recent years."

For companies seeking to increase agility and be more responsive to these highly competitive markets -- not just in financial services -- the combination of SOA and BPM can break down the constrictive silos that cut off essential data and processing resources.

____________________________________________________________________

Posted by joemckendrick in Business Process Management • Data Management • Event Processing • Management • SOA • SOA Events  |  Permalink  | Comments (0)  | TrackBacks (0)

Complex events "can be anything from a sequence of temperature readings to something like the First World War, which was a very complex event indeed." -Dr. David Luckham

David Luckham -- considered the "father of complex event processing" -- recently joined Dr. K. Mani Chandy, Rodney Morrison, and Beth Gold-Bernstein for an informative panel discussion on the relationship between EDA (Event Driven Architecture) and SOA. The panel, part of ebizQ's recent Event Processing Virtual Conference, which brought together the leading thinkers and proponents of EDA and Complex Event Processing (CEP).

The panelists were divided, however, over the extent of the role of human involvement in complex events.

Chandy, for example, said that human engagement is essential at some point in the complex event processing cycle. "I’ve seen quite a few applications, but almost none in which there is no human involved" For example, Chandy said, "in military applications, when there is a gun or device is fired to kill somebody. It’s always done with a human being responsible for their final action."

As Chandy pointed out:

"I think its absolutely critical for human beings to be part of this sense and respond system. It's important how the application supports the human being if you're looking at trading or fraud detection. In all these cases, its really important to have a human being involved. Fraud is one case where you might have an application that informs a credit card user that something inappropriate may be going on, without having a human being first check that."

Luckham, however, pointed out that there are many events are processed independent of human intervention. "There are many examples of event driven architectures where there are absolutely no humans whatever," he said. "The CPU on your computer is an event driven architecture, believe me. And its entirely event driven, clocked, without a human in the loop.

EDA is part of SOA on two different levels, Chandy said:

"One way that I’ve seen EDA used in conjunction with SOA is for service management. Many SOA vendors are exposing metrics that can give you information like end to end process time and activity times. Those metrics can be provided to a CEP system to help control and manage those services. I can, for example, do dynamic provisioning for a service that's getting maxed out."

Chandy also connected the dots between EDA and SOA. "If SOA means loosely coupled subsystems with very clean interfaces, so that new systems could be coupled into the substrate. Then EDA events fit within that framework, because EDA is also based on a loose framework, and is extensible." In a request-reply SOA scenario, "then EDA can still be coupled. There will be layering between the push and the pull parts."

_____________________________________________________________

Posted by joemckendrick in Business Process Management • Event Processing • SOA • SOA Events  |  Permalink  | Comments (0)  | TrackBacks (0)

Behold the zebra in the wild savanna -- when a it senses the presence of a lion, it knows to run away, as fast as it can. When it senses food supplies, it knows to act.

Do today's companies have this much situational awareness, and an ability to act quickly to survive and thrive? Not yet, but thanks to new approaches such as complex event processing, they're getting there, according to Gartner VP Roy Schulte. "We can teach computers to do what a zebra does," Roy said. "To collect and process event data to respond quickly and effectively."

In his keynote kicking off ebizQ's recent Event Processing virtual conference, Schulte broke down the essential pieces of complex event processing, and describing how businesses can leverage CEP, or being able to act, in real time, on multiple streams of event data flowing in from different parts of the enterprise. "The value of complex event processing, overall, can be summarized as improving situation awareness. Simply put, that is just knowing what is going on, so you can figure out what to do." The benefits of complex event processing, Schulte said, include better decision quality, faster response times, reduced information glut, and reduced costs.

Schulte defined a business event as a "meaningful change in a state that is something that is relevant to the business. Examples include depositing or withdrawing money from a bank, submitting a purchase order, or hiring an employee." There is also a second term, "event object," that describes how the event is packaged for processing, typically as an XML document these days. "We have to record events using event objects so computers can receive them and do computations on those events," Schulte said.

However, while all companies have always been event driven -- with millions, if not billions, of events in a single day, most events are still handled manually, by people, not computers. "At any one second, a large company has on its network anywhere from 10,000 to 10 billion business events," Schulte explained. "At the low end, that's almost a billion events per day -- at the high end, that’s almost a trillion events per day."

The challenge is that most of the stovepiped and legacy applications that power enterprises are not yet event driven, Schulte observes.

But there's great practicality in automating the ability to capture and make decisions on multiple event streams coming into the core business systems, Schulte says. "For example, you can have a complex event that says, ‘this mornings sales were 30% above our daily average.' That of course is much easier to digest and act on than sending a person 500 detailed sales records, and making the person compute what happened that day manually."

The growing array of sensors, such as RFID tags, combined with front-end systems such as business activity monitoring (BAM) dashboards make complex event processing a reality with today's technology, Schulte points out.

"In many cases, the complex event processing system Is just a front end being used for decision support. The output of the CEP engine is sent to a person through a BAM dashboard, or through an alert such as email or SMA or an Atom or RSS feed. in this case, we have a two-stage computation. In the first stage we’re using a computer to narrow down the data. And in the second stage, we still have a person involved to do the final analysis.

"An application system, or some other device or some other system, detects the event, and generates a message or a notification that is sent to a person. That notification is the event object or event report sent in the form of a message through message-oriented middleware, RSS, a Web service, or an email, or some other communication mechanism. The response to an event may be a manual activity, done by a person or it may be a SOA service or business process or some other application."

However, things could get interesting as CEP systems develop, Schulte added. Namely, the need for human processing could be taken out of the equation all together. "We can bypass that person entirely; we can build enough smarts into the complex event processing engine to determine the specific response that is needed."

Schulte provided a working example of complex event processing in action within the airline industry:

"In large airlines, there is an event oriented middleware that... acts as an enterprise nervous system. Information from hundreds of sources, including sensors on board the aircraft, information coming in from the FAA, and information coming in from standard systems is sent to the enterprise nervous system, and is temporarily stored in event databases. It helps to create the data, the outgoing alerts and notifications that is sent to hundreds of applications on the consuming side to respond to threat and opportunity situations as they emerge. By having information quickly, each of these systems in their respective departments can respond faster. ...Information helps the fueling and maintenance management applications to change their schedules and so forth. By using an event based system, the turnaround time of each plane can be shortened… Fewer airplanes are needed to handle the same schedule."

______________________________________________________________________

Posted by joemckendrick in Business Process Management • Data Management • Event Processing • Management • SOA • SOA Events • SOA Research and Analyst Reports  |  Permalink  | Comments (0)  | TrackBacks (0)

Oracle's Dave Chappell has always done a great job of linking SOA efforts to measurable business results, and he recently posted an account of a busy online service that was able to integrate its widespread base of customer systems into a well-integrated service layer.

Move Inc., a growing online real estate provider, had what Oracle's Dave deemed a "tall order:" consolidating disparate applications across two business units into an enterprise CRM solution that could provide a single, accurate view of customer data to improve efficiencies and automate auditing, billing and fulfillment processes.

Move Inc. (formerly Homestore, Inc.) provides information on real estate property listings (homes and apartments), moving, home and garden and home finance through its network of online sites, which includes www.realtor.com, www.welcomewagon.com, and www.moving.com.

Tall order indeed. As Dave describes it, Move had systems and touchpoints all over the map. CRM applications were built on .NET, and there were numerous disparate systems and manual touchpoints built to support various business functions for CRM.

The company developed a SOA that focused on re-usability of services, with business processes were at least as efficient if not better than what the current systems offered. Using standard WSDL interfaces, Oracle BPEL PM and Oracle ESB were used to extend the reach and normalize the integration across Siebel CRM, PeopleSoft Enterprise Financial Management and other systems both internal and external

The consolidated customer database is intended to provide support for existing sales activities, order capture, integration with fulfillment systems, integration of customer usage from Web sites into Siebel, and integration to PeopleSoft Billing. The solution involves the use of BPEL, Web services, ESB Mediation, application adapters, and canonical data models.

The project took six months to implement and deploy, Dave reports -- actually, pretty good timing for such an effort. Move was able to achieve both quicker and real-time integration across these systems, and saw a reduction in cost of ownership on existing applications.

"It's always great to hear about successful adoption of SOA, and its particularly exciting when its being used for what you'd think," Dave remarked.

______________________________________________________________________

Posted by joemckendrick in Case Study • Management • SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Everyone considers their systems to be "special" in many ways. They represent years of planning, installations, and modifications. However, sometimes "specialness" can get in the way of the ability to deliver agility and flexibility to business clients.

At the recent Tibco TUCON users' conference in San Francisco, Allstate's vice president of technical solutions, Anthony Abbatista, described how his company managed to automate most of its systems and processes in the 1960s and 1970s with what was in it's time a new generation of "special applications." Everything from policy administration to underwriting was captured on the company's array of mainframe computers.

Of course, application designers in these first waves of automation could never have imagined the uses that their systems would be getting nowadays. They never could have envisioned parts of these systems being opened up to the world via the Web.

These systems, Abbatista explained, were all hand-crafted and hand-coded. Commercial off-the-shelf applications just didn't exist in the 1960s and 1970s. However, the Allstate commitment to rolling its own applications continued right up to recent years. At Allstate everything was custom-built, "and we were proud of that," he said. "everything was very 'special,' with limited reuse."

Adding to the complexity and inflexibility, the company had a plethora of systems and vendors for the commercial solutions it did start buying. "Up until five years ago, we never met a software vendor we didn't like," Abbatista said.

The company, which now has $156 billion in assets and 17 million customers, always had plenty of resources for information technology. However, the company needed more responsive and agile IT solutions to succeed in an increasingly competitive environment for the insurance industry.

"When I first arrived at Allstate, we had three to five different integration platforms," Abbatista related. "We had an executive IT board that mirrored the military model, run by 'generals.' We had an abundance of point-to-point integration."

Allstate knew that it needed to embark on a more consolidated, service oriented architecture if its systems were to continue to deliver value.

Areas being modernized include claims processing, which was spread across nine different mainframe-based silos tied together by custom-built middleware. The company employed a standard enterprise service bus to handle claims processing through a single interface across the entire enterprise.

Another initiative was to establish a common integration layer for the company's fast-growing data environment. "Our data hubs are growing 30%-40% a year," Abbastista said. The company also pared down its vendor list to a "handful of strategic partners," numbering 12 to 15 vendors, he said.

Changing the organizational culture was another challenge, Abbatista remarked. "We had to make a substantial commitment to technology, skills, and also selling integrated teams that we had a better approach," he said. SOA governance was also tied to the operations of the procurement organization. This helped provide better visibility of available services, as well as increase reuse, he said. "How many error-logging services did we really need?" he asked.

______________________________________________________________________

Posted by joemckendrick in Case Study • Management • SOA • SOA Events  |  Permalink  | Comments (0)  | TrackBacks (0)

Does your SOA initiative remind you more of the gunslinging, saloon-brawling days of the Wild West than of the intrepid pioneers?

Don't feel bad -- most companies are still struggling to tame their Wild West SOA frontiers. The right approaches and solutions can help keep rogue services at bay, while delivering greater value from reusable assets.

I will be joining Christian Hastedt Marckwardt, solution marketing director with SAP, on Tuesday, April 29, at Noon Eastern Time in a special Webinar to discuss the results of a new ebizQ-SAP survey on SOA governance trends and practices.

The survey explored the depth of SOA and SOA governance at organizations. Be sure to join us for a compelling hour, as well as receive a complimentary copy of the complete survey results!

______________________________________________________________________

Posted by joemckendrick in Management • SOA • SOA Events • SOA Research and Analyst Reports • SOA Vendors  |  Permalink  | Comments (0)  | TrackBacks (0)

There's been quote a bit of discussion raging across the blogosphere as of late around the emerging concept of WOA, or Web Oriented Architecture, that may represent the the next phase of evolution of service oriented architecture.

Essentially, WOA is another way of describing the application of the Web 2.0-style technologies and methodologies, such as Ajax, REST, and Software as a Service, to enterprise requirements. Put another way, it's running an enterprise from the Cloud, versus onsite servers, hardware, and software.

Many observers are groaning at the introduction of yet another Three Letter Acronym to our already TLA-burdened lexicon. (See Mike Meehan's post here, and Dana Gardner's post here.) Apparently, many IT architects and practitioners are also rolling their eyes at this one.

However, the WOA phenomenon is something to pause and think about in terms of its long-term (and short-term, for that matter) implications for SOA.

Dion Hinchcliffe, the leading thinker in all things WOA, says that there's no reason why much of the internal enterprise functionality we look to in SOA can't be shifted to the Cloud. In fact, WOA leverages the World Wide Web, which Dion describes as “the largest SOA presently in existence.” The services that are built for WOA are built from lightweight Web 2.0 standards and methodologies, especially REST and enterprise mashups. He also describes enterprise-based SOA as “local networks.”

Dion notes that “both approaches leverage HTTP, self-describing data formats such as XML, are concerned about the use of open standards, and can be used to build systems of arbitrary complexity.” However, while SOAs “tend to have a small and well-defined set of endpoints through which many types of data and data instances can pass, WOAs tend to have a very large and open-ended number of endpoints; one for each individual resource. Not an endpoint for each type of resource, but a URI-identified endpoint for each and every resource instance.”

He also observes that while “SOA was designed from the top-down by vendors to be tool friendly, WOA was emerged form the bottom up from the Web naturally, and has the best support in simple procedural code and an XML parser.” Plus, very importantly, while “traditional SOA is fairly cumbersome to consume in the browser and in mashups, WOA is extremely easy to consume just about anywhere.”

In a recent email exchange with a group of us analysts who have been debating the merits of creating another TLA, Dion defended the WOA designation, noting that it needs to be set apart from standard SOA approaches:

"WOA simply reflects the set of emergent network and application architectures that are working today on a large scale on the Web, getting results for a great many organizations by using slightly different techniques and a fairly different mindset than we've used in SOA. This has become increasingly evident in the many WOA success stories over the last half decade that are producing pretty darn dramatic ROI numbers for many businesses large and small (happy to share these)."

SOA as we've known it has just been too cumbersome and complicated, Dion said. "I spent five years building SOAs from 2001-2006 and have been appalled at the cost/benefit ratio."

He notes that the simpler, more rapidly deployable model that WOA offers an incomparable value proposition to slowa-SOA. "Global SOA on the Internet is producing impressive results today with WOA techniques and a quick survey of Programmable Web's hundreds of WOA-style APIs or WidgetBox/Google Gadgets can demonstrate it has already greatly surpassed our traditional SOA models in terms of industry adoption, at least on the biggest network there is. It's the local SOAs in our enterprises that are the ones having the problems."

_____________________________________________________________________

Posted by joemckendrick in Enterprise 2.0 • SOA • Software as a Service  |  Permalink  | Comments (0)  | TrackBacks (0)

Talk about legacy. Up until recently, both Lufthansa and United Airlines were using a 40-year old reservation system, written in Assembly language.

Esther Schnidler, writing in CIO, describes how the airline migrated its green-screen-based system, which couldn't integrate with other systems and services.

Migrating the system to SOA, which covers the product suite for reservations, inventory and passenger check-in, is equivalent to a "heart transplant," said Shama Patel, business program manager of the SOA effort for United and Lufthansa, called Horizon Project.

The key to the project's success is good governance, Patel said. Along with a governance board supported by both airlines, a "Guidance Coalition" which brings IT and business employees together to interact and work on project milestones together. United also created a job title of "business engagement manager" to act as a point of contact between the IT project and the division.

Eventually, Lufthansa and United plan to roll out a common platform that can also be used by other members of the Star Alliance. "The modernization project will impact 20,000 people in 350 locations in a three- to four-year time frame, and it will touch 20 company divisions."

____________________________________________________________________

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

There's been quite a bit of debate in the industry about whether SOA can deliver reasonable ROI within a reasonable timeframe. The consensus has been that it's going to take time, even years, for the benefits of SOA to take effect.

However, there are exceptions to every piece of accepted conventional wisdom. In the case of mergers and acquisitions, the payback from service-oriented architecture sometimes can be seen in a matter of months.

Tony Baer, who also an ebizQ contributor, has just posted this account at Manufacturing Business Technology, describing how a recent acquisition doubled Mohawk Fine Papers' manufacturing network doubled to six sites, and distribution network quadrupled to four warehouses.

From past experience, Mohawk's IT team knew how painful custom development and integration could be. As Paul Stamas, Mohawk's VP of IT, told Tony: "The biggest problem was managing all the interfaces. The failures in the previous integration were point-to-point connections that nobody owned." So Mohawk took a new tact -- SOA.

The company integrated its existing BPCS enterprise system with the Infor ShipLogix transportation management solution deployed recently to replace an older Logility application. And with a much larger production network, Mohawk also sought to tie BPCS into its Infor Datastream enterprise asset management system. (Note: BPCS was created and marketed by SSA Global, which was purchased by Infor in 2006. But just because a vendor is acquired doesn't make it any easier for a company to integrate the separate products.)

_____________________________________________________________________

Posted by joemckendrick in Case Study • Management • SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Dave Rosenberg, CEO of MuleSource, works with a lot of organizations that are starting their SOA journeys, and noticed that many make the same mistake: they spend all their time worry about the technical details of their implementations, but don't pay enough attention to governance.

In a new post here at ebizQ, Dave outlined what he sees as the five greatest mistakes in SOA governance:

1-Decentralizing common artifacts: "When common artifacts such as WSDLs, schemas or configs are scattered in various locations, organizations waste time searching for interfaces and schemas," Dave says. "This is because they lack a central authority for the published service interface, which discourages discovery and reuse across an enterprise."

2-Reinventing the wheel: Perhaps the biggest problem SOA was meant to correct. "Services and applications are often written again and again to perform the same function," Dave says. "As a result, many different versions of the same artifact are built and integrated, increasing development times and creating a huge maintenance cost burden." The solution is a centralized repository or registry available to the enterprise.

3-Hoping for best practices: "Developers may not inherently know best practices, and even if they do, they may not follow them every time," Dave says. Best practices can and should be enforced as enterprise-wide policies, anywhere from the build to the registry to people and processes.

4-Forgetting about service consumers: It is important to continuously be aware of how a service is being used by the final consumer at the end of the process, Dave says. He recommends adopting tools that track dependency management.

5-Inconsistent application deployment strategy: "Many application deployment strategies are ad-hoc, not well documented, and only understood by one person," Dave says. A registry and repository can help automate developer actions, and thus ensure consistency.

How far along are most organizations with their SOA governance? ebizQ recently conducted a survey on SOA governance trends, and I will be joining Christian Hastedt Marckwardt, solution marketing director with SAP, on Tuesday, April 29, at Noon Eastern Time in a special Webinar to discuss the survey results and implications. Be sure to join us for a compelling hour, as well as receive a complimentary copy of the complete survey results!

______________________________________________________________________

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

According to a report in ComputerWeekly, consumer goods company Proctor & Gamble is working on an ambitious service oriented architecture that will provide aggregated data for the company's 32,000 managers.

To accomplish this, the company will be re-using up to half of its internally developed code across the organization, which will be made available as shared services across the enterprise.

The company has already rolled out SOA to 2,000 users, helping to achieve up to 25% of reuse, Terry McFadden, associate director for enterprise architecture at P&G.

_____________________________________________________________________

Posted by joemckendrick in Case Study • Management • SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

There's been a lot of debate and discussion across the industry as to whether SOA can deliver value to the business early on, or if its more of a long-term process.

For one company working with SOA methodologies for the past 10 years, there clearly has been a long-term benefit, in terms of economies of scale. The earliest services may have not been more cost effective than standard applications, but as SOA and reuse grew, these services grew cheaper and cheaper to use and administer.

Then again, a $5 billion logistics and trucking company ought to know plenty about economies of scale. It may cost $1,000 to ship one refrigerator from New York to Los Angeles, but cost a penny if it's intelligently bundled with another shipment. Why not apply this know-how to its information technology infrastructure?

One of the best and earliest examples of heavy-duty implementations of Web services and SOA is Con-Way Inc., a logistics and trucking company. I first spoke with them and documented their efforts back in late 2004. At the time, Con-Way had already been evolving an SOA infrastructure for several years, enabling its seven separate business units to share standardized customer-facing applications. At that time, Con-Way had about 20 coarse-grain business components, such as a shipment component, purchasing component, and customer component.

SearchSOA's Rich Seeley just spoke with the folks at Con-Way, and, needless to say, the company has come a long way since 2004. For one, revenues at the freight transportation company were only making a measly $2 billion when I last spoke with them.

Shibashis Mukherjee, Con-Way lead enterprise architect, told Rich how things came about, dating back to the 1990s, when the company embarked on a component-based methodology to expose COBOL mainframe applications as services. The company began building various Web services earlier this decade.

Con-Way set out not knowing how much services would be reused -- but this was very much their design goal. . "When we built services at that point in time, we built every piece of functionality as a reusable piece of code," Mukherjee said. "We had no idea whether it was going to be reused or not." However, reuse across the company's various business lines took off.

The result was a multiplier effect as SOA gradually took hold in the corporate culture. "It took a couple of projects to see all the benefits," Mukherjee said. "You don't generally see the benefits in the first project you do. We also had executive management buy-in and we had a long-term vision. So as project after project is done, our development time was cut as we reused components built by the previous projects."

______________________________________________________________________

Posted by joemckendrick in Case Study • Management • SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Business-IT alignment... Has a day gone by over the past ten years that we have not heard that phrase?

While it seems to be a constant but elusive dream -- like peace on Earth -- some companies indicate that SOA may be moving them closer to reality.

Fellow ebizQ colleague James Taylor, out at the IBM Impact confab this week, provides an account of an end-user customer panel on the ever-vexing challenge of business-IT alignment. Is service-oriented architecture helping to bring about some of this alignment?

A panel of corporate practitioners talked about their SOA efforts, and the impact SOA was having on alignment -- a positive impact, by the way. James reports that Randy Wallace from Michelin said one of his company's biggest challenges is "B2B with lots of billers to interface directly in their order management systems so, for instance, allow dealers to integrate orders with Michelin. They are currently evolving their order-to-cash system using Process Server and SOA."

Who much alignment has Michelin seen? According to Wallace, the company has come a long way, "from having a very small percentage of IT spend aligned with key business goals (6%) to one that is much more so (81%)."

That's pretty impressive. Wallace cited some examples: "For instance, in the past business units in different regions picked i2 and Manugistics at the same time and both were implemented resulting in separate systems. A stronger governance process and overall architecture are now established, driven by business ambitions and regularly updated. Far fewer and more focused projects as a result. Senior executive user satisfaction has risen steadily."

Austin Waldron from Health Care Services Corporation (HCSC) said his company's "focus is on using SOA in legacy modernization where many disparate systems are being replaced by a unified set of shared services. The governance issues seem to have been key for HCSC."

Waldron also talked about moving closer to business-IT alignment. "They had some years of IT spend focused more on basic IT infrastructure (security, robustness etc) but now investments much more driven by the business strategy."

Another panalist talked about more alignment at the front lines of the business. Jeff Auker from The Hartford "talked about challenge of consumer front-ends. Consumers working directly with The Hartford now expect a much more interactive online experience for sales and service - this is being driven by GEICO and Progressive’s campaigns. SOA is key because they have some front-ends that are tightly integrated with very old back-ends and SOA let’s them decouple them."

Thanks again to James Taylor for this report .

______________________________________________________________________

Posted by joemckendrick in Business Process Management • Case Study • Management • SOA • SOA Events • SOA Vendors  |  Permalink  | Comments (0)  | TrackBacks (0)

I recently had the opportunity to host an ebizQ Webinar on managing SOA performance with Forrester's Randy Heffner and AmberPoint's Ed Horst.

SOA has a lot of moving parts, and digging down to spot the root cause of a service problem is not always easy. SOAs are multilayered creatures. Is it the service itself that's creating an issue? Is it the database? Is it one of the servers?

As Randy put it:

"We’re talking about managing complex SOA services. So we’re diving into an advanced topic that comes up as you realize how deep your service implementations can go, and as you realize some of the dependencies that happen between the various components behind the implementation of your service. Your SOA management solution however you construct it and buy it must handle SOA-based service requests that have complex service implementations."

Randy says when troubles arise with services in SOA, it's often a challenge to pinpoint the source of the troubles, and a number of teams may get involved in the process of identifying issues -- and not have the big picture. Now, Heffner says, "great, we’ve identified there’s a problem with a service, who we going to call?" With complex SOA implementation, and multiple teams, the only answer that will be coming from everyone within their respective teams saying, "it's not me -- my stuff is working fine." That's because everyone has a view limited to their piece of the infrastructure, Randy says.

SOA management tools need to address "deep service" management, Randy pointed out. SOA management tools all do a fairly good job of altering administrators to problems with a service. Even in a complex service implementation -- it could be Java, .NET, messaging middleware, or legacy connectors -- when trouble is afoot, a good management tool will do a good job of sending an alert out.

Randy urges configuring SOA management strategies and solutions to conduct "deep service management." Typically, SOA management solutions employ solutions that don't look beyond the SOAP interface. A new generation of tools that are emerging, however, that can look beyond the service interface to the databases, services, and messaging layers beneath.

SOA management should be able to handle a variety of SOA deployments, ranging from services that invoke Java Message Service, MSMQ, Java RMKI, or CORBA, to ESBs or app servers. Many deep service SOA management approaches can start with agents that many SOA management solutions provides, Heffner said. Then, there are also an increasing number of management solutions that run natively on various platforms.

They key is to employ these solutions -- with or without agents -- to gain better visibility into the systems behind the services, he said. "SOA management solutions may have various ways to construct or correlate a picture, such as dropping tags into a message... or, you might have to do a little work in the configuration..." As services arise, problems will be better isolated, and administrators will know which team to call for assistance. Such deep service management also delivers benefits beyond root cause analysis, such as capacity management.

Randy makes the following recommendations for achieving deep service management:

"Formulate your SOA management strategies; how you’re going to do successful SOA management before you start thinking about products to do SOA management.... You have to deeply know the technologies, know how complex your implementations are. Will your SOA solutions will be able to help you manage your services across the technologies? Will your SOA management solution be able to tie together the complexity and correlate the complexity?

"...Build deep SOA monitoring and management into your whole overall SOA management. It has to do with t