SCENE: A deli lunch counter

Customer: Id like a turkey sandwich with mayo, lettuce, and tomato, a bag of potato chips, and a large iced tea please.

Deli worker: Im sorry. I cannot prepare your order. I do not understand it.

Customer: Huh?

Deli worker: We only accept orders given as follows: 1) sandwich type, 2) condiments in the proper order, 3) drink preference, and 4) side order. You gave me the elements in the wrong sequence. Your condiment listing was out of order. And you never told me how to assemble the iced teashould I put the liquid in before the ice or the ice first?

Pretty ridiculous, huh?

The deli worker only needs to know the items the customer wantsthe basic elements of the order. Following a few conventions, learned through experience, thats enough for them to engage in a transaction is the fundamentals. The deli can easily accept those pieces in any order and prepare them in any way it deems proper to fulfill the request.

If someone comes in and asks only for the drink and sandwich, will the deli worker waste time and antagonize the customer by explaining how he cant make an order without condiments or a side order? The condiments are obviously attached to the sandwich via speech/grammar conventionssuch as with, or on the side. The sequence shouldnt matter. No one would think the customer wanted the mayo on the chips or in the drink. Who cares how the iced tea is assembled as long as its iced tea? And if the deli worker misses an item in the request, should the entire request have to be sent again?

If the deli workers and customers who interact with them spent their time endlessly debating the order and structure, the line for sandwiches would run out of the deli, onto the street, and we would have a crippled business model (and no lunch).

The above metaphor is an exaggerated microcosm of the EDI-XML standards efforts conducted by organizations like ACORD.

Heres the question: Should ACORD mandate not only the place holders for the items (sandwich, drink, etc.), but, like the deli worker above, also a rigid order in which they must be given, just in case someone wants mayo on their chips or in their drink? Or should it simply define the XML tags to identify elements like sandwich, drink, and side-order, and then provide just enough conventionthrough an industry-grammarto make sure we know how to attach an attribute like mayo to a sandwich?

What we need is a framework that allows flexibilityone that specifies only what is prudent for us to get the essential job of sharing information done. Unnecessary rigidity would eradicate what little flexibility we have in insurance!

In a world that has been forever changed by the flexibility and speed of the Internet, with new standards for conducting personal and business interchanges on a global basis, we think ACORD needs to better evaluate its methods and practices to meet (or exceed) the needs of members and interested third parties. Silly as our metaphor is, it is directly applicable to efforts now taking place.

Microsoft provides strong support for ACORD. We have regularly promoted membership and participation in the process, and we aggressively work with partners to have them implement the ACORD standards in their platforms and tools. We have also provided many years of thought-leadership in the development of standards and tools that enable the easy implementation of improved workflows and business processing, worldwide. We also urged ACORD to consider expanding its influence to global transactions, to cover more broadly the business concerns of their constituents.

We believe ACORD has a great opportunity to shed the past attributes of too-slow-a-pace and too-shallow-a-set-of-business-deliverables and provide an enhanced charter and deliver undeniable value-add.

Gift horse. Mouth.

ACORD and other standards bodies have been given a great gift in the world of e-commerce and inter-enterprise data exchange: XML. But AL3 thinking may have hobbled this emerging technology for agency-company interface and powerful e-commerce development.

Microsoft has taken two fundamental positions regarding ACORD that would tend to support just the opposite. Our participation in its activities over many years has been to help it see new ways of crafting and providing their chartered deliverables and in the use of new, globally accepted techniques for speeding its implementation pace. We felt that slow but steady progress was being made.

Now were not so sure. Continued moves ACORD has made toward a more closed processa hierarchy of committees and bureaucratic processestend to validate the criticisms and entrench yesterday and lock out a more dynamic and agile tomorrow.

ACORD is not aggressively leveraging the changes that have happened on a global scale, to improve the way it delivers standards. As a result, many customers are still waiting for needed work to be completed and are beginning to implement systems outside the standards. They have the legitimate, age-old excuse for ignoring them: They cannot wait for ACORD to deliver the goods.

A global revolution in openly-developed and -supported standards provides us with the best example of how standards can in fact, stimulate business improvements and powerful reductions in cost. The current Web services movement is rooted in standards development. Consider that AL3 means little to all but a few hundred or so interested parties inside the American P&C industry. But TCP/IP, HTML, and now XML hold meaning for millions of individuals worldwide and are being implemented by thousands and thousands of trading partners.

It is the power, breadth, and reach of Internet standardsthe process of developing and spreading them and the new thinking about global business processingthat we feel ACORD is ignoring in its efforts. The ACORD standards are no different than the globally adopted and developed Internet standards. It is only the practices and efforts of the standards bodies, and how rapidly they can be adopted by software developers, that make the difference.

ACORD has a large charter. There are many lines of business, thousands of data points, and complex business transactions that could be included in each committee and standard working group. This makes the foundational work critical. That foundation needs to be built firmly so the rest of the work can rely upon an unchanging and stable release. This also facilitates participants who want to use that foundation to base custom solutions so they also ensure extensibility into later standards. Has ACORD secured that foundation right now? We think not.

By using a more aggressive and open development approach, release milestones can also translate into better scaling of features sets. For instance, a rich data dictionary is a small feature set upon which companies can build immediately. From there, simple transactions can take shape. When released, those can be built upon as well. From that step comes bundled transaction sets and then larger workflow and business processes.

Each one of these steps can be a logical jumping off point for work to begin for anyone that looks to the standard for leadership.

