SOA in Action

Does the road to SOA lead through BPM [business process management]?

Yes, says Kaushal Mashruwala, writing in Financial Express.

Kaushal relates a recent Forrester Research Survey that found 38% of companies with more than 1,000 employees are not using SOA and have no plans to do so. Of the companies that are using SOA in some form or fashion, 40% haven’t begun or are using SOA with no clear strategy in place. "The 80/20 rules seem to imply that 80% of people don’t and won’t get SOA in the organization," he says.

The bottom line is that business leaders don't really care about SOA all that much, but do care very much about BPM. So, if you're an SOA advocate, why not give them what they want?

BPM, when fused with SOA, give business managers more power to change, through technology, the way their businesses are run, Kaushal observes. “The management philosophy of BPM empowers business people to think about the processes that affect their day-to-day lives and operations. It gives them a new role in defining requirements, on their terms, and creates a common language for business and IT to address real implementation level concerns. This role of BPM as the business face of SOA is not just a possibility. It’s happening now.”

_____________________________________________

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

Data, you may not realize it sometimes, but we do it all for you. Honest.

In a new posting here at ebizQ, Oracle's Jeff Pollack says the time has come to bring business intelligence, data warehousing, and master data management (MDM) into the SOA house. Or bring SOA into their houses.

Jeff, an executive on the Fusion side of Oracle, and author of the enterprise software book "Adaptive Information“ (John Wiley & Sons), points out that vendors, analysts and enterprises alike often get caught up in the software side of things for too long. "In the past 15 years, with the rise of Java, the hype surrounding EII, EAI and SOA, and the rise of XML, and quietly, the billions spent in ETL projects -- it's too easy to forget why we build and buy all that infrastructure. We do it for the data."

The problem is, many SOA projects may not be ready to handle all the data corporations are churning out these days. Most, if not all, operate within a Java Virtual Machine container and can't effectively handle large data loads. Plus, XML can be a cumbersome markup language for data.

Thus, data managers keep relying on their relational databases to do what needs to be done. As Jeff puts it: "Most new XML-centric solutions for data can't scale to the mult-terabyte sized problem that is typical of a Global 2000 business. Thus, a knowledgeable architect will revert to the proven patterns of RDBMS as the backbone of a data architecture using MQ, TPS, and ETL interfaces as the pipes for pushing all that data around."

That's the challenge going forward, Jeff says. SOA still suffers from "poor bulk data transformation performance and inefficiency."

To address this problem, Jeff recommends the creation of "SOA Data Services," which are decoupled endpoints that expose components for working on all types of data. Interestingly, he points out, such services can be created without SOA, and such services have been around for years now, in EDI and Java applications.

Start simple, Jeff advises. A Data Service could simply be a "boring Web Service with simple data actions, or thin SOA façades for wrapping conventional data technology." And remember, it isn;t just about XML. Data Services created these days should encompass different data delivery patterns and formats, Jeff says, noting that "SOA pundits often assume that XML is the only desirable delivery format, but for a data solution to be truly useful for the enterprise, it must support several different delivery styles."

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

SOA makes us more agile, BPM makes us consistent. That's a combination explored in some depth by Gartner analyst Daryl Plummer at this year's DIALOG 08 event.

ebizQ colleague James Taylor is blogging live from DIALOG 08, and provides a thorough report on Daryl's presentation. Daryl spoke of the rise of "Dynamic BPM," which is the intersection between business process management and service-oriented architecture. As James relates, Daryl pointed out that "Dynamic BPM is becoming a requirement, not an option, as the frequency of change is increasing while the amount of change (the amplitude) is also increasing."

Companies that don't start marshaling their BPM and SOA resources in an integrated fashion risk increased costs and diminished opportunities, Daryl said: "If we don’t keep up we get lots of chaos, more expensive governance as we react, business agility becomes harder and decision making becomes increasingly 'seat of the pants.'"

The movement away from distributed systems or silos make business agility more of a possibility. As James quoted Daryl: "The growth of standards and frameworks, middleware and more has made it easier and provided a better platform. Adding event-processing, ESB and SOA meant that BPM could really deliver."

I like Daryl's ultimate definition of a service: "Something which does something for me without me having to do it or know how it was done - I ask, it does, it tells me its done."

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

More evidence that SOA implementations are moving closer to an enterprise data management role: The Stanwell Corporation recently began a project intended to integrate and provide quick access to data currently stored in siloed IT systems.

In a new ComputerWorld interview, Stanwell enterprise technology architect Greg Behrendt said the new platform will synchronize data from numerous sources throughout the enterprise and transform it into real-time information. "We will have access to information we can act upon and update straight away; this will save us time and money by streamlining business processes and accessing information from one location," he is quoted as saying. Stanwell turned to BEA's AquaLogic Enterprise Service Bus and data services platform to undertake the project.

