Mobile-first, cloud-first approach to e-commerce

I’d like to share a few of my thoughts on building solutions with EPiServer Commerce and why you should not only look to the web-platform(s) when building e-commerce solutions.

Maybe you’ve heard that Microsoft has a new CEO. Satya Nadella. And so far he seems pretty darn awesome.

Satya Nadella

Satya Nadella

On his first day he set the course for Microsoft.

As I said on my first day, we need to do everything possible to thrive in a mobile-first, cloud-first world.

Where does that leave us, the web, cms and e-commerce? Broad question. But here’s my take on it.

Roughly three years ago we saw the coming of responsive design. Suddenly we’re (somewhat) screen size-agnostic in the context of a website. Are we out of the woods? Of course not. First, the web is losing ground in comparison with the apps. I wrote a blog post about the mobile web experience where I included a prediction from Microsoft that mobile will overtake mobile in 2014. It already has, this january apps blew past the web. And we need to build our solutions accordingly.

Mobile usage

So we really do need to thrive in a mobile first, cloud-first world. First of all let’s take a look at what mobile-first means.

Mobile first

In my world a mobile-first approach is building our solutions to be device-agnostic and always available. Some call it omnichannel. Not sure I agree with this definition, but let’s go with it.

Today we’re knee-deep with apps and web. Those are the two primary consumers of our data. And it’s a good start. But consider the devices of tomorrow: smart watches, google glass, cyborg brains, etc. You don’t have to build a grand solution that caters to all, but you can start off small and most of all smart.

Cloud first

Okay. So cloud-first. Should you push everything to Azure or Amazon? No, not necessarily. But there are some pretty awesome services out there that are prepped and ready to be utilized in this brave new world. I’m looking at you, EPiServer Find. I find myself returning to EPiServer Find repeatedly for building these kinds of solutions. The idea of pushing data to a service that is fast, reliable and have an interface that is very easy to integrate with (REST/JSON) is a fantastic start. And you should keep it in mind at the very start when building your solution.

I don’t want to be too high-level and fluff-fluff. There’s a very warm and special place for people that design solutions and know nothing about the metal.


With EPiServer 7 we got blocks. Awesome. But here some solutions went overboard and made very few page (content) types and just worked with blocks. Not ideal if you’re going to push data to EPiServer Find and then retrieve items by type. E.g: “Hey, find! Give me all products!” and Find replies “I have no idea of what you’re talking about! I only have objects!”. I imagine data communication as it looks on the floor of the wall street stock exchange. Absolute madness.

When designing your content types you should already here consider how data will (could) be consumed. Start off small but smart.

Stay DRY with your data and functions

You can opt-in to use EPiServer Commerce as your provider of product data and functions. But it must be made very clear that this is the supplier of such data (an architectural decision), otherwise you’ll have a plate of spaghetti integrations that will be difficult to maintain and your data quality will be less than optimal. The data will probably arrive through an integrations layer from multiple line-of-business (LOB) systems but it’s EPiServer Commerce that owns the aggregated product definition that makes sense for our omnichannels.

Sample architecture

A simplified architecture to explain some of my thoughts.


The takeaway from this is that EPiServer Find can be a cross-cutting function for both EPiServer CMS and omnichannels. Omnichannels being basically any application that consume data and access functions over HTTP.

EPiServer Find is a cheap and effective way to build small but smart solutions from the start that will have your solution prepped for omnichannels and not having to cost a fortune.

Recommended Posts
  • Jacob Khan

    Great blog post, thanks for sharing. I would also like to know your thoughts on designing page types vs blocks?

    • Daniel Berg

      Sorry for the late reply! Notifications don’t seem to be up and running. Do you mean designing page types as in code or photoshop? 🙂

      • Jacob khan

        I meant more like visio and how to think. Not so much code. More the idea of content design if that makes sense

        • Daniel Berg

          Ah, cool.

          To be honest I love using post-its when it comes to modelling the customer’s business objects. It’s an analogue way of doing things that makes sense before even thinking about code.

          Designing a news page, start page, etc, really just depends on the design. They’re in a grayish business objects zone. A news item might be super-specific for one client, but usually a news item is not much different from one client to the next.

          Objects like product, article, etc can vary a great deal though. So before even thinking about visio (powerpoint! :-)), visual studio, etc I always like to model them together with the client so objects in code speak the same language as the client does.

          Same goes for business rules. Model, model, model. And after you’ve modelled, build a simple prototype so that you’ll agree just on how to calculate pricing, display production information, etc.

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search