The STAR eXchange

STAR will be hosting it’s upcoming Winter/Spring General Session in nice and warm Orlando Florida.   As I write this entry we just were slammed with a nice winter storm which pretty much shut the east coast down.   So those heading to the NADA convention will enjoy a much needed reprieve from winter’s grasp.    As they are doing so, and since spring is right around the corner here is some food for thought.

Where should STAR as an organization go for the next several years?   Some may think we have done all that we can and there is nothing left to do.  However, the only thing that is constant in the universe is change.   Some will argue that the speed of light is constant, but that is a nit pick.   While many of the data standards are fairly mature, there are still areas in the Dealership’s business process we do not address, or have not addressed well.

One area that is growing and needs some help in standardization is the growing need for add-on provider integration with the main dealership system.  In some ways there has been resistance to providing a common approach to allowing these add on providers to connect.  Valid concerns about network bandwidth, and security have been used as reasons to limit availability.   Network bandwidth increases over the years, and with recent changes to the STAR Web Services 4.0 specification the security aspect should be addressed.

The OEM and Dealership Management System providers can leaverage the same STAR Web Service specification that they use for communication with each other to allow third party providers to connect to their system.   By leveraging this they are making it easier for more providers that they certify for connection, to be used by the dealership.   A third party provider may have more than one dealership management system to connect with, and by leveraging a common industry standard transport, it can make it easier for all involved.

Prior versions of the STAR Web Service specification left too much open for interpretation.  The new version due in May for general use, address this by specifying a minimum level of interoperability that all implementations must support.   It also updates to the latest Web Service specifications supported by implementation frameworks.     The security aspect leverages industry standards like WS-Security and Digital Certificate Authentication, giving the service provider that needed level of authentication to know who is accessing the system and when.

Service providers can and should be allowed to provide certification into their system, but the starting point for the transport and gate way should be a common industry standard like STAR’s Web Service specification.   In the long run, it is about keeping the dealers happy, and giving them secure access to their data to work with the applications they choose to run their business.   After all if the Dealer is happy, everybody is happy.

If you are going to the STAR General Session and have other ideas for discussion, please feel free to bring those up during the General Topics discussion section in the afternoon on February 11.  Oh and make sure you stop by the STAR booth to say High and show your support for the organization.

STAR is pleased to announce that the Feb 11th 2010 STAR General Session Keynote Speaker will be Chuck Allen, Integration Architect at SilkRoad Technologies, Inc and founder of HR-XML Consortium.

Chuck Scahill, current STAR Development Chair and VP of Business Development from Karmak, Inc stated, “I think it will be an excellent presentation.  It is both timely and consistent with our experiences, particularly this past year.”

———————————————————-

Keynote Presentation:  “Standards 2010: Prospects and Challenges for Standards Development in the Next Decade”

Abstract:

As standards organizations enter the 2010s, they face very different circumstances than a decade a ago. At the dawn of the “2000s,” analysts warned us that a key risk was the creation of a “tower of babel” as industry standards groups proliferated nearly as fast as dot.com start-ups. By the end of the decade, some groups had achieved measurable interoperability gains, but at the cost of years of upfront committee time followed by implementation and revision cycles also spanning years. Today, standards organizations that have managed to survive the decade’s two boom and bust cyles face vastly different funding circumstances and participation levels. At the same time, standards organizations are challenged by an accelerating pace of technology and marketplace change.

In this session, Chuck Allen, founder of the HR-XML Consortium and an adviser to other standards initiatives, will offer a survey of the state of standards development, including key challenges and new approaches. Among topics to be reviewed are:

Development methodologies. The committee processes driving most standards development organizations (SDOs) have remained largely unchanged over the past decade (STAR standards being an important exception). Most SDOs take months or years to spec out a standard with meaningful development against the specification beginning only after publication. While standards organizations have been slow to adapt their methodologies, in the same period, many enterprises have significantly transformed their internal development processes through the adoption of a range of agile methodologies. While there is growing recognition of the need to update standards development process, the prospect of applying agile methodologies to standards development tends to be met with equal degrees of interest and trepidation.

