Business & Technology Nexus

Dave Stephens on technology and business trends

Coupa Technology Stack & Applying the Procurement Discipline

with 7 comments

I'm excited to begin discussing some of the decisions my startup, Coupa, has been making in the technology space. But this is just a precursor – a post to articulate some of our considerations on choosing our technology. I promise a more "meaty" post on the subject in the future.

First let me just say that I love procurement. It's a passion for me and I can't explain why. It doesn't matter if I'm buying a new digital camera, a car, or legal services for a new business – I'm always compelled to source for best value. (Ask my wife.) So when it comes to building our new business, the Procurement discipline is ever present.

As a small software business, besides getting an absolutely amazing deal on refurbished HP hardware, our first big buying decision was for a technology stack. And it's something I didn't rush. We took months evaluating all the tools we could get our hungry little hands on.

Now for me, and I suspect for most of you, the most strategic form of procurement has always been the "make vs. buy" decision. When done right it allows a company to be laser-focused on their true expertise. And with laser focus you can move pretty far & fairly fast.

We had a 5 goals for our technology stack.

#1, of course, it needed to be compatible with our open source beliefs. What we saw & envisioned happening in enterprise applications we also saw happening in the middleware, database, and operating system markets. So we wanted to be smart about choosing something compatible with the overall open source movement.

Goal #2 was to see how much code we could avoid writing. Less code (typically) means higher quality, faster innovation cycles, and reduced customer risk. Though I don't call out productivity here, it is implied. We obviously were looking for a competitive edge since our business plan called for absolute rock bottom TCO for customers.

Goal #3 was the ability to plug in modular components for things we knew weren't our core expertise. We wanted to continually do make vs. buy. Our vision was to slide in best-in-class components as they became available to augment and improve our work.

Goal #4 was a little unconventional – we wanted a technology stack that would appeal to the smartest people we had ever met. But here's the twist – it also had to be accessible to beginners interested in contributing to the Coupa Community. Cliff Godwin, a very senior and gifted Oracle executive once boiled this concept down to the phrase "progressive disclosure of complexity – the simple should be simple & the complex should be possible"

Goal #5 was "dazzle". We needed a technology stack that would support something out of the ordinary from a user interface perspective. We firmly believe people use software they enjoy, and avoid software they don't. Our former Oracle customers & our new prospects seem to agree – they think Procurement compliance programs are far more successful when users like the experience of buying through the system.

After settling on those goals, we developed prototypes (nothing special, just small stuff) in 3 candidate stacks. And the answer became clear very early on, although it shocked me enough that it took some time for me to warm up to the idea. Because I really thought Coupa eProcurement would be in Java.

But as it turns out, Java is so last century.


Written by Dave Stephens

06/22/06 5:15 PM at 5:15 pm

Posted in Coupa, Opinion, Technology

7 Responses

