By Dr. Santiago Chumbe, Chief Technologist - JournalTOCs, Institute for Computer Based Learning, School of Mathematical and Computer Sciences, Heriot-Watt University.

JournalTOCs has gone from being a research prototype to a service funded by its customers. In this article I describe how adopting agile development and customer-centric approaches to our service development helped us become self-sustaining. This change was helped in part by our work with the Software Sustainability Institute.

When I learned that the one of the best performing CEOs in the world, according to Harvard Business Review magazine, is Amazon CEO Jeff Bezos, it brought to mind blogger Steve Yegge's infamous rant about Amazon (and Jeff). At that time, having worked for six years for both Amazon and Google, Steve concluded that Amazon did everything wrong and Google did everything right. He criticised Jeff on just about everything, but he did admit two things. Firstly, Jeff had had the vision to mandate that the only allowed inter-communication between Amazon systems was web services (APIs). This groundbreaking mandate was made in 2002, and Amazon has since been hailed as one of the most successful internal service-oriented architectures in the world. Secondly, Steve implicitly admitted that Amazon did better than Google in terms of customer experience. If you have used Amazon you may know what I mean (or you may be convinced by Amazon.com Core Values: A Customer Experience Obsession and How Aunt Ammy Gets Her Free Lunch: A Study of the Top-Thousand Customer Reviewers at Amazon.com). Jeff managed to put into the mind of his software developers that their work was about delivering value to customers and making users happy.

The JournalTOCs team were lucky to be alerted by our pals from JISC's Centre for Educational Technology and Interoperability Standards, CETIS, to Steve's infamous internal memo almost immediately after it was put on the web. It happened just a few months after we'd implemented recommendations from the Software Sustainability Institute to help in our daunting jump from project to service. The guidance received from the Institute was crucial and opportune. At that time, we were receiving the first expressions of interest from our early customisation adopters. We were doing business! The Institute helped to put us on the right track to become a service by helping us make our website intuitive, usable and attractive. Now what we needed was to become a real service. Encouraged by what we learned from the Amazon CEO, we took the decision to make the effort of using APIs internally as much as possible, and to adopt a customer-centric business model where agile development was the norm for dealing with any input received from any user.

Since then, we have been using internal web services and the results are very good. It is true, externalising your internal applications requires discipline, time and effort, and we have always been tempted to just use direct calls to common functions or to inter-communicate between applications at the database level. To be honest, a few times we have cheated. For example, we had to compromise for a fast cross-journal lookup application since using APIs would have been overkill for the service, particularly when we had a customer waiting. This is probably why we are not Amazon.

The same can be said for implementing a customer-centric agile development strategy. It requires a lot of hard work. From the start, the typical strategy of leaving user inputs for scheduled ongoing cycles of development, where new versions are released once or twice a year, was replaced with immediate development and release of new few features or bug fixes on demand. This strategy is challenging to implement when the demands from and expectations of your customers can vary widely. We would probably have given up on using it if it weren't for the happiness of our customers and, consequently, their loyalty.

Recently we have had four contrasting customers: a large pharmaceutical company, a hospital library, an agency of the United Nations (UN), and an aerospace research centre. Our challenge was to deliver a cost-effective current awareness service (CAS) tailored to satisfy the specific requirements of each of these different organisations. Their demands are quite different. The pharmaceutical company requires immediateness - their staff need to be made aware as early as possible of the results of clinical trials involving competitors' products or new scientific discoveries relating to their own products. The UN agency's main concern is convenience, where anyone should be able to manage their own alerts with little external support. To the aerospace research centre what is really important is transparent integration of the CAS with its own services and library platforms. For the hospital library what matters most is enhanced super-user accounts for the CAS administrators because their patrons, mostly professional medical staff, are consumers of specialised information who are too busy to be able to set up and manage their own alerts. I will venture to list what we think were the key factors for the successful deployment of such diverse type of customisations:

• From the start, each request received from a user was analysed and classified as either a wide functionality or common feature, or a specific functionality or exceptional feature. This step was important because it determined whether we needed to develop a new application (API call) that was going to be part of the core service or a plug-in (add-on) that could be enabled only for specific users.
• Short and frequent deliveries and quick responsiveness to change. Once a request is received, the idea is to release something small but robust in the shortest time possible so the user has something to test and see that their request has been given priority. Once the process has been initiated, the problem is turned into a new feature making sure that the customer feels part of a co-creative innovation process. Through incremental cheap-to-revert-back deliveries, the final feature gradually gains shape. So far, the results are positive because the development is done with the customer in charge, and with respect for their knowledge and without hesitating to undo things.
• Customer engagement, including pleasant and continuous communication with the user, without pestering them. We have learned that in this business loneliness is even worse than being penniless. It is good to be contacted by a customer even to tell us that our service is not relevant to them, because, by experience, we now know that that is an opportunity to start a conversation and sometimes to secure one customer more!

In short, customer-centric and agile developments are pillars of JournalTOCs sustainability. "Your best investors are your own customers", Dr. Uday Phadke of Cartezia once advised me, when we were discussing the difficulty of finding funding for JournalTOCs. He was right. JournalTOCs is now almost 100% funded by its own customers.

However, I cannot say in all honesty that in every case JournalTOCs has had a good customer experience. As a consequence of doing business without a robust plan, and especially when the service was developing from a prototype, our experience has shown that we can improve our customer experience. This is part of the process from simply doing business to being in business. We need to sort out the processing of new contract agreements. Currently this is done manually and, as a result, it is prone to human errors, delays and additional costs. Because the particular constraints we have as a result of being part of an academic institution, our email service is not at the commercial level expected by our users, who sometimes find it difficult to contact us or too slow in delivering urgent messages such as password reminders that are expected to be sent and received immediately. The processing of invoices and payments is another area of the customer experience that we also need to improve. In addition, real-time information on usage statistics is becoming a must for customer satisfaction. To sum up, we have learned that technology and delivery of service are not enough to guarantee the sustainability of JournalTOCs. Being in business is the new challenge that is making it even more exciting working with JournalTOCs.

When Jeff forgot to take away his "NRF 2012 Retailer Of The Year" Award at the podium, after calmly acknowledging the hard work of his teams (including software developers) for the success of Amazon, few probably realised the weight and value of his very short speech - that innovation, web services, customer-centric and agile development really, above all, requires hard work.