Business & Technology Nexus

I’ve posted in the past about Oracle’s Global Single Instance – both the vision and the reality. And although Oracle is now about as far off message from pushing a Global Single Instance as they ever could be, there are some compelling points that come with the promise of system centralization.

[Before you get too excited, this isn't an argument for Oracle to return to the GSI message - clearly the world prefers messiness & Oracle is generating the revenues to show it!]

Answering key questions about your business is easier when it’s done from a central source. Ask Hyperion… And while a data warehouse is the most common route for larger organizations, a few have unified transactional systems that they can query directly.

A friend of mine, Greg Tennyson, was quoted extensively in a recent Inside Supply Management cover story entitled “Acquiring Refinforcements“. In it, another huge benefit of system centralization is showcased: acquisitions.

Oracle, according to Greg, can fully integrate an acquisition’s procurement operations into their central system within 6 months. And that’s impressive. In effect, it means all the overhead costs associated with doing business as a separate company can disappear.

But you needn’t get the “Global Single Instance” religion to wield your systems toward your competitive advantage in M&A actions. A single system is far from required – just ask GE. In one GE business, system practitioners use their “all you can eat” Oracle ERP license and stamp out a new instance with standardized processes within 30 days of acquisition close. They have to! Because +30 days there’s another acquisition to work on… At the end of the process they then tie ERP instances together so closing the books is as easy as possible.

Systems prowess is often overlooked when companies pursue acquisitive growth strategies. But it’s absolutely critical. Done well systems work is transparent and allows a company to focus on what’s most important: their new customers and employees.

I enjoyed a review in VARBusiness on how the US Federal Government is getting behind the open source movement. It’s all about cost – and not just initial acquisition cost but the cost of integration, customization, and ongoing enhancement and maintenance. It’s good to see the US beginning to understand the movement – although in my opinion they are still far behind much of Europe.

VARs will want to read the last paragraph of the article carefully – as working with open source vendors tends to give them a more lasting presence helping the customer than they’ve traditionally held. That’s a little secret I hear everyone talking about but few outside the open source world understand…

Many of Coupa’s early customer conversations have included Systems Integrators. And SI’s seem to have a really good view on what works and what doesn’t when it comes to Procurement tools (and enterprise software in general).

One fact that comes up again and again is how hard it is to find a tool that handles data security (often called striping), correctly.

Failure seems to center around applications trying to anticipate usage patterns too much. These systems usually start by taking well-worn concepts such as Project, Cost Center, Organization, Legal Entity, etc, and then hard-wire them to control access to different data objects and transactional records.

The problem is the complexity and variability around data security requirements often means none of the well-worn concepts fit perfectly. So an implementer picks the concept that “doesn’t fit least” and shoe horns it into the implementation. Which in turn drives up TCO, confusion, etc. It’s misfits like these that lead to the incredible questions I would sometimes hear from customers (like this one from a Stanford University employee: “Why am I a vendor and why do I have to buy from myself via a Requisition to pay my expense report”).

A better approach is to try to encapsulate data security as an abstraction to ensure a higher degree of flexibility. Doing this and keeping configuration and maintenance to a minimum is tricky – but in my view it’s the right approach to software that fits like a glove.

Late last year I began recovering from all the Oracle technology cool-aid I’d read, repeated, and internalized. And as I mentioned previously, I began to recoil from the complexity of Java. Imho some of the IDE’s around Java simply make it worse – a complex wrapper around a verbose language. And before the flame mails roll in from the Java faithful, I’ll pre-empt them by saying a lot of people are doing great things with the language, including the team I admire over at Alfresco. But moving on…

I was surprised how far Microsoft had come with their .Net infrastructure – it’s really good stuff. In fact, hats off to Microsoft on IIS too while I’m at it. (Now why can’t some of the .Net or IIS people work on crappy Internet Explorer – I mean, come on, no transparent png support until IE7?)

Beyond Redmond’s wares, I was surprised to see PHP was now more of a real/serious language too, with much better OO support. Python seemed excellent & gaining momentum also. Many long-time open source advocates predict it will eventually eclipse the other open source scripting languages.

Intuitively (read: I can’t prove it) I began to believe the web applications infrastructure race wasn’t between Microsoft .Net and Java (which admittedly is a horrible apple vs. oranges comparison), but instead between Microsoft .Net and the best open source framework for for developing web applications. And increasingly I believed an object-oriented script language would be a better choice within whichever open source framework won out.

Now, I’m not sure if Ruby is that language. Further, I’m not sure whether Rails will be an open source application framework to rival .Net. But Ruby on Rails has worked incredibly well for us. The productivity gains vs. what I had come to expect at Oracle were shocking and continue to be amazing.

It is clean. It enforces MVC. It’s fairly powerful. We like it a lot.

I first traded emails with David Heinemeier Hannson back in December asking for his advice on whether Ruby on Rails was ready for enterprise software. And I have to say so far it’s been absolutely great. Thank you David!

If you haven’t tried Ruby on Rails or the Ruby language, I’d definitely recommend you give it a shot. And to you Java developers, don’t worry – from what I’ve seen you can make an easy transition to Ruby on Rails. But beware, you may not want to switch back!

This July 4th I’m traveling to Portland, Oregon. Portland, for those that don’t know, is arguably the US capital of open source. I was surprised to find it a hotbed of open source thought leadership and activity, and I’m told it’s been that way for some time. It’s wonderful to sit in a Starbucks and hear conversations about networked innovation and the darwinism behind the success of Linux. It’s great stuff.

Here in Silicon Valley, most of the coffee conversations sound more like the guy in this short and funny video by StoryStream courtesy of YouTube. No offense Palo Alto!

I’m hoping to catch up with a new friend of mine, Scott Kveton, while I’m up there. Scott was Director of OSU’s Open Source Labs, and I first got to know him in that capacity. He’s a firehose to talk to – lots of experience and insightful commentary on the community.

He’s just now taking on the CEO role for JanRain, a firm that has some really cool technology for individual authentication for users applicable to both the business and consumer spaces. Identity management is a pain most of us wish we had to deal with a lot less, certainly in our everyday web experience but also within the enterprise. I’m hopeful Scott will hit a homerun with JanRain & wish him the best. Who knows, maybe Coupa’s products will be able to take advantage of OpenID someday.

For those interested in technology and its relationship with entrepreneurship, I'd recommend reading Paul Graham's 2001 article called Beating the Averages. It talks about Paul's experiences starting up a firm that in the end became Yahoo! Stores. He explains why he and his co-founder chose LISP, a programming language that no one uses, and why he viewed that choice as the source of ViaWeb's competitive advantage.

In June 2006 we announced Coupa, a startup venture I co-founded with Noah Eisner. Here is the text of that announcement (with minor commentary added)

—

Today, June 6th 2006, I’m announcing what many of you have been anticipating for some time – my new venture. It’s called “Coupa“, and it’s been operating in stealth mode for a few months now. Our small crew comes from the Oracle Advanced Procurement team. It would be fair to say as a group we’ve designed & built quite a few Procurement products over the years. And we’ve come away with some pretty interesting beliefs that we now intend to test in the market.

At Coupa, we believe open source will form the components for the future of enterprise software. To that end, we intend to introduce best-in-class Procurement products at absolute rock bottom TCO based entirely on an open source technology stack. Our first product, a new take on eProcurement, will be available this July.

Why eProcurement and how is it different? I’ll delay answering these rather important questions for now. Suffice it to say those we’ve shared it with are saying things like “now why didn’t I think of that?!”

On the technology front, the Coupa team knows all too well today’s enterprise software is overly complicated, heavyweight, and yawn-inspiring. Our open source alternative aims to be the antithesis – lightweight, easy to deploy, and fun.

We expect to offer the software via traditional download and via SaaS.

I encourage you to register on the Coupa website to receive our latest news. And here’s a new email address you can reach me at: dave at coupa dot com. We’d love to hear from parties interested in joining our open source projects. In addition, we have a few openings for early adopter customers who can engage with us in an advisory role. Finally, we’d love to connect with SI’s specializing in either open source or Procurement.

I am planning to continue to operate Procurement Central (which later became the Business & Technology Nexus) as a separate blogging conversation from Coupa. It will afford me the opportunity to continue to recount my Oracle experiences, as well as touch upon the current trends I’m seeing in Procurement. And now I can add news on the start-up & also be able to share the technology and functionality choices we’re making.

I’m grateful to so many of my former customers & colleagues (as well as my new friends) for your support and wise counsel. Thanks for your help and encouragement – now it’s time to see what we can do!

Quite a few members of my former team are pushing hard to get R12 of Oracle Advanced Procurement out the door. I have no doubt they are doing a great job.

But quite a few others have gotten the start-up bug, mostly in the consumer space. And some have moved on to "cool" endeavors at other established firms. I've decided to label the group who has left: The Advanced Procurement "Graduating Class". Here's the honor roll:

Jeff Mellen, Joe Wong, Sam Hsiung, Srini Panguluri – YouOS startup

Jang Kim – Moblastic.com startup

Jacky Cheung – Mobitv.com startup

Sudhir Rao – Purisma startup 

Angus Huang – Aplix (established company in cool space)

Damon May – Fred Hutchinson Cancer Research Center (what an amazing job)

Now, some of my former hot shots are MIA. Drop me a line at drstephe at gmail dot com and let me know what you're up to. I'll update the honor roll accordingly ;)

