Category Archives: enterprise

Open APIs Can Unleash the Beast

Caged Tiger

The engine that will power the future of banking is fueled by Open APIs.

At Continuity, our mission is to relieve banks and credit unions from the increasingly untenable burden of regulatory compliance. As an integral part of the Compliance Core™, Continuity’s Assurance program provides regular, independent assessments of the state of compliance within your organization.

We put technology to work in order to make compliance easy. But no matter how efficient or effective an engine we build, it can’t run (or add value) without fuel. In the case of our Assurance program, data is that fuel. Everything is data, and auditing is just data validation.

One of the challenges we face is that the data of financial institutions is often locked in impenetrable black boxes built decades ago. Technology may have evolved considerably since then, but many bank cores remain comparatively stagnant. We can’t power our engine without a fuel pump.

On the surface, it would seem that the companies who sell these core banking systems have little incentive to modernize. After all, their customers are heavily reliant upon them in order to keep operations afloat. Ceding even a small amount of that control could ultimately translate to a decrease in recurring revenue. But similarly to what has occurred with the decaying legacy systems of other sectors like education, modernization and openness bring many benefits that might not seem obvious at first.

While the ever-increasing regulatory burden might be a mere annoyance to some of the core provider’s bigger customers, it can be a credible threat to the continued health of smaller community financial institutions. If the burden of compliance grows to a level that forces leadership to reconsider the long-term viability of the business, the core provider might lose a customer. Now rather than a decrease in revenue from that customer, the core provider realizes none at all. Suddenly modernization and openness don’t seem so inconceivable.

When was the last time you switched TV or Internet providers for your home? Do you remember how you were feeling about the old provider at the time? What about the new one? Did it feel like a sucker’s choice between the lesser of two evils? Would you have bothered with the inconvenience of switching if the old provider could have responded more effectively to your needs? Banks don’t migrate from one core provider to another very often, but it does happen. And a bank that’s unhappy with what they’re getting (or not getting) from their current core provider is more likely to migrate. Financial institutions are increasingly demanding more flexibility in their technology to improve compliance management. If a particular core provider emerges as a leader in technological flexibility, it achieves differentiation through innovation. It’s no longer in consideration among lesser evils… the customer’s choice becomes clear.

Another factor to consider is data security. Even selectively opening up a bank’s core systems would increase the likelihood of a data breach, right? Not so fast. Think about the way in which traditional audits utilize bank data. What safeguards are in place to ensure data security with the traditional process? Data must first be exported from the core system, typically in printed form. It may then be scanned, faxed, emailed, or shared via various online collaboration tools as the auditing process moves forward. By that point, a number of potential security compromises have already been introduced into the workflow. There are multiple points of potential failure along the chain, many of which are entirely beyond the institution’s control.

Now let’s return to the challenge of fueling our engine with data. We’ve already established that closed systems are starving the engine. Consider the modern alternative of an application programming interface, or API. An open API is our fuel pump. It’s predictable and consistent. Precedent already exists for secure third-party connectivity in the realm of personal financial management; web-based tools such as Mint and FinanceWorks are trusted and used daily by millions of people. With a properly-secured API utilizing strong encryption technology, there is a single point-to-point connection between the bank and the intended recipient of the data. Both the data channel (think: road) and the payload (car) are secured. The open system is actually more secure than the closed one. Our engine now has the fuel it needs to deliver unprecedented value to our clients.

Financial institutions must adapt to survive. Their core systems should do the same.

Sakai Mobile Usability

Case Study

Qualtrics on an iPhone
Pilot application on iPhone

In January 2010, Yale’s Center for Media and Instructional Innovation conducted a survey of mobile devices used to access Classes*v2, the University’s learning management system built on the open-source Sakai platform. The results of this survey and a series of related discussions prompted further development, and in 2011 the Classes*v2 team completed an alpha version of a mobile web interface. A decision was made to open it up to a select group of pilot participants during the Spring 2012 semester. Our goal was to gather student and faculty feedback to inform ongoing development efforts. With no formal usability training, but plenty of gritty do-it-yourself determination, the team set about conducting a large-scale usability study.

The process of selecting and gathering feedback from the pilot participants was a multi-phased approach:

1. Open call for volunteers

Upon logging into Classes*v2, a message invited interested users to apply to be part of the pilot.

  • Sample language we used:
    • “Help us pilot a new mobile interface for Classes*v2!”
    • “Got a mobile device? Help us pilot a new mobile interface for Classes*v2!”
    • “The Classes*v2 team needs your help to pilot a new mobile interface!”

2. Selection of pilot participants

Pilot applications simply required the user’s identity as well as which Classes*v2 tools they used regularly. Since the alpha version of the mobile web interface only worked with some tools, the team wanted to ensure a good fit between these parameters and the usage habits of potential pilot participants.

3. The call to action

We sent accepted pilot participants an introductory email:

“Thanks for your interest in the Classes*v2 mobile pilot. As a first step in optimizing Classes*v2 for mobile devices, we invite your feedback on an alpha release, which includes views of several key tools.

To access the mobile view, please visit …

We’ll be sending you a quick survey in several weeks to learn about your experience. Your input on what works, what’s missing, and what needs to be tweaked will be incredibly helpful as we continue building the mobile view.

We appreciate your participation in the alpha pilot and look forward to your feedback.”