Intellectual property. Most standards organizations manage intellectual property by requiring participants to grant royalty-free licenses to the SDO and to anyone implementing the standard. For companies with large patent portfolios, this can impose a burden of expensive patent inventory searches and monitoring. Since each SDO has slightly different licensing terms, current licensing practices also prove challenging for an implementer wanting to apply multiple standards as well as for standards development organizations trying to converge standards. Patent non-assertion policies and efforts to simplify and standardize licenses hold some promise is reigning in the complexity associated with managing IP.

Funding models. Standards cost money to develop and maintain. However, traditional funding approaches, such as pay-to-play” and “pay-for-the-standard” don’t always keep up with funding needs and can work as disincentives for adoption and engagement.  There isn’t an easy answer to the question of financial sustainability for many SDOs, particularly in these tight economic times. The answer likely lies in a combination of approaches, including doing more with less, the design of attractive sponsorships, meeting and programming fees, and taking advantage of grant opportunities.

About the Speaker:

Chuck Allen, Integration Architect at SilkRoad technologies, Inc., was the founder and Executive Director of the HR-XML Consortium, Inc. Prior to founding HR-XML in Dec. 1999, Allen worked in a variety of new product development roles for major business publishers, including Thomson (now Thomson-Reuters) and the Bureau of National Affairs. Allen has a B.A. from the University of Virginia.

———————————————————-

Event Date: Thurs., Feb 11th 2010

Host Details: STAR Organization

Meeting Registration Information: The STAR February 2010 General Session is available only to STAR Members and approved Guests. If you are a non-member and wish to attend, please email Ghezal Khalili, STAR Executive Coordinator at gkhalili@starstandard.org .  If you are a STAR Member, please register at this link: STAR Member Meeting Registration Link

Interoperability when dealing with standards can be a frustrating thing, and it should not be.   The goal of a standard is to reduce the overall work that has to be done, eliminate the one offs, and allow users to exchange their data between tools.   However, the failure of many UML based tools to reliably read and exchange even the simplest of models is a lesson that we should learn from, not try to emulate.

It's been interesting following the Model Interchange Workgroup's testing of various UML 2.1 compliant tools.  The results have not been surprising.  Many tools have interoperability problems, from failing to render according to the spec, to not even being able to read a compliant XMI file.    To many large vendors there is little incentive to have interoperability as they feel it gives them a edge.  However, these vendors are just opening the door to others that can provide interoperability.   Having a unique implementation or a one off of a standard is not an advantage, it's a hindrance to your customers.

It's important for Standards to be Standard.  While it may be convenient for you to make a one off change, as soon as you role that change outside of your internal application, you provide a pain point for all of your trading partners.    In order for Standards to be Standard, members and the community need to participate.  It means contributing your requirements back to the organization, or working with the organization to find where your requirements are captured.  In many cases your use case is not unique as you think.

In order to help enable these changes, standard organizations need to respond quicker to the communities needs.  They need to adapt and make changes available sooner.   STAR currently publishes a yearly version available to the community.  However members can get updated versions in a little as a day after the request is received.   It's one of the benefits of being a member.  However, are we responding quick enough by a yearly release?  Does the community need a bi-annual release?

Organizations should also provide a testing tools for the community.  STAR provides the BOD Validation website which adopters can use to check that their STAR BOD validates against the official STAR schemas.  If you receive something from a trading partner that doesn't validate, it isn't STAR compliant.  The community needs to step up as well and make sure that your trading partners are using validly formatted BODs.  There is only so much enforcement that an organization can do.

The community needs to ask and demand for interoperability.

In general though, having non-interoperable changes may not necessarily affect your implementation, but it does greatly affect your trading partners and their trading partners as well.   Do not repeat the mistakes of the UML Tool vendors.  Let's learn from them.

The STAR community in general is much more diverse than I think most realize. Too often we focus on the OEM, DMS, and Dealer relationship. However, there is a ripple affect that takes place.  Each of these entities deal with other trading partners, and they deal with others as well.   The STAR reach affects many areas that are not traditionally thought of when discussing the standards.  When we modify or deviate from the standard for our own convenience it affects everybody in the community.

