Some interesting highlights from the second SOA Executive Forum, Tuesday May 17 in New York…the ZDNet summary is here.
Kevin McKean, InfoWorld CEO and Editorial Director, kicked things off with an informal audience survey. From the 100 or so in the room it appears that:
- Today there are more demands than ever on IT
- With fewer resources to apply
- More requirememnts to interface with partners externally
- Constantly changing business processes
SOA is growing in popularity precisely because it addresses these and other issues. In fact, the speaker following McKean (Dr. Halamka) delivered a strong validation.
Among the reasons are that SOA:
- Is platform independent – embracing the natural heterogeneity and complexity in IT systems both internal and at partner sites
- Produces reusable (and sharable) components
- Extracts qualities of service from code
- Creates and updates applications dynamically
McKean used the assembly line analogy, something we’ve been talking about for at least a decade, but until SOA based on Web services came along it has always seemed just out of reach.
In all of this service enablement is key – a kind of prerequisite to achieving the potential value of an SOA based on existing, heterogenous systems — either within a single IT environment or across IT environments. That’s why we focus on this key aspect of SOA with our ESB product, Artix.
Following McKean, Dr. John Halamka, CIO at Harvard Medical School and Caregroup Medical Systems gave the opening keynote, illustrating through his experience that the benefits of SOA and Web services are real.
Dr. Halamka said he’s created a kind of “Napster” for health care, reducing processing costs dramatically and at the same time improving the quality of care. His results to date are so significant, he said, that Senator Kennedy and Governer Romney have brought the message to Washington that SOA is the only way to contain spiraling health care costs. (Imagine government-mandated SOA if you dare.)
He said that the big challenge is accessing data that is scattered to the winds. They need strong security, especially around controlling access to sensitive medical data. They have an environment of large heterogeneity at the technology level, with lots of constituents and need to share data across departmental, organizational, and governmental boundaries.
SOA is the answer, providing a federated approach to data access instead of centralized databases, which haven’t really worked out. He’s been busy building what he calls a trusted, interoperable network for healthcare transactions across large parts of the state of Massachussets. Both within and outside of the network. They have implemented some security themselves, partly because they started before WS-Security was available. (Somehow it seems like SOA is a kind of retro-fitted name for what they were doing, but anyway…it is certainly Web services/service oriented.)
Big issues for him include:
- Lack of harmony across standards, therefore the need for implementation guides
- Need to establish policies and policy management around exchange of data (including auditing, compliance, enabling foreign originated transactions to complete successfully) while respecting daa consent laws
- Finding the right incentives to improve care
But he did say that they have been able to significantly improve quality of care and reduce cost of care using an SOA approach.
They basically use a commodity PC based gateway with a list of all Web services available to the requester, and invokes the Web service at the provider to get the data — thus the Napster P2P reference.
They could not afford to rip ‘n’ replace. Leave the legacies in place, he advises, and wrap them with Web services to connect the various systems. They have to deal with mainframes, MUMPS systems C++, etc. and it all works with Web services. No matter who you’re doing business with, he said, the API is always the same.
The clinical side is more difficult than the business side, he said. The solution there is essentially a network of networks (like the Internet), a federated model, not a single network. He intends to build up to a nationwide SOA for healthcare.
It’s a cost and quality of care issue to exchange data, current system is like an ATM card that works only in your own home bank branch. A CAT scan at one hospital isn’t available at another hospital, even one just down the street.
Each year 86K accidental deaths occur, it’s like a 747 crashing every day. Would you fly? he asked. The flow of data (i.e in this case medical records, needs to be improved so that doctors wherever you happen to be have access – this by the way was one of the original “dreams” of a service enabled world presented in slick video format at the UDDI kickoff hosted by Microsoft in October, 2000.)
Also we don’t need a national health ID for this, he said, as some have proposed. The federated SOA he has in mind creates a kind of DNS for people, i.e. a registry of healthcare IDs that you can access as a service over the Internet to map people to their IDs. In MA they have 500K patients in the directory already, by the end of the year it will handle all of MA.
The starting point was cost avoidance. It cost $5 a transaction to process an insurance request before, the SOA reduces it to 25 cents. Hospitals are going out of business because it’s too expensive to say in business, and have to deal with increasing regulatory control.
On the clinical side the starting point is better medical record sharing to improve care and avoid accidents.
SOA in action, some place where it really matters.
Otherwise, we heard:
- Automate business processes to eliminate manual labor and redeploy staff (one of the motivations for investing in service enablement etc.)
- Bigger returns on investment happen over time, as the “network effect” starts to take hold (i.e. achiving a critical mass of reusable, sharable services)
- CEOs are starting to mandate SOA, they want dashboard information etc.
- CEO/CIOs therefore may have a different view of how well and thoroughly SOA is adopted compared to developers (an InforWorld/BEA survey indicated as much)
- A fine line exists between maintaining creativity and control in the development environment
- Developers need to shift their focus from developing applications to providing and consuming services
- Some view BPEL as a centralized point of control; others argue even BPEL engines need to be federated
- You may have to be willing to “give up control” over what happens at the endpoints, especially when consuming a service provided by someone else
With all of this validation of SOA and its importance to IT and business, us vendors on the “Defining the SOA Platform” panel discussion did our best to describe the respective values of our various ESB products. All of us agree that Web services standards are core to the ESB, while others of us debate whether or not an ESB is a new product (developed from scratch to serve as SOA infrastructure) or an old product retooled.
Much of the debate often boils down to how best to use the tools, but new tools are also necessary to support the new paradigm. We are now living in a multi-technology world. ESB and Web services represent new technology, but designed to work with existing technology and improve its value. As such it really must be a new kind of product, with a new and different value proposition compared to previous generation EAI and application server products. An ESB must be something that enables and complements what’s already there.