Perhaps the Stanwell and BEA folks read ebizQ's own David Kelly a few months back, when he so succinctly made the SOA-data connection a few months back, observing that "any organization considering or pursuing SOA should also be creating a data services strategy....Simply put, putting together the right data services are an important strategic investment for organizations pursuing SOA."

While data warehouses and data marts are intended to accomplish this de-silozation of information, they need middleware support to effectively disperse the data to the right parts of the business through the right applications. "There's an ever-growing need for delivering data, especially from multiple, disjointed sources, in real-time," David explained. Thus, data needs to be moved closer to the applications, and applications need to be moved closer to the data, and somewhere in the middle they meet. What a killer role for SOA.

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

Oracle's Dave Chappell writes about a new paradigm sweeping the financial services world, extreme transaction processing (XTP). The good news that used in conjunction with SOA, XTP offers power to applications such as fraud detection, trade resolution, and risk management calculations, running off of low-cost commodity hardware, versus the premium servers required for these applications in days gone by.

"We're seeing that SOA coupled with XTP (eXtreme Transaction Processing) is the future for financial services infrastructure," Dave says. XTP enables certain applications to process large amounts of data/

What is the connection between XTP and Complex Event Processing (CEP)? They are both "positioned to solve some of the same thorny problems of tracking business exceptions such as what is required for fraud detection," Dave says. XTP is tied to CEP "in that they are both about consuming and correlating large amounts of event data and doing something meaningful with it." However, traditional systems relying on CEP may not have the storage management capacity needed to handle large amounts of data.

"Tie-ins to SOA are many, but the most obvious one is that once the exceptions are detected, there are actions to be taken," he explains. "Typical actions to be taken are to send alerts to a BAM dashboard and to invoke a business process or human workflow, such as what can be defined and executed using the Oracle BPEL process manager."

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

At Delta Airlines, SOA is cutting the cost of ownership by half for its various applications and systems. That's good news, of course, but the company's experience with proactive governance also provides some valuable pointers for other companies wrestling with the politics of SOA.

Delta's SOA has been under development for more than 10 years and is now its third phase, says Bret Martin, principal enterprise architecture for Delta Technology Inc., a wholly owned subsidiary of Delta Airlines.

In a session (registration required) at a recent online conference put on by Tibco, Martin said that phase one of what the airline calls its "Digital Nervous System," or DNS, commenced with proprietary and home-grown integration hooks in 1996. As SOA and Web services evolved earlier this decade, Delta focused on bringing DNS in line with industry standards such as SOAP over HTTP, delivered through an enterprise service bus at the back end.

Now, in the latest phase of the effort, the goal is to see that "SOA is infused with the enterprise," Martin related. "SOA is a way of life for implementing business applications across the enterprise."

The greatest value Delta is seeing from SOA is reuse of IT assets and data, Martin pointed out. "Reuse is one of the big drivers for our SOA environment," he said. Delta's SOA, for example, is reusing the same customer and operational data across a range of systems, from the Delta.com Website to ticketing kiosks to ticketing counters and gate systems. "It allows check-in to happen in a uniform way," he explained. Another way services are being leveraged are by exposing services to vendors and partners, such as American Express or operations companies.

Delta engaged a cross-enterprise governance team to perform all the tasks that are expected from an SOA governance group: managing registry and repository in making sure that services are registered, defining the policies that are going to go into the deployment of a service, defining security, defining service-level agreements.

However, Delta recognized the value that the governance team was bringing beyond merely approving, registering, and managing services, Martin says. "Its not only registering services, but also trying to promote services that we already have defined, and have already put into production." This is essential, he said, because developers and architects aren't necessarily aware of what services are available out there, or where they can be found.

"What we needed is a governance organization that says they can help, 'here is a SOA business process, and is is how it can be implemented," says Martin. "Having a group that stands in front of those services, and matches business requirements to the services that we have… is a huge benefit."

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

In his latest post, ebizQ analyst Peter Schooff spoke with Anne Thomas Manes about the insecurity that continues to nag at SOA. (Transcript and podcast link here.)

This is an issue that's not getting near enough attention, Anne points out. Ironically, securing SOA is not a big deal, as it employs the same mechanisms used to secure Web services and Websites. Actually, Anne pointed out, "at this point, I think it’s really easy to secure your environment. You just have to use different practices than what you would probably do just for your Websites... Any platform that support Web services has the ability to support WS-Security."

And, as with Web services and Websites, applications or systems may be vulnerable to outside intrusions. "With services, you’re exposing business processes within your organization," Anne says. "If you don’t properly secure those interfaces to those business processes, you’re now letting anybody in the world come in and access them." Too many companies think that having those services contained within a well-protected firewall will do the trick. But, as she points out, these are intended to only protect point-to-point connections.