4. Gathering post-pilot feedback

After the month-long pilot period ended, we sent participants a survey about their experience. Out of 648 participants, 220 (34%) responded to the survey.

“Thank you for your participation in the pilot of the Classes*v2 mobile alpha. Please take a few minutes to complete a quick survey on your experience with the pilot. We’re grateful for the feedback, and confident that it will help us further develop and improve the interface.”

(The final survey was individualized for tracking responses.)

Here are the results of the survey, if you’re curious. Included are some lessons learned and signposts that we used to prioritize development efforts.


  • Well over 500% mobile activity increase.
  • Over 300% increase in pages per visit during mobile sessions.
  • Over 300% increase in average time on site during mobile sessions (from roughly 20 seconds to about 90)
  • 25% increase in new mobile visitors
  • 57% decrease in the mobile bounce rate (a good thing!)
  • A focus group with student interns from the Instructional Technology Group to further refine the feedback we received
  • Coverage in the Yale Daily News
  • Users of phone-sized devices are now automatically redirected to the mobile web interface when logging into Classes*v2.

Lingering Questions

  • How might we have streamlined the process?
  • Was there anything missing from our approach, bearing in mind the scale of the effort?
  • What should we do when frequently recurring suggestions are seemingly impossible to deliver?

This post was written as a contribution to Users First!, a November 2013 Unconference at Yale University

Cloud Integration Shootout: Office Suites part 2 (the Mac conundrum)

Users of modern Macs face an unfortunate dilemma when it comes to cloud-integrated office suites. Google Cloud Connect is not available for Macs; the company blames Microsoft for their lack of support for open APIs in the Mac version of Office. And the OOo2GD extension for OpenOffice (and friends) doesn’t work properly on any version of OSX after 10.4 (Tiger) due to Java issues. What this effectively means is that true Google Docs integration is simply not possible at the current time. Users are left with two equally cumbersome and unappealing options.

Microsoft Office 2011 for Mac includes native (though rudimentary) hooks into Microsoft’s own cloud infrastructure. Applications in this suite offer the ability to “Save to SkyDrive” or “Save to SharePoint.” There is not, however, support for automatic synchronization. It is still a manual process, an extra step in your workflow which means this is not true integration. And for established Google Docs devotees, it requires a separate collaborative space to be created and maintained.

NeoOffice is a Mac-specific fork of OpenOffice. I tested version 3.2 Beta Patch 1. Through a feature known as “NeoOffice Mobile,” it does provide support for saving to Google Docs; but again, true integration eludes us here. Users are inexplicably required to create a separate NeoOffice Mobile account, even if they’re only using it for the ability to save directly to Google Docs. The account creation process is tedious (you are asked to donate money), and credentials do not appear to be saved between sessions. So when you quit NeoOffice, and then start it up the next time, you have to separately login to both NeoOffice Mobile and Google Docs. And you have to do this every time. There’s no automatic synchronization, either.

The elegance and seamlessness of both Google Cloud Connect and OOo2GD are sorely missed in OSX Leopard and Snow Leopard. Hopefully someday soon, one of these options will be available, or perhaps an entirely new solution will present itself.

Cloud Integration Shootout: Office Suites

google cloud connect



Analysis: LibreOffice 3 + OOo2GD versus Microsoft Office 2010 + Google Cloud Connect


The following is a comparison of cloud integration options for two popular office suites. Both options allow synchronization of documents, spreadsheets and presentations to Google Docs. Both options allow for either automatic or manual syncing, depending on user preference.



LibreOffice 3 + OOo2GD advantages:

  • None of the costs associated with Microsoft Office
  • Multi-platform (Windows, Mac, Linux, many other Unix variants)
  • Supports other cloud services besides Google Docs (Zoho and generic WebDAV)
  • When used with user-controlled WebDAV, allows for total control/ownership of all data
  • Translated into many other languages besides English


LibreOffice 3 + OOo2GD disadvantages:

  • Some problems with certain versions of Mac OSX (seems to be Java related)
  • Needs Java 5+ to work, on any platform


Microsoft Office 2010 + Google Cloud Connect advantages:

  • Allows user to disable Protected View for documents synced with Google Docs
  • Allows application-level configuration of a proxy server to access Google Docs
  • Does not require Java


Microsoft Office 2010 + Google Cloud Connect disadvantages:

  • The cost of the office suite
  • Limited to the Windows platform
  • No option for end-to-end control and ownership of all data
  • Does not support any services other than Google Docs



The most impactful factors to consider are the platforms being used by all potential collaborators, and any enterprise requirements for internalization of data.

If you’re dealing with a heterogeneous client environment, OOo2GD is the way to go. The interface looks the same across all platforms it supports, which simplifies training through consistency and uniformity; the only caveat is that you may have problems if any Mac users are running one of the versions of OSX affected by the known Java issue. If you’re an all-Windows shop, none of the above is a concern, and either option will work fine.

Some companies are hesitant to embrace cloud computing because of the inherent risks of having your data stored on someone else’s hardware, in a physical location you do not control. This would be a show-stopper for Google Cloud Connect, because all synchronized documents will live on Google’s servers. Assuming your company sets up its own internal WebDAV instance, which could be accessed by employees via VPN, OOo2GD would provide a completely self-owned and internally-controlled solution. This would allay many of the typical fears associated with cloud computing.