Go Big By Going Small

Bringing in a new technology requires a workplace evolution — that if done carefully, avoids the revolution! My work in Consulting at MarkLogic brings me into daily contact with our customers, so I’m often asked for the “real” scoop on how each uses our product – -and lessons that can be learned. Over the next several months I will focus on individual companies and analyze each’s journey under the category:The Real Scoop.

SDO A Standards Development Organization (SDO), publishes a website, journals and books, and runs community initiatives such as balloting and peer review. Although these products often use the same content, they are walled off from one another and much of the work gets repeated. One of the factors driving the SDO to change is the unscalable nature of its website’s update process. The site’s architecture is based on thousands of static, pre-cooked pages. Its rigidity limits opportunities for visual redesign, and locks the team into a content update cycle. Instead, they want to freshen up their layouts and offer new content as soon it’s available.

More importantly, the organization wants to revitalize its way of doing business to meet new market challenges. It needs to create new products in new bundles, and market them to a new audience. For instance, it wants to use its content in a Learning Management System (LMS) and build courses around it. (Another great opportunity to leverage MarkLogic, which I’ll talk about in a future post.)

So with all this big-picture ambition, how should our SDO start? By thinking small. Yep. I first learned to think small many years ago, when I worked on the team that automated photo editing at The New York Times. Start any huge endeavor with dozens of stakeholders by identifying a discrete end-to-end process you can plug in behind the larger workflow. (Back then, it was delivering up-to the minute Olympics photos from Barcelona to the Sports Desk.)

With our SDO, the first step was to inventory all its content. In keeping with my “think small” directive, I took a page from my colleague Matt Turner and at our first meeting had the SDO team shout out the assets while I built a simple PowerPoint deck. I am talking bullet-points only, no animations (or cat videos.) This deck, projected on the conference room wall, eventually cataloged about 50 kinds of content in use across the organization—  pdf standards, InDesign journal articles, MathML snippets, arcane artifacts of peer review. We continue to annotate and refine as MarkLogic’s work proceeds at the SDO. It’s a living business analysis, most of it created in that initial four-hour collaboration with the SDO.

The small team— MarkLogic Consultants and SDO stakeholders— who created that inventory, went on to unpack a manual syndication process that delivers a metadata payload to a third party, who builds the SDO website’s static pages.  MarkLogic could automate that syndication process with no impact to the upstream editorial or downstream site-creation. We drew this on the whiteboard, with the best-colored markers going dry first, using our hands for erasers. A content model emerged. Each item the SDO wanted to syndicate was represented by a collection of files on the SDO file system that MarkLogic would ingest, along with some additional metadata from its Oracle system, which MarkLogic application code could request via a RESTful API. All of that was easily de-coupled from the multi-stakeholder editing and website creation process, and could be accomplished with a small cross-discipline team.

The leveraged benefit to the SDO is that, as a result of this “think small” implementation, their entire body of standards is in MarkLogic, and they are ready to be reused in new applications.

Core Capabilities

Ingestion

MarkLogic’s capability to apply sophisticated logic during ingestion allowed us to handle varied SDO data types against an evolving specification, and even enhance data quality as we brought in content. MarkLogic’s real-time indexing, and schema-agnosticism allowed for rapid iterations on the content model. We pulled content in, developed, designed, and replaced content many times a day. Sometimes that was in response to our own testing and profiling, and sometimes that was in response to changes in the application.

Application Development

MarkLogic’s application development platform allowed us to respond immediately to changes in the content model. Our application developers’ API is deep, wide, and documented with clear examples and recipes. Our REST support allows us to put up lightweight code you can call from any language and our ability to respond with JSON or xhtml allows you to present your results with a minimum of fuss, or with panache and polished elegance depending on your needs.

Conclusion

MarkLogic’s ability as a rapid application development platform allows small teams to leverage small applications into major content opportunities.