The STAR eXchange

“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

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.

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.

One of the items we hear consistently is that XML is to slow. This can mean many things and affects people differently depending on the tools that they use. At this past technical session, I gave a presentation on “Gossamer and You”. Gossamer for those that do not know is the Big Hairy Monster from the Warner Brothers cartoons. The point being is that XML is often treated like the monster under the bed. The gut reaction from programmers is to go with the most common form of working with XML. Data Binding. Unfortunately this can cause many of the problems that XML is blamed. The problem may not necessarily be XML but in the way we process it.

The Basilage Markup conference is having a “International Symposium on Processing XML Efficiently: Overcoming Limits on Space, Time, or Bandwidth”. It will visit many of the myths about XML and ways to over come these problems. The conference is being chaired by Michael Kay the author of the Saxon XSLT processor. If anybody is attending the Basilage conference and attends this forum, please post a comment to this entry and share what was learned.

When we asked users to submit testimonials describing the value that they have derived from STAR standards, we were not exactly sure what type of responses we would get, if any. It has been my experience that so many companies, believing the myth that there are competitive advantages in data formats, prefer to keep their implementation of STAR standards close to the vest – even their successes. This is a myth that, even after 9 years, STAR is still trying to debunk.

Myths aside, I have been pleasantly surprised with the responses that we have received thus far. We have received testimonials from various retail system providers including IPS , PBS Systems, and RouteOne. We have also received our first OEM testimonial from Ford Motor Credit Company, and even a testimonial from the Motorcycle Industry Council (MIC) whose members implement STAR.

The benefits noted in the responses vary with some focusing on the overall benefits of STAR including, as MIC puts it, “an opportunity for substantial cost savings when building and supporting data communications throughout the value chain”. While others, such as IPS, focus on the percentages of increased efficiencies and reuse. According to the IPS, testimonial there was a “50-60 % time savings” and code and data reuse of “80% or higher” through the use of STAR standards.

While I am incredibly grateful for ALL forms of testimonials, I must admit that I am a sucker for numbers. When an implementer tells me that STAR standards have saved them close to 60% in time savings and upwards of 80% in code and data reuse….well my heart goes all a twitter. There is a certain sense of a job well done that comes from knowing that STAR standards really do provide value to the community, and in this current economic “climate” (ahhh… think of the trade winds of the Hawaiian islands) showing value is paramount. And really, that gets back to the original purpose of these testimonials.

As an architect of the standard, it is not part of my job to actually implement what I have created. I design and code the standard based on member input and then, with the membership’s blessing, send it off into the world to create value. So to a certain extent I work in, dare I say …, a vacuum? I know it sounds awful but it is reality. I will not know the true value of what I have created until I receive feedback from implementers, i.e., testimonials.

So the next time you are able to reuse code, or you saved yourself time because you are implementing a STAR standard, think of me…and think of the STAR community….then go directly to STAR and submit a testimonial!