The STAR eXchange

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:

At STAR we seem to be cutting edge at times. We often get asked how we do so much with the amount of staff we have? We seem to produce higher quality deliverables, faster than most organizations with three times the staff. The key in many ways is to look at your processes, but also look at the tools you and the community use as a whole.

In STAR’s case we have shown that good quality sites, and materials can come from leveraging the power and diversity of open source and open standard communities. We do not only consume but we contribute back as well. STAR staff leverage and manage many web sites. Some for the community as a whole and some for the benefit of the membership. Regardless of which community we are focusing on we expect high quality and stability from the products we choose. The following is a summary of some of the open source projects we leverage at STAR.

• Joomla
• PMWiki
• LimeSurvey
• Luntbuild
• Corga
• eXist
• Ant
• Eclipse
• MantisBT
• The DocBook Project

As a non-profit organization we have to watch how we spend the memberships money so that we can provide the quality of service they expect. Leveraging open source projects let’s us stretch that dollar so that it goes farther and provides more value.

Some of the open source projects STAR has contributed back to in the way of code and time are:

• Eclipse – extensive contributions to Web Tools Platform. In particular the XML related tooling.
• PMWiki – bug fixes, and extensions.
• Mylyn-Mantis – an eclipse plugin for interfacing with MantisBT
• XML Schema Unit Testing – an agile testing framework for verifying XML Schema requirements.
• XMLUnit – a testing framework for testing and verification of XML files.

Consuming is the easy part. It takes real effort to spend the extra cycles to contribute. However the contribution is just as important if not more important than the consuming. With out contributions your projects will ceast to exist.

Standards development regardless of the organization is the same way. If there are more consumers than there are contributors to help support the system, then it will eventually ceast to exist. So if you support or use standards produced by STAR, AIAG, OAGi, ACORD, HRXML, or any other organization consider donating some time, become a member, or help promote the use of the standard. Every little bit helps. We extend on this ecosystem concept in the upcoming edition of the STAR eXchange Newsletter, if you haven’t already please consider signing up to receive it.

A recent blog entry by Ed Merks, had an interesting quote:

The maturity of an organization’s policy around open source tends to progress from deny, use, contribute, champion, and finally value co-creation.

While Ed is talking about how a commercial company may eventually evolve through the various stages in open source adoption, it equally applies to how a company goes through and adopts open standards. In STAR’s case, it is the common pattern that we see when talking to various companies about the use of STAR and how they are deploying it within their businesses.

1. Deny – many feel they don’t need the standard, that their business works just well enough with out it. In fact there is some fear that if they use a standard it won’t give them the competitive advantage. This could be called the FUD principle as well (Fear, Uncertainty, Doubt).
2. Use – somebody finally uses the standard, they implement and deploy it. They start trading with another client/partner, with the same standard. Find they can re-use or use the exact same implementation they did before. Freeing time and resources for other “added value” features for their customers.
3. Contribute – having learned the value of using the standard, they want to give back to the organization and help address other areas that are pain points. They may join the organization that created the standard, start an open source project that implements the standard, or help others to implement the standard. There are many ways to contribute.
4. Champion – after having experienced the advantages and ROI on using the standard and deploying more, some move to the champion stage. Helping to bring others into the organization, actively participating in the community, and going beyond and above the call of duty. Champions are rare. They look beyond what is best just for themselves, but what is best for the community.
5. Co-Creation – this is the stage we have yet to reach as a community. In some aspects getting your customers involved with the creation of your products is the driving point of co-creation. In the way of standards, it’s bring those pain points that are common back to the community, and working together to address them and add value for the customer.

So the question I leave you with: What stage is your adoption of standards?