The STAR eXchange

On July 21, 2009 STAR posted its second 2009 release of the Dealership Infrastructure Guidelines, more commonly referred to as the DIG. The DIG is a set of guidelines and best practices designed to aid a dealership’s IT staff in the implementation and maintenance of its network infrastructure. STAR has been providing support for the dealer community with the publication of the DIG and its predecessor document, for over 10 years. So it may come as a surprise to some that a majority of dealers are not aware of STAR, the DIG or the STAR data exchange standards. Why is that? Well, here’s my guess.

The spotlight of the STAR organization is typically drawn to its data exchange standards, its common architecture, and the need to promote the interoperable exchange of data between OEMs and DMS providers, the key players in the development and utilization of STAR standards. The data standards themselves are, by their nature and if properly implemented, meant to be transparent to the dealer. Basically, the standards remain hidden in the back-end of a dealer’s systems. The ideal situation leaves the dealer with only the benefits of the standards which are designed to increase and improve vendor choice, lower costs, eliminate redundant data entry, and improve overall business efficiencies.

Unfortunately, with the amount of attention given to the STAR data exchanges standards and the intended transparency to the dealer, in many cases the STAR message itself does not make its way to the dealer.

Then there are some cases where a STAR message or a STAR-related message is given to the dealer, but not necessarily one that conveys the value of the standards. In the case of a dealer’s IT infrastructure, the dealer may be made aware of changes resulting from franchise agreement necessities noted as addendums to STAR’s DIG. For example, an OEM may notify its dealer community that they must be off a proprietary satellite by the end of the year to be in compliance with that OEM’s new IT infrastructure requirements that are in the OEM’s Addendum to the STAR DIG. While this change could end up saving the dealer thousands in return on investment, it is not exactly a glowing STAR recommendation. Instead, the dealer only sees unexpected costs and changes being dictated with no clear understanding of what value or ROI is to be derived from the change and not much choice. Again a message, but not exactly the one STAR wants to convey.

When we are developing value propositions and marketing initiatives, we all too often forget that it is ultimately the dealer that utilizes the systems that implement the standards. Therefore, it is ultimately the dealer that is our end customer. If we miss this point, we are missing a valuable opportunity to grow and support a grass roots movement that has the ability to promote STAR from the bottom up. This is a voice that, to date, as has been under utilized.

Consider the possibility of dealers requiring their vendors’ to utilize STAR standards. What about the possibility of an entire dealer council urging its OEM to not only support STAR standards but to map a course for STAR compliance? Those and more are all possibilities with an educated and empowered dealer community.

So how do we get there? We need to bring STAR from the back-end of dealership systems to the forefront of the dealer’s day to day business. Dealers must understand what STAR is, what it has done for dealers, and what it can do for their business AND how they can support STAR.

Recognizing this lack of brand awareness, STAR has identified as a 2009-2010 objective the need to create more education and awareness within the Dealer community. Education and awareness are basic tools for empowerment when it comes to standards.

One way that STAR is doing this is by partnering with its members such as OEMs and dealer organizations like NADA, who have a common interest in promoting such STAR initiatives as the STAR DIG. Through these types of partnerships STAR can connect with dealers through its members’ dealer facing websites and dealer communications to promote the education and awareness of STAR and the DIG. A good example of this type of successful partnership would be NADA’s “STAR and Internet Guidelines for Dealers” web page. This page is dedicated to promoting the STAR DIG, to post the latest STAR Dealer Tech Sheets, and to encourage dealers to contact their manufacturers about STAR standards.

STAR is also looking to partner with members and their dealers to promote the success that they have had implementing the DIG. STAR would like to capture these success stories along with recommendations to expand and improve the DIG in the form of testimonials to be shared with the larger Dealer community.

Through these joint efforts and more, STAR and its members can ensure that dealers are aware of and have access to STAR materials such as the DIG.

The DIG is the dealer’s gateway into STAR. Once dealers are aware of STAR, aware of the benefits that they can receive from STAR standards both in terms of their network infrastructure and their systems, they themselves can become STAR advocates. They can use STAR compliance as a criterion for selecting vendors. They can encourage their OEMs to adopt and participate in STAR standards. Dealers can even participate in STAR’s Dealer Advisory Group and identify areas of operation within the dealership that could benefit from standards.

The Dealer Community is a critical component in the sale and service of vehicles and even more critical to STAR is it ultimately our end customer. With education and awareness, it is a community that can play an invaluable role in moving the standards movement forward.

One of the constant themes I hear about users in STAR is the size of the XML files. That there is a problem parsing them, processing them, and in general trying to cram them into legacy data stores and using legacy technologies. One of the unfortunate side affects of data binding of XML is that everybody tries to use it for everything. The first and typically last tool a programmer will go for now a-days is a data binding framework. Unfortunately, this is not necessarily the best choice. In many cases, if you dig around in the xml tool bag you can find other choices.

Kurt Cagle has written an excellent rebuttal on the FUD (Fear, Uncertainty, and Doubt) that XML is not right for BIG Data. When we are talking BIG we are talking 50MB or larger. In fact, he rightly says:

Frankly, if you ARE storing your XMLdata in a relational database repository, then you’re throwing valuable money away, because you’re adding a hideous performance penalty on every transaction.

Kurt Cagle, XMLToday.com

He goes on to talk about the role of XML Databases and how in many ways they are out performing their relational database counterparts. STAR has several very large BODs that may need to be processed and queried. PartsMaster, LaborOperations, PartsPriceList, and RepairOrder are a few that come to mind. Processing these with data binding is definitely not the way to go. Supplementing an existing Relational Database with an XML Database can be very beneficial. It also allows you to work with XML natively without necessarily having to do a data transformation to get at the relevent information. Investigate your existing Relational Database as many have XML Data Storage abilities. XML can be a good fit for Big Data, it just takes using the right tool for the right job, and not trying to use the same tool for every job.

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:

A blog from Vishal Vasu, “Open Source vs Open Standards“, has some interesting points on how the two terms get confused. His points about open standards are on target:

The word “Standards” means a set of guidelines to which a lot of people have agreed upon. Putting this definition in the context of software, “standards” allow a company to pick and choose from competing vendors and interoperate their systems without being pinned down to one of them.

He’s correct with this statement, the goal of a standard is to promote interoperability amongst vendor implementations. So that a user can pick and choose from vendors that compete, but doesn’t lock the user into one of them. Vendors should compete on the value added features they provide the users, not the proprietary nature of the data. Custom extensions to a standard are no-longer a standard, they are proprietary.

In the STAR community this means that customers must require and demand that STAR standards be used in the products they purchase and use. This allows them a greater choice in moving from one vendor to another. Vendors that work with multiple trading partners need to require that STAR be used, and if requirements are not there, work with STAR to get additional changes to the standard made.

However, Vishal, goes on to say:

I feel we should have more specific and beneficial standards that are not vendor specific or not vendor dictated because ultimately it is the interoperability that counts at the end of the day. If open source software fits your environment and gets the work done in terms of costs, features, support or maintenance – all’s well. But if you are putting security, compliance, performance, upgrades and scalability before everything else then proprietary software designed with open standards in mind is your choice. We can even extend this further and run a combination of both – it’s our choice.

Interoperability again is the key here, but the statement on proprietary systems being more secure, compliant, better performing, upgradable, and scalable is not accurate. There are many open source implementations of standards and in general software that is much more secure, performs better, upgradable, scalable and is more compliant to a standard than many proprietary systems. Like any software product out there, this varies by product to product, whether it is open source or proprietary. More and more proprietary software is leveraging open source to help create it.

In general though, interoperability are what standards are about. Customers need to require this interoperability within the products they use or purchase. If a software system does not allow the export and import of their data into an open standard format, they are locking themselves into that vendors product for the long haul. They are limiting their own ability to control the data that belongs to them.

One of the benefits of STAR membership is the ability communicate with the people contributing time, and resources to it’s development. In the last several months, STAR has been upgrading the tools that it provides to it’s membership to make this collaboration easier and more frequent. We’ve recently upgraded the look for the forum itself:

The forums are a great opportunity for STAR members to collaborate on the development of the standards and participate in workgroups, when they have the time. Not everybody can make the scheduled workgroup calls, so we encourage members to participate in other methods. The newest workgroup that has been introduced is the STAR Marketing Workgroup. The marketing workgroup will be working at ways in which STAR and Members can help promote the usage of the standard.

So even if you are not into the technical development of the standards, there is a way for you to participate and give back. If you are a STAR member consider joining the Marketing Workgroup, and if you are not a member, please consider becoming one to help us promote the standard.

One of the nice things in web site content and design is that you can pretty easily update the look of the site with out having to redo all of your content. The STAR website has undergone some more visual design tweaking.

Some of the goals of the redesigned skin:

