SOUND INTERNET SOLUTIONS
Is SEMCI just around the corner? Not quite.
By John Ashenhurst
The caveats don't preclude eventual success with Transformation Station, but they do suggest that transforming the industry to use it isn't a trivial task.
In December 2001, AMS Services announced that it had made arrangements with IVANS to use Transformation Station, a network service that facilitates communication between agency and carrier systems. Transformation Station was originally created by Applied Systems but, in late 2000, Applied made the technology available to the industry through IVANS.
Shortly after the AMS Services announcement, the IIAA commended the vendor for joining Applied and DORIS in committing to Transformation Station, noting: "This positive development has the potential to create the critical mass the industry needs to make SEMCI--single entry, multiple company interface--a reality." Since AMS Services, Applied Systems, and DORIS serve more than 80% of the independent agency community, having them all use the same technology should certainly benefit agents, making it easier for carriers to develop and support both real-time and batch interface.
While the convergence of three vendors on a single interface platform is certainly good news, it would be a mistake to assume that SEMCI is now a reality or will be any time soon for most of the agency population. In many respects the problems in achieving SEMCI have been less with the vendors and more with the carriers. And though vendor commitment to Transformation Station appears to remove one hurdle to carrier support of two-way, real-time and batch interface, there are others--financial, technical, and strategic.
There is a real danger that over-enthusiastic reporting of the AMS commitment to Transformation Station will lead to unrealistic expectations by agents. For the last 20 years, agents have been told that the solution to the multi-carrier data exchange problem is right around the corner. At first they were told that ACORD standards and the IVANS network would provide the solution. That didn't happen--at least as advertised. Then agents were told the ACORD XML standards (now released) would solve the problem. Now IVANS' Transformation Station is supposed to be the panacea. Because of the perpetual gap between promise and reality over the last 10 or 15 years, agents have moved from being hopeful, to skeptical, then to cynical, and now to being apathetic. Although vendor convergence on Transformation Station is good news, it may prove to be only another way-station on a long and frustrating journey.
Why Transformation Station?
What is Transformation Station? According to IVANS, "Transformation Station ... now provides one-stop shopping for agency vendors and companies. Whether the solution is real-time, batch, store and forward, immediate mailboxing, or a combination, the business can be conducted through a single infrastructure." Transformation Station is, in part, a software package that translates insurance transactions from one form to another (ACORD AL3, ACORD XML, or some proprietary format) and between batch and real-time transmission as well.
Presumably, one of the barriers to widespread adoption of SEMCI has been the inability of carrier systems to connect with all agency systems and vice versa. One carrier system may support AL3 batch interface, another proprietary batch interface, and a third proprietary XML. With Transformation Station in the middle, theoretically at least, any carrier should be able to connect with any of the three subscribing management systems.
When IVANS was founded, the choice of its name was quite deliberate. It was to be a value-added network and would provide a translation service between various transaction formats so that one network subscriber could communicate with another without worrying about formats. IVANS would provide store-and-forward services (mail boxes) with translation services in between.
Transformation Station can be seen as the latest generation of the IVANS value-add, a service that can provide real-time transaction translation as well as enhanced store-and-forward services (batch)--and even real-time to "batch" and vice versa. The Internet and XML have made the communication landscape more complex, and Transformation Station is intended to handle it.
Where are the caveats?
Transformation Station advocates imply or openly suggest that the only thing that stands in the way of achieving long-promised SEMCI (real-time and batch) is carrier commitment, a little coding, and not much else. Would that it were that simple. As far as I can tell, there's little public recognition of the continuing substantive barriers to SEMCI--even with vendor commitment to Transformation Station.
Translation: Technical geniuses have been working on transaction translators for at least the last 40 years. Transformation Station, in part, is one such translator. It has advantages over generic translators because it grew up in the insurance industry, but it can't solve every insurance translation need--with just a little coding. Sometimes a great deal of analysis must be done and sometimes non-trivial changes are required to the carrier system.
Priority: Even if Transformation Station made translations a no-brainer, vendors and carriers must establish a priority of attention. They can't work on everything simultaneously--which transaction should be done first, which second, and so on. Much of the attention being given to Transformation Station now is focused on real-time quoting. Is that the best place to start? Does it have the greatest benefit for agents and carriers? Many agents believe that they would benefit more from early attention to policy change implementation over quoting, since changes occupy more of their time.
User interface: Transformation Station says nothing about the way the transactions appear to the user, that is, they address a communication layer but not the user interface layer. The U.I. is left up to the management system (or other agency software/service). That makes sense, or appears to, but some carriers express concern about the way their data may be presented. Their own "proprietary" Web sites make it very easy for agents to do business with them and in a way that favors the uniqueness of their own products. With some reason, they worry that the advantage they've gained through controlling the presentation will be lost when the field is leveled through an imposed U.I. provided by a vendor. And for that reason they may be unwilling to fully cooperate with vendors even though they're tied into Transformation Station.
Authentication: Agents who use multiple carriers' Web sites know that each carrier has a different authentication system. Some carriers are comfortable with some sort of password system. Others insist on digital certificates. The former are not specific-PC dependent; the latter are. Biometric identification (iris scanning, thumbprint) will soon be in the running as well. Can Transformation Station find an authentication scheme that every carrier will agree to? Or will each agency need to use a variety of authentication methods when hooked to Transformation Station, one for each carrier, the clumsy situation they face today?
Edit management: Transformation Station is intended to make it possible to pass clean, edited transactions to the carrier system--so they can be processed automatically. Today too many transactions going from agency to carrier systems are rejected and must be handled manually by the carrier. The Transformation Station environment supports two different approaches to creating and maintaining edit specifications, one developed by Applied and one by IVANS (which is what AMS is using). Therefore any carrier that wants to work with both Applied and AMS through Transformation Station must set up and coordinate two different edit systems. ACORD's XML service provider extensions offer a third edit specifications candidate and have some advantages over both the IVANS and Applied schemes. Which should be used? Or could some higher-level approach be created that supports all three plans?
Web services: We're all hearing a great deal these days about remote Web services, an idea being promoted by Microsoft, IBM, and Sun. The core idea is that software modules can be housed on servers anywhere in the world and then the appropriate ones invoked at a particular time to provide needed functionality to an agent (or other user). It's a wonderful picture and overlaps with ideas implicit in Transformation Station. The idea is that ultimately agency management systems would be having continuous real-time conversations with carrier systems mediated by Transformation Station. Carrier information and functionality would in effect be moved out to the agency management system without ever leaving the carrier servers. Unfortunately, neither the insurance industry nor the world at large has had adequate experience with remote Web services. What is certain is that operational problems not now imagined will crawl out of the woodwork and make using remote Web services difficult or even untenable, at least for a while.
Infrastructure: Transformation Station can be used only by carriers and agencies that have the right hardware and software infrastructure. Though probably less of a problem to carriers, agents may face significant hardware and even software expenses to become current with the agency management system release that supports Transformation Station. Given the inertia of installed software, the process will take years and perhaps can't even be justified by all agencies. Sometimes carrier IT practices won't support real-time interface because, for instance, they require shutting down systems overnight and on weekends. At least in some cases, carrier mainframes simply won't be able to handle the increased activity agent real-time quoting will bring.
None of the issues above precludes eventual success with Transformation Station, but they do suggest that transforming the industry to use it isn't a trivial task. And maybe Transformation Station isn't even the point.
Confusing means with ends
Transformation Station is the latest in a long string of idealistic and probably unrealistic approaches to solving the industry's many-to-many data transfer problem. These proposed universal solutions, all too good to be true, preempt more ad hoc, less ambitious solutions that, though capable of delivering real value quickly, don't claim to offer a complete solution. More than one carrier has suspended work on upload to jump to real-time quoting. Maybe that doesn't make sense.
And the elephant in the room that no one ever seems to want to talk about is that the many-to-many problem, and the need for Transformation Station, the ACORD standards, and other industry technical artifacts are unnecessary and the result of confusing means with ends. The end is making the industry more efficient and agents more responsive to their customers. Transformation Station and the line of reasoning it represents is the most expensive and difficult approach one could imagine. Were we focused on the goal rather than the technology, we would quickly find ways to eliminate most of the need for interface by making agencies the center of the insurance sales and service process, rather than the peculiar and overlapping division of labor we see today.
The message? If you're an agent, don't expect Transformation Station to immediately bring interface utopia. If you're a carrier, do look into Transformation Station but with your eyes wide open. If you're a vendor, work with Transformation Station, but make sure your users have a realistic view of the situation. If you're a user group or association, support the general concept but ask for objective reports from knowledgeable carriers, vendors, and others before being caught out on a limb. Transformation Station may be the best thing going, but that doesn't mean we'll be any better off in five years--even if everyone wholeheartedly adopts it. It's more likely that we're like the fly in the fly bottle. All we need to do is turn around to escape our self-imposed conceptual prison. *
The author
John Ashenhurst is editor of "Sounding Line," a monthly newsletter covering insurance and the Internet. His company, Sound Internet Strategy, provides consulting, Web site evaluation, and seminar services to independent agents and their trading partners. He can be reached at johnashenhurst@soundingline.com or (360) 376-1090.