An upcoming STAR eXchange Newsletter article will touch on these concepts in a bit more detail.  Look for it at the end of the month.

At STAR we like to look at what other Standards organizations and non-profits are doing to help their membership and community. One of the ones we keep an eye on is ACORD, they share many of the same values and opinions on standards that STAR does.

ACORD held a recent meeting in which they outlined their goals for the year:

With yesterday’s approval and release of the STAR Transport specification documents, STAR has listened to members and the community to help create a more interoperable specification. The STAR Web Service specification received in some ways a much needed refreshing.

The specification has not changed much in the last 4 years. However since the time that it was in production many things have changed within the web services world.

• STAR has both members and non-member implementation experience to draw upon. This helps give us real world interoperability experience to gauge how well the specification is meeting its goals.
• Many of the standards that were recommended in the prior version were draft standards. These have since moved out of draft status and into official recommendations.
• Tooling support has been greatly enhanced and evolved. Many of the older specifications are no longer supported by current tooling.

Interoperability:

One area that has been hard to maintain with out a strict profile is the goal of deploying the web service once, and having it work with out change amongst a variety of trading partners. The reason for this is that the old specification allowed a lot of wiggle room in its interpretation. To help with interoperability the latest specification to has addressed the following:

• Documented a set of REQUIRED rules that STAR Web Services must implement. The current specification addresses the STAR Level 1 compliance rules. Work is under way for more advanced features called STAR Level 2.
• Updated the specifications to the most current approved standards. All STAR Level 1 requirements are supported by the existing tooling and frameworks.
• REQUIRED compliance to the WS-I Basic Profile 1.1.
• NOTE: That STAR WS 4.0 is not backwards compatible with STAR WS 3.0 implementations. Namespaces for many of the required specifications have changed as well as the STAR Transport namespace.

Interoperability Testing:

STAR also joined the WSTF group this last year. WSTF provides a forum where tooling vendors and implementers can work together on specific web service implementations. STAR will be proposing some use case scenarios to the WSTF to have web service endpoints setup to test both the STAR Generic Transport as well as the BOD Specific transports. By publishing these endpoints, STAR Members and Community adopters can test their implementations for interoperability against various implementations. It is the hope that by providing these end points an unofficial verification can be made that an implementation should be interoperable with another.

STAR Level 2:

The Architecture Workgroup is currently addressing some more advance use case scenarios and will be documenting these under STAR Level 2 requirements. An important note is that a STAR Level 2 implementation must be able to fall back and inter-operate with a STAR Level 1 implementation. STAR Level 2 will be addressing items like:

• WS-ReliableMessaging
• WS-Addressing
• WS-Policy
• Attachments with MTOM
• WS-Security with Digital Certificates for Authentication.
• Leveraging the latest approved specifications from WS-I on WS-Security and Reliable and Secure profiles.

What about ebXML?

This is a topic on the radar for STAR over the next year. ebMS 3.0 is now released, and STAR needs some feedback on whether current implementers are going to migrate to ebMS 3.0 or if they plan to stay on ebMS 2.0. ebMS is a victim of its own success in some ways. This is due in many ways to its stability and interoperability of the specification. Migration may be slow to ebMS 3.0 due to the fact that ebMS 2.0 just seems to work.

Please check out the latest specifications and feel free to comment or send us feedback on the latest specifications. We can only make sure we are addressing community needs if we hear back from the community.

David E. Jones, VP of Open for Business at the Apache Foundation has a good blog entry called, Open Source Community Collaboration Best Practices. He has this to say about Collaboration.

If you want other people to collaborate with you, first you need to collaborate with them. If you are hoping for some benefit of the collaboration you first need to set the stage for the collaboration and invite others to collaborate by starting first and giving what you have, then invite others to get involved. The important thing to keep in mind is that collaboration implies a two-way street and if you try to make it one way by not trying to collaborate with others, but still expecting them to collaborate with you, then you will most likely be disappointed by either no collaboration at all, or a good-will attempt by someone else to collaborate with you that will fail because no stage was set for the collaboration and they will likely help in a way you don’t need…..