It's a joy to see these former Advanced Procurement development rockstars spread their wings. The ones pursuing start-ups are each going after pure innovation & creativity and are pursuing large prospective markets. It's great stuff. For the readers who have time check out some of their websites & demo their stuff.

And here's a promise to the "Graduating Class": I won't be just a lazy bones blogger forever!

drs

One of the projects I learned the most from at Oracle was Transparent Punch-out. Of course, for as long as I can remember we had this vision of keeping content under the supplier's control & on their website but being able to ensure a consistent user experience for self-service requisitioners. For many years this just sat on the shelf, until one day Vijay Pawar and a few crack engineers on his team did an advanced prototype that actually worked and performed. We were able to do a distributed & parallel XML query to multiple content sources, get the responses, aggregate them & display them all within a second or two. We immediately submitted a patent on the idea, and scheduled it for the 1st available release.

Next, we invited a bunch of distributor suppliers to Redwood Shores to get their feedback. We told them "look, no more catalog syndication". We send you a query, you respond with the results. It's all real-time, with search governors in place to ensure speed. How do you think they reacted? "Boo!", "Hiss!", "NEVER!"

We had failed to position the "why" – and suppliers, hungry to differentiate to their customer base, just weren't buying. Sure, there were a couple ready to compete on price alone with good back-end systems who were ready to play ball. But 1 company estimated it would cost them $900,000 to adapt their systems. Pah! I'll adapt their systems for that and then hang out in the French Riviera for a few months to recoup. The bottom line was, if suppliers view a technology change as moving them closer to a commodity they will passively & actively resist.

Transparent Punchout may yet prove compelling – in fact, it has been pushed forward a lot further in the UK than in the US. Time will tell. 

But lesson learned – technology that bring capabilities to buyers at the expense of sellers will go nowhere fast. 

I think it might have been my former boss John Wookey who said “Software development is a lot like making sausage. The less known about the process, the better.” How true! And I know John is committed to improving practices at Oracle. But let’s face it: software development at big ERP companies is inefficient. And looking at Microsoft’s woes with Vista it’s obviously not just big ERP firms that have trouble.

So how do these firms build software? Surprisingly, practices haven’t really changed for decades. The state of the art is still classic waterfall-based milestones where thousands of resources are supposed to hit “Design Complete” or “Code Complete” all on the same day. I’ll risk getting flame mail & go ahead and state the obvious: it’s stupid. Delays are built into the model. In my experience human error, communication mistakes, and scope increases were the 3 most frequent causes of schedule delays, and they certainly weren’t the result of incompetent resources. Instead, they were the result of a system so inefficient it seems ripe for revolution. Southwest Airlines, efficiency zealots that they are, would go berserk if they saw it!

I still recall the original target for Oracle’s 10th installment of 11i was very early in 2004, perhaps January. January turned to March, March turned to June, and eventually 11i10 came out in November of 2004. Customers affectionately renamed the release from 11i10 to “11iWHEN?!”