"If there is a URL that provides access to a service, chances are somebody’s going to be able to connect into it," Anne cautioned. "And the -- the idea that your perimeter is actually going to protect your internal systems is pretty dangerous at this point."

What to do? The best practice for SOA security is to enable security to be applied uniformly and automatically across all services deployed or run within the SOA, versus trying to build in security for each separate service.

Anne said that a layered defense will better protect SOA-based transactions and underlying data. "Use a combination of security protections when you’re dealing with a service-oriented system," she said. "You use the traditional periphery type of security measures, you also use identity-based security measures at the endpoints, and then potentially you use additional intermediaries to perform additional security capabilities like auditing, or cross domain, credential mapping and things like that."

Plus, she said, look into technologies from XML gateway vendors or from Web services management vendors "which will automatically protect your services for you, and automatically configure the kind of management and security protections that you want, such that you don’t have to do a whole bunch of effort every single time you deploy a service."

Emerging approaches also include new OASIS specifications such as WS-Federation, and “WS-Secure Conversation” that "gives you an additional layer of security by enabling two communicating service endpoints to establish a secure connection... a more efficient way of establishing a secure conversation so that you don’t have to authenticate on each interaction."

In a Webinar I moderated last fall, Anne also raised another important point that needs to be addressed better by enterprises: that all too often, the burden of security is left on the shoulders of IT or integration teams, and therefore not getting the holistic view required to be effective. SOA brings this issue even more to the fore, since the goal is to provide service-enablement across the enterprise, well beyond the walls of IT.

You can get answers to your specific SOA Security questions from four of the top experts in distributed-computing security at this Webinar. Join Fred Etemadieh, co-chair of The Open Group's SOA and Security Project, Gunnar Peterson of Arctec, Andrew Brown of AmberPoint and moderator Mike Rothman of Security Incite on Wednesday, February 27, 12:00 p.m. ET for the special Roundtable that will key on the to discuss the most effective initial precautions (including using existing identity and access management) systems and long-terms strategies to keep your SOAs safe.

Find out more, submit a question or register here.

Check out submitted questions that will be covered here.

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

How secure is SOA? Security has long been considered the Achilles Heel of both Web services and SOA, since both mission-critical applications and data are being opened up to the cloud.

Surveys I have worked on for Evans Data over the past several years find Web services and SOA developers overwhelmingly rely on Secure Sockets Layer (SSL) for their security needs. This is not enough, of course -- a holistic approach is required, that not only encompasses service and application security, but also a layered approach involving network security, OS security, and physical security of the facilities where apps are run and data is stored.

In a couple of weeks, Mike Rothman, President and Principal Analyst, Security Incite will be joining Gunnar Peterson, Managing Principal, Arctec Group for a discussion on the state of security in SOA. The session promises to be an eye-opener, with a frank discussion on new attack vectors introduced by SOA, the best places to implement SOA security, and identity and access management options.

In the meantime, ebizQ's Peter Schooff provides some good pointers for better securing SOA in his latest post.

Don't assume that your vendor "is taking care of" security. It's up to you to protect you're own company's assets -- your vendor's not going to care.

Security is not one-dimensional. Don't assume that "because your firewall is up and functioning doesn't mean your secure," Peter cautions. "With SOA, security is much more than just perimeter and means working security in during the design and implementation phase."

Don't rely on a cursory risk assessment. Resources are limited, and a company is likely to let some things lapse while attending to more "pressing" issues. Peter gives the example of a company that rationalizes that an unpatched router is a greater threat than flaws in its SOA framework.

Don't rely too much on security standards or security features. Standards such as SSL, S/MIME, and WS-Security are helpful, but don't fully secure the system, Peter cautions.

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

You ever hear about the "rent-a-patient" scheme hatched by a pair of unscrupulous doctors in the LA area? In this incredible-but-true scheme, the doctors performed unnecessary surgery on patients that were recruited by marketers with promises of cash or discounted cosmetic surgery procedures.

Patients were instructed by recruiters to describe false and exaggerated symptoms that were used to create medical charts used to make the surgical procedures appear to be justified. The doctors reportedly racked up claims totaling more than $2 million before being caught. Procedures performed on the otherwise normally healthy patients included colonoscopy, sinus surgeries and thoracic sympathectomy, commonly called "sweaty palm surgery."

Claims fraud gives many insurance carriers sweaty palms, as I documented in this recent article in Insurance Networking News. The good news is that technology -- in the form of analytics -- is providing carriers the tools to rapidly sift through claims data to connect the dots on suspicious activities. Time is of the essence -- claims must be paid within a certain period of time, and once the check is cut and mailed, it's difficult to get the money back.

