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.

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.

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 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.

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.

An interesting quote from Bob Sutor’s most recent blog entry.

….understanding of the value of [sic] and a preference for truly open standards must be both part of the policy of and inherent in the common practices of an IT organization. Technologists and IT administrators must live, breathe, think and reason in terms of open standards. They should feel repelled by dictated or faux-open specifications that were developed without balanced community involvement and innovation.

Read more about his views on Open Standards at his blog.