• Make it easier for those in the Media to get to the information they need.
• Make it easier for the user community to get to the most requested information quicker.
• Provide an easier method to retrieve printable pages.
• Provide a more pleasant browser experience.

Many of the changes were implemented by leveraging the Top Content reports from Google Analytics. The changes are directly reflected on how users were using the site and which parts they were visiting most often.

Over the years, there have been many variations of the STAR web site. Each hopefully improving on the useability and accessibility to the main content that the user community needs. For a walk down memory lane, the Internet Archive Wayback Machine, has the archived versions of the STAR website. The earliest it goes back is 2001. Take a walk down memory lane, and provide us with feedback on the new look.

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.

Over the years, I’ve been introduced to a variety of XML Schema design patterns. We’ve gone the route of defining everything in complex types as in STAR 4

STAR 4:

    <xsd:complexType name="PartyBase">        <xsd:sequence>            <xsd:element name="PartyId" type="PartyId" minOccurs="0">                <xsd:annotation>                    <xsd:documentation source="http://www.starstandard.org">Party Identification Number</xsd:documentation>                </xsd:annotation>            </xsd:element>        </xsd:sequence>    </xsd:complexType>

To going to all Global Elements in STAR 5:

   <xsd:complexType name="MessageType">        <xsd:sequence>            <xsd:element ref="ID" minOccurs="0" maxOccurs="1"/>            <xsd:element ref="ReasonCode" minOccurs="0" maxOccurs="1"/>        </xsd:sequence>    </xsd:complexType>

Both of these patterns can be a problem though for various tooling to handle. The reason is that the tools tend to generate extra content models to handle the schemas. In particular data binding frameworks will tend to generate thousands of classes. Which in turn can be problematic to deploy and maintain.

STAR is currently looking at implementing a Hybrid approach for STAR 5. The hybrid approach will maintain backwards compatibility with the existing XML Schemas from an XML Validation standpoint, but will hopefully help reduce the number of classes that are generated.

The XML NDR by UNCEFACT that STAR follows describes the hybrid approach as follows:

    <xsd:complextype name="ApplicantType">        <xsd:sequence>            <xsd:element name="PrimaryDriverIndicator" type="udt:IndicatorType" minoccurs="0" maxoccurs="1">            <xsd:element ref="ResidencePeriod" minoccurs="0" maxoccurs="1">            <xsd:element ref="ApplicantParty" minoccurs="1" maxoccurs="1">            <xsd:element ref="ApplicantDemographics" minoccurs="0" maxoccurs="1">....            <xsd:element ref="ReferencePerson" minoccurs="0" maxoccurs="unbounded">            <xsd:element name="GSTRegistrantIndicator" type="udt:IndicatorType" minoccurs="0" maxoccurs="1"/>       </xsd:sequence>   </xsd:complextype>

Basically anything that is a Component is still treated as a global reference. Anything that is a Field is locally defined within the component that it appears. This should help reduce the number of classes that are generated by various tooling as the local elements will be mapped more directly to fields or attributes in the appropriate language.

The benefits of the design change will vary depending on tooling support. It is the hope though that the design change will help ease some of the integration burden. This is planned to be available to STAR members during the upcoming Draft and Milestone releases for STAR 5.3.2. Other community members will see the proposed design changes in STAR 5.3.4 in March 2010.

Traditionally the STAR Architecture Workgroup has been focused on the delivery and maintenance of the STAR Transport packages:

• STAR Web Services – specifying the Generic and BOD Specific WSDLs.
• ebMS – covers the STAR specific profiles for ebMS 2.0 (ebXML).
• Transport Package – covers the overall direction and guidelines regardless of the transport being used.
• STAR Web Services Quickstart Guide – samples and available tooling that can be used to implement the STAR web services guide.

Over the last several years, most of the work has been concentrated on the Web Services portion. In the past the name of the group was the Transport Workgroup, but that was changed in recent years. However, the overall direction didn’t change with it.

I’m now managing the Architecture Workgroup and Jason Loeffler from Karmak is the workgroup lead. Together we are trying to broaden the horizon. We want to make it more than just working on specifications. Architecture around standards covers more than just the transport layer. It covers design and implementation of the standards. Security. Integration of various tools and technologies.

We want the group to evolve into an information resource for both STAR members as well as the general community. So I’m asking for some community input. What do you want to see from the workgroup. What is missing from an architecture standpoint that STAR members should be trying to address? Collaboration is what helps drive standards forward, now is the time to weigh in on the direction that the Architecture Workgroup at STAR should take. Please leave a comment here with your ideas and suggestions.

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.