Here's a role SOA can play as well. Sandy Carter, VP with IBM, just published details in CIO about how SOA is enabling MIB, the industry's largest fraud detection service that is used by nearly every North American life and health insurance carrier, to spot fraudulent activity.

Sandy relates that MIB, which has 500 members, can sift through files from a range of systems to help detect potential fraud among new applicants to insurance policies. MIB's systems can access the applicant's insurance and medical history; the proximity of marriage, establishment of a life insurance policy and a spouse's untimely death, and the frequency of auto accidents resulting in medical claims.

MIB is also employing SOA to "help build an online community among credit reporting agencies, healthcare and insurance providers, and government agencies by extracting the information that’s trapped in various software applications that are located inside and outside a company and bringing it together under one roof in a faster, more secure and economical way. This information helps create an accurate and comprehensive credit history profile while also adhering to industry regulations."

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

Eric Roch points out that many of the issues that dogged enterprise application integration (EAI) may be getting addressed by SOA. However, some of the problems also have the same ring.

Some of the issues in SOA that echo the bad old days of EAI include constant change and a lack of experts with SOA, immature standards, and problems with legacy systems connections.

The SOA software suite is more complex than the EAI stack because we just keep adding to the stack without taking anything away. You could argue that there are more patterns and standards for interfaces but if you are using SOA for integration there is still an art to connecting the legacy systems. The rest of the EAI problems are more process related and can certainly be an issue for SOA projects.

EAI's track record is mixed at best, Eric states, for example, that in 2003 it was reported that 70% of all EAI projects fail. "Most of these failures are not due to the software itself or technical difficulties, but due to management issues," he says. Management issues are definitely the greatest challenge with SOA as well.

Eric points out that conditions are improved with SOA, however: "The good news is there are more patterns, methodologies, governance frameworks and experience for SOA than there was for EAI in 2003."

Eric also cites examples of SOA patterns, such as IBM’s SOMA and the OASIS SOA Adoption Blueprints. "We have improvements in tools, best practices and methods."

Let me add that another advantage is that connecting SOA interfaces don't necessarily demand armies of consultants as EAI did.

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

You may have seen the amazing high-tech tools that the crews in the CSI crime series use to track identities and spot forensic evidence. In fact, the technology delivers a little too quickly and efficiently in TVland. But perhaps there is some service oriented architecture behind the scenes. It's definitely becoming the case in real-life police work.

ComputerWeekly reports that a UK-based police department is employing SOA to enable remote access to applications via a common, standardized interface.

The Wiltshire Police department commissioned a major redesign of its systems so officers and managers can use an SOA-based system as an interface to a dozen applications. Matt Bennion-Pedley, Wiltshire's financial director, said that the SOA ensures security, continuity and resilience against technology changes: "It insulates the applications themselves, making it easier to develop interfaces for new terminals and applications."

The SOA enables better access from mobile clients, and will provide access to administrative and investigative tools such as intelligence systems, the Police National Database, vehicle and criminal records, and photo files. There are also plans to enable DNA file access.

And hey, let's be careful out there.

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

One of the coolest aspects of SOA is that it is oblivious to any of the platforms underneath that support it. That means even the oldest and most rigid mainframe systems can be re-energized (or modernized, as IBM likes to call it) to handle a new generation of applications and end-user demands.

As part of my ongoing work with Unisphere Research, I published a survey of SOA deployments and plans at mainframe sites, conducted in cooperation with SHARE, the IBM mainframe and large systems user group.

In our survey of 430 SHARE members (link to PDF download of executive summary), we found that many mainframe systems are at the center of efforts to extend applications into SOAs.

The SHARE survey found companies are still in the early stages of expanding the capacity of their current mainframe systems to support SOA. Close to one out of four respondents' companies have SOA efforts now in progress, and another one-third are planning or considering SOA. At least half of those engaged in or planning SOA say they are or will employ mainframes in a central role.There's still a lot of work that needs to be done, of course. Fewer than one out of ten could say that an appreciable amount of their SOA-based services are shared across two or more business units.

There are some great case studies out there on SOAs built on top of mainframes, and here's one story of Mainframe SOA in Action: According to an new report in SearchSOA, the Ohio Bureau of Worker's Compensation has moved its mainframe-based operations to a service-oriented architecture. Most new development occurs in .NET, but, as the report notes, " most of the data relating to more than $19 billion in assets is in mainframe IBM DB2 databases interacting with COBOL applications and using CICS."

BWC used the CA Gen tool to deliver more than 100 reusable mainframe services, consisting of CICS transactions.

Such data is consumed by the .NET applications that update the status of workers' compensation policies and claims for employers and workers accessing the information via standard Web browsers. Some large datasets will have to be eventually be moved off the mainframe environment, since CICS COBOL has 32k-data limits of how much data can be passed through the system, a challenge that was overcome by enabling applications to make multiple passes through the CICS servers.

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