The STAR eXchange

Standards are one of those things where they seem to take years to release.   Most organizations tend to release every couple of years and then only a few of the standards may have had new information.   However because of the time lag involved, many users tend to extend the standard to meet their immediate needs.    While STAR releases once a year to the public, STAR members can get immediate updates, evening nightly depending on their needs.   Other standards organizations like OAGIs are starting to do releases twice a year to meed their communities needs.   This is something that STAR may need to look into in the coming years.

The 2010 release includes changes from STAR members that cover additional requirements for Marine, Heavy Duty Truck, and Automotive.    In addition, the STAR Web Services Transport package now includes to levels of compliance.  STAR Level 1 and STAR Level 2.   The goal of the compliance rules are to promote interoperability of the transport.   The prior versions allowed too many items open to interpretation, and created a wide variety of one-off-implementations.  Through the hard work of several member companies, the new STAR transport was created to help alleviate this problem, and promote a truly interoperable transport.

The new specifications become effective July 4, 2010.

1. How to increase membership, revenue and participation.
2. What direction should STAR move? Continue down a technical path or possible change the approach to business type services.
3. Should the standards be “sold”, or remain an Open Standard.
4. It is imperative that the “third party” service providers see value in STAR, and are enticed to join.

Guest speaker Shuvo Bhattacharjee from SAE presented an opportunity to develop a standard integration that would help dealers and OEM’s support the customer at an exceptionally high level by communicating diagnostic information from a vehicle directly to a dealership. This was well received by member OEM representatives.

There were many more ideas and discussions – many with merit and spirit.

Keynote speaker Chuck Allen presented many lesson’s learned from his involvement with HR-XML consortium and shared many lessons learned from working in and with other standards organizations.
At the end of the day the important take-away from this meeting: Member’s are confident that STAR is a valuable organization with much work to do, and effectively will thrive and survive as technology evolves within the Automotive Industry. There are many opportunities to “build the better mousetrap”, and STAR should lead the way.

“STAR is moving forward-STAR is not done!” – that was the main message that was resonating from the STAR Members that were in attendance at the Feb 11th 2010 STAR Meeting.  The comments shared from the STAR Members in attendance at the meeting is a testament to STAR that its members believe in STAR, have seen its value, have experienced the benefits and have realized that STAR is Technology Dedicated to Business Efficiency!  Hearing these comments from the membership community is  a strong show of the value, benefits, effectiveness and work of the STAR Organization!  The STAR Members showed their unwavering support, dedication and participation of the STAR Organization despite the struggles that many of them have faced in the past year.  There are many new and improved projects that were discussed at the meeting – as they say…’our work here is never done!’

The STAR Steering Committee made it clear that STAR has strong goals & projects set for the next couple of years.  The STAR Steering Committee conducted an Open Discussion Forum and shared ideas and asked questions of the members.  This sparked great comments, ideas, discussions from the Members!  The STAR Members spoke…and the STAR Steering Committee listened intently…

Stayed tuned…its going to be a great year for STAR and its Member Community!

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