Substitute open standards for open source and the blog applies just as much to open standards development and collaboration. Read the rest of the entry at his blog.

In our recent announcement about the STAR 2009 Transport package, we talked a bit about some of the upcoming changes. Most of these changes are coming about because existing implementations are not interoperable. The original goal of the STAR Web Services specification was to provide a common way to implement the web services, so that there would not be different flavors. However, the reality of the situation is that the current specification leaves too much open to interpretation. This is causing the very problem we tried to address, one off implementations.

Another thing has happened since the document was originally written, the web service specifications have evolved. Many have moved out of draft status and into recommendation or released status. Many of the approved specification namespaces have changed. Frameworks distributed by tools that are used to build the web services have evolved and upgraded as well. So STAR is working to address the issue and bring the web services specification up to date.

This will mean breaking backwards compatibility with existing implementations. There is no way around it if we are to try to address the issue of interoperability and framework support. Also, there will be a tightening of the requirements for an interoperable service. To help with this, STAR has created a two-tiered approach. STAR Level 1 and STAR Level 2 requirements.

STAR Level 1 requirements are the basic requirements and will affect all implementations. The STAR Level 2 requirements cover things like WS-ReliableMessaging, Addressing, MTOM, and other more advanced features. It is the hope that by clearly specifying what is to be supported, and working with groups like the WSTF, we can help ease the pain and help increase the reuse of the web service. Particularly from a client implementation standpoint. If the service is implemented the same by all parties, the same client code can be used to access it.

I’ll provide some more views on what is happening in the coming months. As always, I encourage community members to provide us with feedback. I’ll take that input back to the group that is working on the profile and make sure your voice is heard. Please leave comments here.

With true dedication from STAR members the Transport Package 2009 Release 1 has been published for everyone to utilize. The documents contained in this package are great tools to help with implementation, interoperability and maintainability of IT Infrastructures to define standards for XML BOD transport that meets the requirements of Automotive OEMs, RSPs (Retail Service Provider) and Dealerships . The three documents included are:

• Transport Guidelines – a high level requirements and recommendations document
• Web Services Guidelines – implementation details for using Web services specifications
• ebMS Guidelines – implementation details for using the ebXML Message Services specification

In the coming months the Architecture WG which is comprised of several STAR members will work diligently to get the latest and greatest Transport Package out to the public. This release is slated for August 2009. A few of the changes you will see will be:

• Addition of MTOM specifications
• Updates to several areas of the Web Services Specification
• Re-organization of content
• Large File Handling specifications

A recent blog entry by Ed Merks, had an interesting quote:

The maturity of an organization’s policy around open source tends to progress from deny, use, contribute, champion, and finally value co-creation.

While Ed is talking about how a commercial company may eventually evolve through the various stages in open source adoption, it equally applies to how a company goes through and adopts open standards. In STAR’s case, it is the common pattern that we see when talking to various companies about the use of STAR and how they are deploying it within their businesses.

1. Deny – many feel they don’t need the standard, that their business works just well enough with out it. In fact there is some fear that if they use a standard it won’t give them the competitive advantage. This could be called the FUD principle as well (Fear, Uncertainty, Doubt).
2. Use – somebody finally uses the standard, they implement and deploy it. They start trading with another client/partner, with the same standard. Find they can re-use or use the exact same implementation they did before. Freeing time and resources for other “added value” features for their customers.
3. Contribute – having learned the value of using the standard, they want to give back to the organization and help address other areas that are pain points. They may join the organization that created the standard, start an open source project that implements the standard, or help others to implement the standard. There are many ways to contribute.
4. Champion – after having experienced the advantages and ROI on using the standard and deploying more, some move to the champion stage. Helping to bring others into the organization, actively participating in the community, and going beyond and above the call of duty. Champions are rare. They look beyond what is best just for themselves, but what is best for the community.
5. Co-Creation – this is the stage we have yet to reach as a community. In some aspects getting your customers involved with the creation of your products is the driving point of co-creation. In the way of standards, it’s bring those pain points that are common back to the community, and working together to address them and add value for the customer.

So the question I leave you with: What stage is your adoption of standards?