Imagine an orchestra performing a symphony: the maestro with the funny-looking hair waves his baton at about 100 musicians, which somehow makes them play together harmonically. The brass section might be playing the main theme, the basses are responsible for the bottom end and the drums set their accents. Should instruments be too loud or too fast, the conductor can adjust dynamics and tempo by simply flicking his wrist.
Before the concert, in numerous rehearsals, the maestro has chosen the piece, worked on the orchestration and has invited the musicians. His aim: Being able to present the piece in a way best suited for both the audience and the venue. After the concert, he might decide to make some adjustments to make the musicians sound even better in the future. Or he introduces modern instruments to perform a rock opera. Or he gets rid of most of his musicians to play a little chamber concert.
Now this is a commerce blog and you might be wondering, why we have been dwelling on the music metaphor for more than two paragraphs. In my daily e-commerce work, improving SPHERE.IO and talking to our customers, we more and more get the feeling that commerce technology should stick to the musical principles outlined above.
Software Monoliths vs. Service-Oriented Architecture
Metaphorically speaking, most commerce projects do not rely on a multitude of different musicians, but rather base their on a single synthesizer with a couple of pre-installed audio presets. Everything is fine to the point when the presets in this machine cover a sufficiently broad spectrum so that the musician can bring his music to his audience. However, if the requirements become too complex or a part of the machine breaks, the whole instrument becomes unusable and needs to be replaced completely.
Focus on implementation
Software suites in e-commerce are mostly built like one-piece instruments, and many projects center around those. Merchants concentrate on finding the one perfect piece of software offering the right features. Also, they are fixated on launch day, which usually marks the end of this project for them. In other words, people involved focus on implementation and getting everything ready for day X. Projects of this sort are mostly browser-centric, what everybody aims for is producing a webstore looking and working like — a prototypical webstore.
This procedure can be successful if the business model in question can be covered by standard software and is not likely to change much in the future. The merchant expects her customers to behave in a standard way, who in turn expect a storefront without strange deviations from the norm. On the technical side, if the core software’s development curve stays underneath the requirement graph, the merchant can be happy with her instrument. She does not take the role of a conductor but rather that of an engineer greasing her e-commerce machine from time to time.
When change is default, operation is the name of the game
As the developments in the last few years show, however, this approach is less and less effective — especially for ambitious merchants challenging their market segments with disruptive ideas. Higher consumer expectations on the one hand, and technological developments regarding new devices on the other make for a reality in which constant change is the default: The market simply doesn’t stand still while shop owners are busy implementing this one “perfect” setup. Also, they might find that the tools standard software offer are no longer sufficient to have an advantage over their competitors. Or, to put it differently, out-of-the-box features equalize everybody using them.
What a majority of merchants is facing already today is a situation, in which business requirements and external factors result in an exponential growth of the complexity graph. Sticking to the linear development of their own technical setup inevitably means they will have outgrown their architecture within a short time-span. In order to cope with this, it’s necessary to constantly adjust, improve — and to orchestrate. The focus in this scenario is clearly on operation instead of implementation.
APIs: Conduct your own Commerce orchestra
Let’s come back to our music metaphor. Ambitious merchants need to become like modern commerce conductors, free to assemble and direct different services as they see fit. It’s a fluid process allowing them to make last-minute, on-the-fly alterations when the business requires it. Need a new payment provider? Switch off the old one and switch on the new one without having to make a 6 month IT project out of it.
Modern APIs already offer stable and reliable services regarding all aspects of online retail. Rather than falling back to installing and maintaining an on-premise software black-box, merchants will profit much more from combining some of the more than 2,000 e-commerce APIs which ProgrammableWeb lists today. And, offering a hosted e-commerce-API ourselves, we are convinced that much more additional value for both customers and merchants can be generated by fine-tuning the interplay of violins, flutes and cellos instead of doodling away on your old synthesizer into all eternity.
First published on commercetools.com