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.

The STAR eXchange has a new home, and new look, but we plan to continue to provide the same great content.   Blogspot served us well, but our needs for the blog out grew what the free service provided us.   The new blog is being self hosted by STAR, and is running the latest release of Wordpress.    This provides us with much more control over the look and features of the blog, and will allow us to further customize the site to meet the STAR communities needs.

Several of the features of blogspot have been retained.  You still have the option to get notifications via email, and can still subscribe via RSS feeds with your favorite feed reader.    If there are other items you would like to see, please feel free to register with the site and provide us some feedback.  We would love to hear what you think.

One of the most difficult things from a Standard organization aspect is getting people to request changes to a standard. STAR has been pretty good about this over the years, and in many ways I contribute it to the adoption of Agile development and management techniques. In general, people do not contribute or request modifications because they feel it takes too long to get their requirements met. STAR members can get a turn around in as little as a day, sometimes even within an hour. How is this achieved?

One of the technical development techniques that has come out of Agile development is the concept of Continuous Integration. Basically, everybody that is developing on a standard and creating its artifacts are integrating continuously. As code or changes to models are checked into source control, builds are started to generate and check that all artifacts are being produced as expected. Below is a snapshot of an early setup of the STAR Hudson continuous integration server:

STAR actually has about 6500 unit tests that run to check the quality of the XML schemas we produce. As the developers make changes and check in their changes, the Hudson build server monitors for new changes and then runs a build. If a build breaks, notifications are sent out to those that broke the build. This way we catch integration issues early instead of late when they are more difficult to debug and fix. The Hudson instance is made available to STAR members so that they have the ability to pull down changes at their convenience.

Providing your members and community with development snapshots helps improve the overall quality of the standard being produced, but also helps to eliminate one of the road blocks of getting community members to contribute or request changes. Shortening the overall development cycle is something that standard organizations need to do, as adopters can not wait years or even months to use what is being produced. Business moves ever faster, and we need to adapt or get out of the way.

Check out the list of countries that have visited the STAR XML Spec page since January 2009:

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: