Happy New Year, friends!

Here we are in January, so named after the ancient Roman diety, Janus.  It turns out that Ronin Technologies has a lot in common with that ancient fellow.  Read on and I'll tell you why.

Janus was not just the god of doorways and bridges in their concrete forms, but in their abstract concepts.  He represented transition, bridging past and future, bringing together one vision to another.  If we look at him in a modern light, Janus was the god of integration and middleware.

Everything we do at Ronin Technologies is about working smarter by standing on the shoulders of giants and helping our customers build bridges across their data and applications.  This is true with the open standards we participate in (such as RETS and MISMO), the technology partners whose tools we use to integrate data (Talend) and the languages and frameworks we use to develop applications faster and cheaper (Groovy and Grails) while leveraging existing legacy code.

Like Janus, we have a clear view of the past.  In our case, this past represents the lessons learned over 2 decades' work in enterprise application development.  It encompasses the tomes of the masters, i.e., "Code Complete", "Rapid Development", "Head First Design", and of course, "The Pragmatic Programmer: From Journeyman To Master".

Janus also sees far into the future. Ronin Technologies' works with the leading edge and tracks the bleeding edge. The majority of our current implementations use Groovy and Grails.  We are advocates of the SaaS philosophy. We have been following developments in the semantic web and cloud computing.

I won't go stretch the Janus analogy as far as to claim that Ronin Technologies represents the middleground between civilization and chaos, but I will say we've often found ourselves thrust into the position of hammering out a workable compromise between extremes.

Ronin Technologies:  cross the threshhold this January.

Felix sit annus novus.

I am Paula O'Brien, and I have been involved with RETS since 1999, developing early adopter technology around the 0.9 version at the largest broker in NE Ohio. Beginning in 2002, I was contracted by Dale Stinton (then CIO) to assist NAR in RETS adoption through the creation of tools such as reference implementations for RETS servers and clients. In 2003, Bruce Toback and I created the RETS compliance testing program. I have served RETS as chairperson of compliance from that time through the present.

As a thought leader in the RETS community, I have advocated decoupling transport from payload, extending RETS to support uses beyond bulk listing downloads, and to outreach to other real estate standards bodies. Much of my outreach and research is reflected in the concepts expressed in the 2006 RETS2 specification, which I co-authored.

As a long-time developer of both client and server-side RETS, I have unique insights into the strengths and weaknesses of the standard. I have a history of getting things done, and I am a team player who has served on workgroups and participated in projects with many members of the RETS community and current BOD.

If elected, I will continue my commitment towards developing a tactical and strategic roadmap for RETS, and ensuring that this roadmap is followed and progress is reported to the community. Our biggest technical challenge is future-proofing our current standard, so we have a solid core RETS that can be extended without breaking backward-compatibility each time it is versioned. It is time to jumpstart our standard and get things moving again - the standard has sat idle for nearly 3 years and Web 2.0 has passed us by. What else are we missing out on if we continue to stand by?

It is an honor to be nominated. Please vote for me - help me help you make RETS a standard we are all proud of, where all your voices matter.

Paula O'Brien
Business Integration Specialist
Ronin Technologies
http://www.ronintech.org

I want to take this opportunity to extend a round of applause and thanks to the members of the RETS Compliance Workgroup.  These folks have donated countless hours of volunteer time to review requirements, run tests, and resolve issues to help get the new compliance tool into production. 

This has been one of the longer running, concentrated efforts of volunteer time in my history of involvement with RETS.  This group has met regularly for the past year and shown tremendous dedication, patience and perserverance.  They are a credit to their companies and to the RETS community.  And I, in particular, think they deserve a standing ovation.

Matt Cohen has posted another article in his series on "Completing RETS".

It contains some very interesting responses to his recent survey, and, as always, maintains a positive and professional outlook.

So, how do we move forward in RETS?  I have a few ideas for getting unstuck.  First we focus on the BUSINESS side of things.

1. Stand on the shoulders of the past.  Let's dust off those things that we've put in the metaphorical glove compartment:  the RESO governance document and the old RETS Roadmaps.  Enforce the governance document so we can operate effectively as a standards organization.  Review the roadmaps to find out our previous destinations and why we were headed there.
2. Gather requirements.  Matt's survey indicates some major areas of concern/interest.  Start with these and flesh out use cases. Include, where appropriate, items from old roadmaps.
   
3. Prioritize the requirements.
4. Use requirements to create strategic goals, and from those strategic goals, define tactical ones.

This becomes the RETS Business Roadmap.  This roadmap is then presented to the general assembly FOR A VOTE.  

Once the general assembly ratifies the business roadmap, we involve technical folks to discuss how RETS gets from where we are to where we want to be. This requires an architecture group.  It's what the Standards Committee was supposed to be, as opposed to a group that validates the format of RCPs. The architecture group devises a plan to adapt the RETS standard to meet the requirements of the business roadmap.

This plan becomes the RETS Technical Roadmap.  This roadmap is then presented to the general assembly FOR A VOTE.

And then?  Then the workgroups are re-evaluated and chartered with specific goals to move the standard along the technical and business roadmaps.  These workgroups create RCPs based on their charters (which are based on the roadmaps) and everything runs according to the governance document.

Along the way, NAR will have to loosen its purse strings and fund some of these activities.  NAR should do this by providing the RESO BOD with a budget (again, see the governance document).  The RESO BOD then would create RFPs, put them out publicly for bids, review responses, and designate who receives funding to do the work.   Everything open and transparent, the original intent of the governance committee.

Bruce Toback, the first technical chair of RETS from 1999 through to his untimely death in 2005, was a good friend of mine, and a visionary.  He moved mountains to make RETS a reality.  I don't want to let him down by letting RETS remain stuck in neutral, or, worse, slide backwards.

Anyone remember "The Charge of the Light Brigade"?

Well, if you've been involved in the compliance workgroup for the past year, you can relate to it.

We are finally at the release candidate stage for the new compliance tool...if final QA testing goes well, this means we are just scant weeks away from flipping the switch for MLS Associations to come in and test their RETS servers.

Once this is behind us, I would love to begin discussing issues such as usability and interoperability, especially as they relate to the new transactions and schemas that are in progress.  We need to make sure the things going into the RETS spec are in line with modern toolkits and business requirements.  Something that's testable but not usable or interoperable is just much ado about nothing.