In Procurement, 11i10 was a very big release. I had introduced 2 new products – Procurement Contracts and Services Procurement. We had interested customers demo’ing product in January. But by November I had lost most of their attention, as well as that of Oracle’s direct sales force.

Of course, post-11i10 launch Oracle acquired Peoplesoft & there were a lot of management changes. Heck, now Oracle has also acquired Siebel. But through all this change 1 thing has remained the same: the delays. Now R12 of Oracle e-Business Suite (on which development began in 2004!) is even further off schedule than 11i10 ever was. I hear the latest target for the release is November. Sound familiar?

Just to make my point, consider this: I was still at Oracle, and still heading up Procurement applications development when R12 scope was determined. I selected features from an impressive candidates list and did my best to maximize Oracle’s chances of growing share in the market. I oversaw functional design efforts and early advanced prototyping. And yet even though I left the group in January of 2005 (to head up CRM for a “New York minute” prior to the Siebel acquisition), my organization’s ideas won’t be tested in the market until 3 years after they were envisioned. And by the way, the organization is led by just as much talent and capability as it ever was.

Why, I could probably start-up a new enterprise applications business and deliver v1 product before Oracle even released my prior work. Sort of a mind-bending thought, I know, but true.

By the way, you could always predict the projects that were going to cause a schedule delay. They were either painted with a big red “I’m going to be so-o-o late” sign (e.g. let’s rewrite the Account Generator) -or- they were cross-product and cross-organization efforts. Whenever teams with differing priorities had to come together to get work done there was the possibility of miscommunication, differences in points of view on prioritization, and, to sum it up, risk.

Okay, now I’ll go ahead and say what you’re expecting: THERE IS A BETTER WAY. A former direct report of mine and all-around smart guy Seth Stafford once came up with an idea called “the chute.” Here’s how he envisioned it: you’d have your copious amounts of resources all working on their important efforts. And at any given time you’d select 1 key project or initiative to be in “the chute”. The attention of the entire company would be drawn to the project at that time. Of course it would have to pass rigorous inspection criteria to qualify for “the chute”. Any issues encountered while adding the project to the existing body of work (in this case the eBusiness Suite) would be Priority 1 for the entire group. The project would have a very short, fixed time period to get through the chute and to release.

What’s great about Seth’s idea is it is a fundamentally different approach than today’s “we need to test all this stuff together” mentality. Combining thousands of destabilizing elements into a new build & then trying to isolate problems and iron out difficulties is challenging work. But Seth’s idea poses perhaps a bigger challenge to traditional enterprise applications vendors – it requires a brand new approach to how many layers of stratified and often intransigent organizations operate.

I’m in favor of software development practices that empower individual groups to move fast and yet still ensure the high intrinsic quality customers deserve. I believe there’s an opportunity to foster chaos-based development while upholding processes meant to ensure standardization and high quality.

As always, I encourage your thoughts. If you’re a Procurement manager, do you really care about innovation in software development, or are slow, lumbering 2-3 year releases with incremental innovation good enough. After all, aren’t policy enforcement challenges and other, more political issues, really your key areas of concern? If you’re in IT, how fast can you reasonably adopt change anyway? Doesn’t a release every 24 months free you up for business-sponsored project work? And is the only way to uptake software faster through SaaS? And finally, if you’re in software development yourself, what’s worked for you?