By starting small and then moving on to the larger next step, everyones interests can be served, from the smaller more agile companies to the larger more influential firms. In this way, lightweight transactions like a change of address can require sending only the necessary data elements, not the entire policy record. In addition, it allows for new transaction frameworks and communication standards to be incorporated without any conflict in underlying technology. For instance, in a simple change of address, a header could identify the originating party and the customer of record. This could be done securely using other widely accepted industry standards, without any impact to the transactions underlying data standards.

As with any institution, change poses many challenges. While we believed that ACORD was making progress on a number of fronts over the past few years, we now grow concerned over larger, more cumbersome efforts that we feel are undoing some of that early good work and are surfacing old practices that may not be productive for the industry at large.

Stick To The Knitting

Our concerns are rooted in three fundamental problems that we see, looming on the horizon for ACORD.

ACORD extending itself into the domain of business processing, rather than focusing on aggressively mediating a shared data-dictionary and transactional framework on behalf of member organizations.

A return to slow, bureaucratic, staff-driven processes, placing strictures on ACORD members to communicate and their ability to rapidly create systems to support their business objectives.

Lack of formal support or guidelines for emerging global XML standards for transactional computing.

If ACORD focused its efforts on creating only a data dictionarya list of shared elements required to facilitate the exchange of business processing information (so true multi-company e-commerce could be implemented)it would be delivering powerfully on its charter. It would also have the needed bandwidth to cover more ground, and more lines of business. If it supported the global Internet initiatives that are enabling tremendous e-commerce capability worldwide, it could participate in an even greater renaissance of industry vertical standards. Perhaps even lead it.

An ACORD data dictionary, complete with taxonomy and ACORD nomenclature, is important in high-performance transactions. Simple policy changes should be built out of ACORD elements that can be identified in standalone format as ACORD elements. The lightweight transaction is what will be the basis for vast new business libraries of Web service transactions that insurance carriers expose to their agents and to internal business units. These Web service transactions would be well served by ACORD data element standards.

Current implementation finds carriers taking the ACORD spec, extracting the relevant pieces of the transactions, and forming their own transactions. That nullifies the value of the standard itself! Once developed, data element standards can act as the basis for many larger transactions standards. Why should a transaction call for boat loads of extraneous data just to change the primary driver on a vehicle? It shouldnt. Instead, the transaction built by Carrier X and exposed as a Web service should rely on simple identification data elements that are standardized by ACORD, thereby creating that trusted base of agreement for the element attributes.

Unfortunately, ACORD decidedagainst many diverse and important voices of oppositionto spend time and energy developing a complex data model, which it has indicated its intends to mandate. This effort will create a formalized, rigid data structure that may be enforced to attain certification.

This, at a time when ACORD hasnt crafted the data dictionary that addresses all of the lines of business and transactions for which its constituents need to build transactional workflows! This is a mistake and a waste of resources and time.

Inflexibility Breeds Contempt

To better understand how a rigid data model can foul things, consider being able to deliver the identifiers necessary to express drivers and cars. If we publish a standard that enforces drivers-attached-to-cars, what will we do when someone wants to implement a transaction in a domain where cars attach to drivers?

With rigid data structuring, we lose the flexibility that XML has brought, not to mention development speed. We greatly limit our potential for improved workflow and business processes. We also end up with ACORD telling companies how to process business, rather than simply having it provide the essential elements that facilitate the exchange of business information. This will further the issues of commoditization that the industry has so poorly prepared itself to fight.

ACORD should leave the data models to carriers software developers. Those models are the domain of business processing and not that of a standards body.

If ACORD spends its limited time and resources to craft a rigid data model, it will not be using those resources to continue to craft the multitude of building blocks needed for additional lines of business. Thus software developers and carriers will have to make their own formats for business application development. Weve seen this time and time again; many of the companies we try evangelize to join ACORD give it as a reason not to be a member. (Weve always been successful at opposing those positions, but its getting harder to do.)

The promise of true interoperability across systems, applications, and programming languages isnt just possible, its becoming pervasive with the tremendous potential of XML-based applications. We want ACORD to join us and our technology partners in adopting a more timely posture for developing and releasing the tools for developers to build next-generation applications and transactional platforms.

Another Way of Putting It

Microsoft has released a new set of specifications that are the beginning of the Global XML Web Services Architecture (GXA). Because there are no broadly-adopted specifications for security, routing, reliable messaging, and transactions, developers today either have to go without these capabilities or develop ad-hoc solutions. Microsoft intends to work with key industry partners and standards bodies on these and other specifications important to XML Web services.

Divided into three conceptual layers (SOAP, SOAP modules, and infrastructure protocols), GXA is built on the Internet and the XML family of technologies. Our strong commitment to GXA is similar to other efforts we have taken regarding XML Web services. That commitment is resulting in great strides in speed of application development and improved methods for true e-commerce.

We urge ACORD to consider revamping its processes, limit its focus on data-modeling, shun bureaucratic methodologies, and work closer with Microsoft and our partners to speed the release of the standards. That will allow carriers, ISVs, and agencies to implement the next generation of insurance processing in a more timely fashion.

ACORDs current direction smacks of severe feature creep. Because of the redundancy of a few groups efforts to release a standard for all the necessary business units, we see many customers having to roll their own solutions. This is not only unfortunate, but risky. The relevance of ACORD diminishes with every custom solution that gets completed as a workaround. With rapid application design (RAD) tools and real-time dynamic discovery of data and application integration, legacy standards may become less and less critical to operational success between businesses and in industries. After all the years of effort and participation, we think that would be a shame.

Kevin S. Kelly (kevkel@microsoft.com) is managing director of financial services for Microsoft. Josh Lee (joshlee@microsoft .com) is Microsofts financial servicestechnical strategist.

Special Reports /

Food for Thought: Is ACORD Serving the Industry?

Related Stories

Recommended For You