Subscribe to comments with RSS.

  1. “Java is so last century” is written by the guy Steve Hamm, whose profile is available at

    Personally, I wouldn’t be making technical decisions based on such articles.

    The reason for Java not being popular and PHP having several millions of installbase is not because of Java’s inferiority in anyway as a language, but
    because Java hosting solutions are expensive.

    Some history: Back when CGI was the way of the world, people used to write scripts that could run as separate processes and web-servers used to just fork of an external process and get the output of the script directed back to the web client. The advantage with this is modifying a script didn’t require restarting the server. But as internet applications became more and more state oriented, thanks to Netscape and it’s contribution to cookies and https, CGI scripts weren’t really sufficient for writing state aware applications. However, with applications like mod_perl, it became possible to write in-process CGI scripts and also maintain state. In addition, being an interpreted code, it became possible to reload the code as changes are made to the scripts. Neither perl nor php were object oriented to start with. So, a lot of session management in these frameworks used to be through a backing filesystem or into a database with special serialization and persistence which is easy to implement for scalars, hashtables and arrays.

    Now coming to Java’s history. First there was JServ in the industry and then came Tomcat. During the JServ days, it was just a bridge to run Java code through Apache with a mod_jserv module. If one made changes to the code in jsp pages, it was possible to reload the pages. But if one made changes to their POJOs, then one had to restart the server.

    Hosting solutions at the entry level can be offered dirt cheap only if it’s possible to host several domains on the same server. To make it possible to host multiple hosts with Java, JServ was enhanced to support what’s called Zones. Still, any changes made to the POJO code was not easily restartable without bringing down the entire server (I am not sure if people were successful restarting individual zones or by then Tomcat, mentioned below, started picking up where JServ left off). Oops, my website went down because my neighbor wanted to make fix his bug! So, there wasn’t much freedom for Java hosting clients in their ability to start and stop their servers in shared hosting. Dedicated hosting is very expensive, event now (for a good reason), and most mom & pop sites don’t need that.

    Perhaps some of these early day experiences contributed to a better servlet specification which formally introduced the concept of Servlet context. Tomcat, the open source pure java implementation of the entire http web server and the servlet specification started offering the servlet context functionality. By separating system classloader, server class loader and context class loaders, it became possible to restart a context without bringing down the entire server. Infact, while jsp pages don’t need a restart at all and the user can continue even with the existing session, restarting of a context made it possible to test changes to POJO code quickly and efficiently without bringing down the system.

    These days more java hosting solutions are available. But are still usually expensive. My recommendation for anyone is to go with php/perl based hosting if they like coding in those languages or they outsource to get their coding done. But people who like Java, they need to evaluate the immediate gain in hosting cost to the longterm benefit, as applicable to their specific case (like the cost of learning a new language by splitting your precious time between two different languages), to sticking to the Java language.

    Apart from the issue with hosting costs, the development cost was also higher in the past for Java web applications due to lengthy cycles of restarting the entire server. But the concept of servlet context, coupled with the Ant (another great tool written in Java) tasks to compile and stop/start/restart a servlet context makes the development cycle much faster. (What can beat the producitivity of vi-editor, ant, tomcat cycle?)

    A close friend of mine who works for a startup has to wait more than 10 minutes between every code change, inspite using Tomcat, as they bootstrapped the Tomcat server with their own code and messed up the overall architecture. So, even with 6 changes to the code per day (which definitely is an underesimation) would cost the company an hour’s worth of the employee!

    Another friend of mine at a large Internet company tells me how painful it is to rebuild his Apache and/or their custom mod_xyz written in C/C++. But if the business is to serve millions of pages a day (which many internet start ups can only dream to achieve in their life time), the pain and the development cost is all worth it.

    I can go on writing about the various performance benchmarks I have done to compare C, Java and Perl, some really eye-opening computer science papers about why multiple inheritance is much harder to implement and is inefficient, how JIT compilation can actually speed up the code sometimes etc. But then, it’s for people to decide whether they want to go with FUD or Facts and decide the right architecture for their task at hand.

    I usually go with Java for major projects, Perl for simple scripts, Shell for even simpler scripts. These days also using BeanShell to benefit from the knowledge of Java and the convinience of Scripting.

    Anyway, it would be interesting to see Coupa’s final architecture based on facts, fud and business decisions. Not many data points on this regard except from personal experience of from friends.


    06/22/06 9:38 PM at 9:38 pm

  2. I'll just add, in case many don't know, that most of Oracle's procurement applications were written in Java, initially via hand-coded servlets (1998), then jsp's (1999-2001), and finally via an infrastructure called "Oracle Application Framework" which provides oracle's development teams handy libraries for common functions within a servlet-inspired architecture.

    Dave Stephens

    06/22/06 10:32 PM at 10:32 pm

  3. I agree with the AC, it’s hard to evaluate the BusinessWeek article because it contains so many technical gaffes. Those gaffes could be the result of:

    1) “editing for the masses”
    2) “an ounce of inaccuracy is worth a pound of explanation”
    3) sloppy writing
    4) poor insight/technical naivete

    Regardless, the article does make an important point: namely, STUFF HAS TO BE EASY. A naive user can put up a PHP site in 10 minutes. That is totally impossible with Java. And that’s why PHP will have deeper penetration and faster momentum, at least until someone figures out how to make Java sites that easy — and it may already be too late.

    All of the above notwithstanding, we still don’t know what technology Dave has chosen. Could be Ruby, for example. Could be lots of things. C’mon Dave, don’t keep us in suspense!

    Eric Strovink

    06/23/06 7:14 AM at 7:14 am

  4. I believe looking at the goals written by Dave, I must say there is one more point I would like to stress:

    Are the customer’s that Coupa is targeting, could have a very complex implementation or very simple implementation? Are we targeting just Jack’s Galamart for example that sells disposable camera or are we targeting Canon Inc. where Dave really wants that digital camera (Note: Goal #4), complexity is the key consideration that should be considered and given more weight when selecting technology for an application.
    Now if you want Goal #4 to be satisfied and believe “…the simple should be simple & the complex should be possible….”, now we are talking about having FLEXIBILITY. Now it is a daisy chain…when you introduce flexibility…you have to consider SACALIBILITY…. during my five years of development experience in application I have found when you introduce flexibility it unknowingly starts hampering the scalability.

    Important Question: Can this procurement application be scalable and simple enough for Jack’s Galamart and also is scalable and complex enough for Cannon Inc? This is I think the billion dollar question….

    How to choose such a technology?

    I believe you if you try to separate the presentation layer and business layer, and business layer from the data (schema) layer it will provide that flexibility. In turn, you can use any technology that you want in each layer when you have such architecture in place. I believe this is what SAP’s, Oracle’s are doing with their architecture for their next generation applications. With this type of architecture you can make use of the SOA architecture => SaaS architecture — Now with this you don’t have to be saying …Java is sooooo old…. PHP is the ‘Grand Daddy of All’…. This decision can be done at a later time and will provide the flexibility to use whatever the complexity of the application requires…

    Having said all this I would really like to know now how Coupa has done its prototypes. I am looking forward to Dave’s next posting on this…


    06/23/06 11:23 AM at 11:23 am

  5. He’s just teasing us. Coupla’s going to be using Motorola 68000 assembly. Nothing like hand-coded goodness….


    06/23/06 6:39 PM at 6:39 pm

  6. GWT seems to be a very cool technology.

    “GWT applications can be run in two modes:

    * Hosted mode – In hosted mode, your application is run as Java bytecode within the Java Virtual Machine (JVM). You will typically spend most of your development time in hosted mode because running in the JVM means you can take advantage of Java’s debugging facilities and remain within an IDE like Eclipse.

    * Web mode – In web mode, your application is run as pure JavaScript and HTML, compiled from your original Java source code with the GWT Java-to-JavaScript compiler. When you deploy your GWT applications to production, you deploy this JavaScript and HTML to your web servers, so end users will only see the web mode version of your application.”


    06/28/06 10:23 AM at 10:23 am

  7. Dave, What an interesting article! I am still debating on our hardware stack. Before I go too far. I must declare that I am not a techie. I am a commercial opportunist in addition to being a first-timer! At present, we have settled for Sun hardware as we are a Sun Microsystems partner. We also went with Java and Sun Solaris. Our Strategic Technology Partner, Affno is a java specialist. Some of the stuff we use (they say these are new technologies – I do not need to know as long as it does the job and commecially acceptable), Java, SOA, webservices, Struts, Hibernate, etc etc. We will shortly get Release 1 out. If you or any of your readers are interested in trialling (at least the web-to-web application), do get in touch through My details are on contact us page

    Manoj Ranaweera

    07/14/06 9:42 PM at 9:42 pm

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: