Lokad Aggregated News

Whitepaper on Out-of-Shelf Monitoring Technology released

Wed, 23 May 2012 11:54:40 +0000

Few aspects of retailing are as fundamental as fully stacked shelves, and few concerns rank higher with an ever more demanding customer than product availability. Regardless, on-shelf availability remains a huge challenge for the industry. Growing, more dynamic product portfolios, staff and cost cuts combined with an increasingly complex supply chain have increased the challenge.

While shelf availability is a top concern for customers and retailers alike, even the Tier I retailers today mostly rely on manual checks by store staff. This puts a large burden on employees, and response times to out-of-shelf situations are slow.

However, grocery retailers a crossed Europe and the US have started to explore technology that can help address the problem. With this in mind, we have published a whitepaper on out-of-shelf monitoring technology which gives an overview of

Objectives of out-of-shelf monitoring systems
Introduction to the technology
Definition of performance characteristics
Quantification of system capabilities and limitations

Are we missing some interesting aspects of this type of technology, or do you have experience with OOS monitoring systems you want to share? Please let us know in the comments.

DDD/CQRS Challenge - Integrating Distributed Systems

Rinat Abdullin — Tue, 22 May 2012 08:37:06 +0000

Let's have a look at the relatively simple DDD/CQRS challenge in integrating elements of a distributed system composed of a different bounded contexts and deployed across different hosting environments.

Let's imagine a small Software-as-a-Service company which provides some subscription-based service while charging customers per consumption on pay-as-you-go basis. Software infrastructure of such company could consist of only 3 bounded contexts (a major oversimplification on my part, bigger view might be more complicated):

Subscriptions - subscription management system, that keeps track of all customers, their active plans, billing information, invoices, monthly service consumption and available login keys. This system is architected as NoSQL solution with event sourcing and is deployed on a dedicated server (with plans to redeploy it to Azure some time later).
Cloud Services Integration - massively scalable set of services deployed in Windows Azure (e.g. using some big data processing design). Among the other things, these services expose API to 3rd party companies and even products of the same company. This API is secured by user tokens, which are replicated from the subscriptions BC. This project is stable and does not change frequently.
Product 1 - a new product being delivered by the company. It is developed as a standalone set of systems that enhance user experience, using Cloud API. This product leverages authentication and user management capabilities from "Subscriptions" and interoperates with API.

Here are some examples of the interactions between these system:

If new user is added to the subscriptions, it's auth credentials should be immediately (within 1-2 seconds) replicated to Cloud Services, to enable access via API.
If customer's account is locked out due to balance overdraft, then all related users should be locked out of the API.
When services consumption is detected in the API, it should be within 5 minutes reported to subscriptions portal.

Naturally all these systems have to work independently in such way, that if one of these is down, the rest will continue doing their part (at the very least by providing read-only UI, at best - doing everything that is not dependent on the other systems).

For example, if subscriptions are down for maintenance or Cloud Services and Product 1 should continue working as they were (all pending changes should be replicated after system comes back online).

Additional constraints:

Resulting design (with inherent implications) should be relatively easy to explain to a Junior dev.
It should also be relatively straightforward to deploy and run systems both locally (xcopy deployment of .NET code) and in the cloud.
systems should be able to change independently and rapidly as they follow their individual DDD evolution paths (for example, weekly releases with new business processes but without breaking any relations).
no more than 3 people per project to develop and maintain it.

Note, that we are focusing here only on the integration between the systems. Internal design of each system might affect such integration, but is less relevant in this case. Still it would be nice, if integration patterns shared natural affinity with internal design of each bounded context (this tends to create systems that are more robust and practical).

How would you approach this problem?

Making sense of the marketing automation software market

Matthias Steinberg — Mon, 21 May 2012 17:14:50 +0000

I recently spent some time researching marketing automation software and realized that before starting to assess specific software products I needed to gain a general understanding of the space and how certain players and verticals fit into an SMB's sales and marketing efforts. This is very basic stuff, but one needs to start somewhere. Here is a summary of what I learned.

Marketing vs. sales vs. CRM

The full customer process from 'cradle to grave' is divided into marketing, sales and customer relationship management. The responsibility of marketing is to reach an audience, create interest in the product, and produce 'qualified leads', which are then handed over to sales. The responsibility of sales is to take qualified leads, and turn them into buying customers. Marketing activities have in the last years broken into inbound and outbound marketing.

Software solutions on the market are typically following the this structure: Inbound marketing solutions, outbound marketing solutions, sales and CRM. While these solutions often have some overlap, they are all designed with one 'step' in the marketing and sales process in mind.

Inbound vs. outbound marketing

There is a whole 'war' waged on inbound vs. outbound, with inbound being the hot new thing on the block. Inbound marketing is often defined as any activity that 'lets customers find you' (SEO, content marketing, social media, blogging, email), while outbound marketing can be summarized as all paid advertising plus outbound activities such as calling and emailing (SEM, tradeshows, advertising, cold calling, email).

Opponents of outbound marketing also call it 'interruption marketing' and argue their support of inbound marketing with 'the new customer' who is savvy, will pull quality info rapidly from multiple sources (on the web mainly) and who is more pro-active while less willing to respond to unsolicited approaches.

I concur with the opinion that both should go together. Outbound marketing will help create awareness of the company, while inbound marketing seems very powerful to develop and nurture this interest. Every company will have to find the mix of both that works best for its business.

Inbound marketing automation software

Inbound marketing automation software lets you create and publish content in the various channels, and provides a very close tracking of customer behavior (profiling) by measuring visits, pages viewed, content downloaded, sign ups, time spent on the website plus targeted emailings for lead nurturing that are based on this behavior.

What I believe makes this approach very interesting is that it provides the tools to achieve the following things:

Create visibility on the web by blogging, SEO, social media publishing -> Demand/lead generation
Measure and analyse prospect behavior; identify prospect interest and stage in the buying cycle -> Lead management (lead -scoring, -intelligence, -tracking)
'Hit' customers with the right content at the right time. Right content = matching interest AND stage in the buying cycle) -> Lead nurturing
Measure and optimize your processes (which 'campaigns' work with which customer group, A/B testing, automated emailing, trigger actions for automated emailings etc.) -> Analytics and optimization
Automation of lead nurturing, analytics, workflow -> inbound marketing automation

Example: Once the particular interest and stage in the buying cycle of a website visitor is identified (based on behavior and often automated) the prospect will receive emailings tailored to his profile. What's more, emailings can be timed to optimize opening times (based on statistical evidence).

Email is used as a tool in inbound as well as outbound marketing, and software for both segments will have sound email capabilities.

I find particularly interesting the notion that not every prospect that engages you (or your website) is a buyer yet. In fact, most are not, and 'lead nurturing' is an activity aimed at turning these prospects into buyers over time. By providing the ability to identify, measure and track prospects a tailored follow-up for the particular prospect can be achieved, and to some extend automated. Turning this around, it enables me to avoid wasting time on low probability prospects, and to avoid annoying prospects that are not ready to buy with too much and the wrong type of communication.

Prominent vendors: Hubspot, Silverpop, Marketo, Eloqua (from suitability for smallest to largest customer). Others include (Acton software, Exacttarget, SEOMoz)

Outbound marketing software

Outbound marketing includes email campaigns, calling, SEM, affiliate, offline advertising, trade-shows etc. In the case of calling, outbound marketing and inside sales largely overlap. I'll only mention calling and emailing as outbound channels here:

Calling: Inside sales/outbound telephone marketing ("telemarketing") software is designed squarely around maximum calling efficiency, accountability and scalability (of teams) and provides contact, list and lead management functionality. It covers outbound marketing and outbound sales requirements alike.

Prominent vendors: Vanillasoft

Mass emailing: Emailing software solutions seem to be mostly designed for mass emailing: List cleansing, list segmentation, message templates and layouting, email deliverability, analytics (delivery, opening and click rates), scalability are key features. Typically these solutions are rather suited for B2C and potentially large B2B vendors.

Prominent vendors: There are hundreds of vendors to be found through google.

Email drip campaigns, newsletters. Similar to emailing software with an optimization towards newsletters and drip campaigns.

Prominent vendors: Mailchimp

1:1 emailing: For companies wishing to increase the efficiency of 1:1 emailing (typically large enterprise B2B) there does not seem to be a dedicated software on the market. Some inbound marketing solutions as well as telemarketing solutions have emailing features that provide limited functionality that can be used for an efficient 'personal' emailing strategy. Relevant features include templates, automatic personalization of the addressee, email preview and analytics (opening rates). Furthermore, some solutions provide the ability to create event driven 'drip campaigns', e.g. an automatic, personalized email based on customer behavior (opening of email, reply etc.).

Vendors providing some capability: Hubspot, Silverpop and Vanillasoft. However it is seems apparent that they are not a dedicated solution for 1:1 email marketing.

Integration

CRM: An important question is CRM integration, as all solutions mentioned work towards delivering a qualified lead to sales for further managment from within a CRM system. Some vendors can directly integrate with some of the largest CRM vendors. Other than that, contact export/import features seem to be provided by all vendors.

For a start-up that is just building up a marketing and sales effort it is most likely not reasonable to run multiple solutions for a very small team. It has to make a difficult choice where to focus and enjoy a dedicated software, and where to cope with the limitations of the solution. It is particularly difficult to decide while it is still unclear which marketing efforts are the most profitable ones (partly because there is not software in place to track and measure campaing ROIs)

Creating a long-list of in- and outbound marketing tasks and features might be a good first step, and a subsequent prioritization according to the marketing and sales process that management has in mind will help determine the best solution for you business

ROI = Return On Inventory?

Wed, 16 May 2012 12:00:00 +0000

ROI stands of course for return on investment. However, the idea that every euro or dollar ‘invested’ in inventory brings a certain return in terms of profits is a powerful thought. When looking at inventory from this angle, two questions arise:

Are profits earned by a product versus the capital invested in stocking it (i.e. ROI) similar over the product portfolio?
If the ROIs of the various products are heterogeneous – how can the overal ROI delivered by the inventory be maximized?

As you will have guessed, the answer to the first question is a clear ‘NO’. The return generated by a product for the euros invested in stocking it differs vastly from product to product. Two aspects have a major impact.

First, the gross margin of a product directly affects the ROI. This is obvious, and product managers naturally try to build a portfolio with high margins in mind. However, many other considerations come into play such as the coverage of the product portfolio for example. Adding more products to the portfolio is often also a strategy for growth.

The second aspect is more subtle, but equally important: The amount of stock that is required to provide a desired availability (i.e. service level) varies significantly among products. The main driver here is the volatility of demand - the higher the uncertainty of the future demand, the higher the inventory level required to assure a given service level.

As an example, lets imagine two products with the same gross margin that sell the same number of units during the year, thus generating the same amount of annual gross profit. However, product A sells the same amount each week with a high certainty, while product B is much more erratic with no sales for weeks and large orders in others. To achieve the same availability or service level for both products, the safety stock for product B will be a lot higher than for product A, where very little uncertainty and therefore safety stock requirement is given. As a result, product B requires much more units in stock than product A to achieve the same annual profit. The ROI for product A is therefore significantly higher.

Businesses continually work on maximizing their return on capital employed (ROCE). Inventory is a significant part of the capital invested by most retailers, and therefore an important opportunity for optimization. The good news is that the potential for optimizing the ROI of your inventory by taking advantage of the heterogeneous ROIs across your catalog is large.

The latter is done by finding the optimal service level at which an SKU produces the best ROI within the constraint of a set inventory budget. As a result availability and revenue can be increased for a given inventory budget, or cash can be released from inventory while maintain the overall availability.

The analysis behind this optimization however is not trivial given the non-linear correlation between service level and inventory levels. Additionally, a set of ‘strategic’ constraints such availability goals for certain products need to be taken into account.

This is a challenge which we plan to take on in the near future, the goal being a fully automated ROI optimization over the product portfolio for a given working capital sum. As an output, the system will determine service levels per SKU that give the highest availability (and therefore revenues) for a chosen inventory budget.

Excessive inventory reduces the return on invested capital, but too little inventory diminishes profits as well. The optimal inventory level is therefore a trade-off between stock-out cost and inventory cost, and falling too far on either side of the optimum will negatively impact your business. Our plans for service level optimization will leverage our forecasting technology. Stay tuned.

Sparsity: when accuracy measure goes wrong

Tue, 08 May 2012 11:09:37 +0000

Three years ago, we were publishing Overfitting: when accuracy measure goes wrong, however overfitting is far from being the only situation where simple accuracy measurements can be very misleading. Today, we focus on a very error-prone situation: intermittent demand which is typically encountered when looking at sales at the store level (or Ecommerce).

We believe that this single problem alone has prevented most retailers to move toward advance forecasting systems at the store level. As with most forecasting problems, it's subtle, it's counterintuitive, and some companies charge a lot to bring poor answers to the question.

The most popular error metrics in sales forecasting are the Mean Absolute Error (MAE) and the Mean Absolute Percentage Error (MAPE). As a general guideline, we suggest to stick with the MAE as the MAPE behaves very poorly whenever time-series are not smooth, that is, all the time, as far retailers are concerned. However, there are situations where MAE too behaves poorly. Low sales volumes fall in those situations.

Let's review the illustration here above. We have an item sold over 3 days. The number of unit sold over the first two days is zero. On the third day, one unit get sold. Let's assume that the demand is, in fact, of exactly 1 unit every 3 days. Technically speaking, it's a Poisson distribution with λ=1/3.

In the following, we compare two forecasting models:

a flat model M at 1/3 every day (the mean).
a flat model Z at zero every day.

As far inventory optmization is concerned, the model zero (Z) is downright harmfull. Assuming that safety stock analysis will be used to compute a reorder point, a zero forecast is very likely to produce a reorder point at zero too, causing frequent stockouts. An accuracy metric that would favor the model zero over more reasonable forecasts would be behaving rather poorly.

Let's review our two models against the MAPE (*) and the MAE.

M has a MAPE of 44%.
Z has a MAPE of 33%.
M has a MAE of 0.44.
Z has a MAE of 0.33.

(*) The classic definition of MAPE involves a division by zero when the actual value is zero. We assume here that the actual value is replaced by 1 when at zero. Alternatively, we could also have divided by the forecast (instead of the actual value), or use the sMAPE. Those changes make no difference: the conclusion of the discussion remains the same.

In conclusion, here, according to both the MAPE and the MAE, model zero prevails.

However, one might argue that this is simplistic situation, and it does not reflect the complexity of a real store. This is not entirely true. We have performed benchmarks over dozens of retail stores, and usually the winning model (according to MAE or MAPE) is the model zero - the model that returns always zero. Futhermore, this model typically wins by a comfortable margin over all the other models.

In practice, at store level, relying either on MAE or MAPE to evaluate the quality of forecasting models is asking for trouble: the metric favors models that return zeroes; the more zeroes, the better. This conclusion holds for about every single store we have analyzed so far (minus the few high volume items that do not suffer this problem).

Readers who are familar with accuracy metrics might propose to go instead for the Mean Square Error (MSE) which will not favor the model zero. This is true, however, MSE when applied to erratic data - and sales are store level are erratic - is not numerically stable. In practice, any outlier in the sales history will vastly skew the final results. This sort of problem is THE reason why statisticians have been working so hard on Robust statistics in the first place. No free lunch here.

How to assess store level forecasts then?

It took us a long, long time, to figure out a satifying solution to the problem of quantifying the accuracy of the forecasts at the store level. Back in 2011 and before, we were essentially cheating. Instead of looking at daily data points, when the sales data was too sparse, we were typically switching to weekly aggregates (or even to monthly aggregates for extremely sparse data). By switching to longer aggregation periods, we were artificially increasing sales volumes per period, hence making the MAE usable again.

The breakthrough came only a few months ago through quantiles. In essence, the enlightenment was: forget the forecasts, only reorder points matter. By trying to optimize our classic forecasts against metrics X, Y or Z, we were trying to solve the wrong problem.

Wait! Since reorder points are computed based on the forecasts, how could you say forecasts are irrelevant?

We are not saying that forecasts and forecast accuracy are irrelevant. However, we are stating that only the accuracy of the reorder points themselves matter. The forecast, or whatever other variable is used to compute reorder points, cannot be evaluated on its own. Only accuracy of the reorder points need and should be evaluated.

It turns out that a metric to assess reorder points exists: it's the pinball loss function, a function that has been known by statisticians for decades. Pinball loss is vastly superior not because of its mathematical properties, but simply because it fits the inventory tradeoff: too much stocks vs too much stockouts.

Move Forward by Discarding Complex Tech

Rinat Abdullin — Sat, 05 May 2012 04:53:56 +0000

Good things are either well-forgotten past or a complete rip-off from the nature. It seems that at Lokad we are going all the way back in time ourselves as well.

Over the course of the last few days we had really interesting times at Ufa office, while migrating entire event replication infrastructure to a new model. If you wish, you can call this infrastructure as bounded context of digital nervous system that is represented by green arrows in our context maps. This is a really interesting place for us, since it "touches" multiple other bounded contexts and actually crosses 2 clouds and 1 additional datacenter deployment-wise. Change shocks are mesmerizing to observe.

Now, instead of a mixture of Azure queue delivery and ZeroMQ streaming, our applications just push large event streams over hand-made HTTP replication protocol. This effectively uses HttpListener and WebRequests, which are:

rather performant;
dead-simple and well understood;
have minimal friction of introducing replication to new projects (ZeroMQ is pretty invasive here, if you go for Azure);
can be debugged with a lot of HTTP-based tools.

The design is rather simple, practical and works well for streams of half a million of events (albeit performance could be improved a lot). This was really important, since we have now a number of bounded contexts to integrate together and the volume of event streams just keeps on growing.

It is curious, how our movement forward towards better and simpler designs happens concurrently with stepping back from complex technologies to much simpler ones. In other words, we gain by discarding things.

Another example of such behavior is related to our recent decision to discard ProtoBuf as the storage format for large data objects, while replacing ProtoBuf+Gzip with TSV+Gzip. This applies specifically to bounded contexts that deal with big data. Reasons for that being:

ProtoBuf by default loads all objects directly into the memory at once (imagine a dataset of 1 GB), while the default behavior of text files is streaming;
For numerical data TSV+Gzip compresses better than ProtoBuf+Gzip, since archivers were initially designed and optimized specifically for handling text data;
You can read and parse TSV dataset with tools on any platform, including scripts and Excel. While with protobuf, some intermediate dancing would be required.

So, if I can reduce a number of technologies in a given bounded context, while making it more practical and performant, then that's a clear choice.

As you can see, in certain scenarios, we are stepping back from cool and smart tech towards something more practical and simple. This "stepping back" actually enables us to solve certain problems that exist in this specific scenario. Surprisingly enough, this brings us closer to the Unix philosophy:

Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

I certainly didn't expect to see this happening before, not even theoretically. However, in practice, there is a big difference between theory and practice.

Caveats

Please, keep in mind, that:

we are aware of ProtoBuf capability to read items sequentially.
we still will be using ProtoBuf for serializing messages, including events that are used for our event sourcing scenarios (leveraging for .NET development a wonderful library by Marc Gravell)
these examples just serve the purpose of illustrating possibility of cases, where you can move forward by discarding a technology. Specific decisions might not be applicable directly to your case.

Video: Quantile Forecasts - Part 2

Wed, 02 May 2012 05:00:42 +0000

Last week, we published the Quantile Forecasts - Part 1 video; here comes the Part 2. In the previous video, we discussed what quantiles were about. In short, it's a new way to look at the inventory optimization mechanism itself.

In Part 2, we provide some non-technical insights why quantile forecasts outperforms classic ones in three usual situations.

Video summary (7min46):

High service levels
Intermittent demand
Spiky demand

Don't hesitate to post questions in comments.

Processing Big Data in Cloud à la Lokad

Rinat Abdullin — Tue, 01 May 2012 20:36:07 +0000

Let's talk about a simple approach to visualise, model and deliver complex large-scale data processing tasks. Such tasks would deal with datasets that are so large, that they don't fit into the memory of a single machine and would also take ages to compute on a single machine. These datasets can often be referred to as "BigData".

Such tasks would benefit from distributing out the work and storage load between relatively cheap machine instances that are made available in the cloud (either public or "private"). We would also want to optimize our consumption costs by get these resources only when they are needed and releasing afterwards.

Let's also assume that such processing task, requires complex sequence of steps in order to complete (more complex than a mere MapReduce). Some steps must be processed before others can start, while others can work in parallel batches. Actual steps of the job are idempotent, messages can be delivered more than once or simply fail.

Here is an example of how such processing graph could look like:

That's how I would approach such problem in the situation, when:

development resources are limited;
data processing model is not formally established and is likely to evolve;
team (or a single developer) is familiar with event sourcing.

I would split the problem domain into two separate bounded contexts: Orchestration and Data Processing.

Bounded Contexts

Orchestration Bounded Context will be responsible for navigating data processing graph and orchestrating the individual jobs. Behaviors for that will be captured inside an aggregate root that uses event sourcing for persistence (AR+ES) for better testing and getting persistence mismatch troubles out of the way. Deployment-wise, this aggregate can live in a separate machine and would be configured in such a way, that all commands to this aggregate are synchronized and executed on a single thread (just a routing rule for messages).

AR+ES just schedules batches of tasks that can be executed an parallel, and issues second batch only when the first one is complete.

Should there be any message duplication (always a possibility in the cloud environments), AR+ES can easily track and drop duplicates by keeping hashes of already completed task batch identifiers.

Data Processing Bounded Context will be implemented using a set of command handlers that consume work commands from an input queue and process them. These handlers would operate upon data that is stored somewhere in the cloud and is considered to be immutable for the duration of the specific big data process. Commands and events can contain meta-data, parameters and references to this immutable data.

In essence, command handler is a function that will take as input a command (which could contain a reference to larde immutable data blob), perform certain operations and publish an event (optionally saving some large processing data into another data blob).

Multiple instance of command handlers would be picking commands from the input queue in this bounded context. In essence, they would be competing for the jobs, just like clercs in the bank "compete" for customers standing in line (customer is handled by only one clerk). However, we would be better than a bank, since if we can always massively increase the number of command handlers handling the load, by instructing cloud fabric to provision more machines.

Both bounded contexts subscribe to all important domain events of each other.

Important: we should differentiate between actual data (which is so large that it does not fit into a single machine/process) and behavioral metadata. The former is accessed only by data processing bounded context, while the latter is passed within the messages between both bounded contexts. For example, number of time series in dataset is metadata, while actual values within these time series are actual 'raw' data.

Orchestration Aggregate would use that metadata to make decisions that 'drive' the process through the graph.

Flow of work

Let's say we have a ProcessAggregate that contains orchestration logic for our complicated MapReduce process. When this aggregate starts, it simply publishes X events that say something

TaskAScheduledEvent(processId = 1, taskID = guid)

Note: there is more elegant way to do this, but that would require going deeper into DDD

These events would be received by Receptor (or Port) in the second bounded context, which would translate them into instances of ProcessTaskACommand. These command messages would be passed into the queue from which multiple worker machines pick their jobs.

When command handler finishes processing the task it sends TaskAProcessedEvent, which will get routed back to the ProcessAggregate as ConfirmTaskAResults(task ID = guid)

Within the aggregate we:

Mark task as confirmed (if it hasn't already been reported due to message duplication).
If this task completes some batch and enables further processing, we schedule more tasks for cloud execution.

We can also define a timeout view that simply lists all tasks that are currently running. Timeout manager (a simple process) regularly checks this view and sends "TryTimeoutTaskX" to the aggregate. Aggregate checks with it's internal state, and if task indeed has not been processed, decides to either reissue the task or terminate the whole process (yes, we essentially implement our timeout tracking as a business process within Lokad.CQRS architecture style)

Gotchas

Advantages of this approach (esp. if aligned with Lokad.CQRS architecture style):

no need to worry about persistence of complex object that represents our graph decision logic;
orchestration logic can be explicitly tested with the specifications (and documented as such);
we can easily migrate between multiple versions of the data process without downtime or stopping processes;
process can easily be developed and debugged on the local machine, while being deployed to any cloud afterwards;
we use same approaches and ideas that are used within Lokad.CQRS architecture style for modeling more conventional business concepts (this lowers learning barrier and allows to reuse answers to some common problems).

Drawbacks of this approach are:

It requires certain development discipline (and familiarity with cloud computing and AR+ES);
At the moment of writing, there is no prepackaged infrastructure for event sourcing that would work out-of-the-box;
performance of this approach would be somewhat inferior to finely tuned functional style map-reduce process implementation;
this is a batch-processing approach, which is not fit for real-time processing (yet).

In short, with this approach we trade some performance for development and deployment flexibility. This enables us to rapidly model and implement big data process (especially when requirements are still changing). After the process is formalized, we can always fine-tune and optimize bottlenecks. Although frequently you would find that it is cheaper to add another server (worth 100 EUR per month) than waste multiple development days of brilliant developers on performance optimizations.

Heads up: the entire infrastructure does not need to be really performant with one exception - if you are doing hundreds of thousands of messages within a single process, then it's worth to invest effort in messaging infrastructure (e.g. direct communication with ZeroMQ), otherwise latency will kill everything. Event stream for actual process aggregate can be simply cached in memory.

Deployment Options

Below are some deployment variations that could be used within this approach. We can implement our core processing logic without any coupling to specific deployment environment and then deploy in various configurations. The latter would require just re-configuration and optionally providing some specific adapters implementations (for messaging, event sourcing and large BLOB streaming).

Alternatively you can have the same project prepared for multiple deployment options from the start.

Local development machine:
- orchestration bounded context runs as one thread;
- multiple data processing command handlers run either as parallel threads or as multiple instances of a single console app;
- file system is used for both message queueing, persistence of large binary files and event streams for aggregates.
Windows Azure Cloud:
- Orchestration bounded context runs in a single worker role (e.g. instance of Lokad.CQRS-based engine);
- data processing handlers run as additional Windows Azure worker roles (you can configure them to run on X different threads within Y worker role instances);
- Large data is streamed to Azure Blob Storage, just like event streams for AR+ES entities;
- Azure queues are used for messaging.
Amazon Elastic Compute:
- Orchestration bounded context is a single VM, while Data processing command handlers run within multiple replicas of another VM. We scale by adding or dropping instances of that second VM.
- Amazon S3 storage is used for persisting large binary data, while local instance of RabbitMQ is used for messaging; event streams could be persisted locally within orchestration VM.

Obviously, these are just some of the few options. You can have completely different scenario, based on the specific resources, requirements, risks and constraints within you project.

In each of these cases, elastic scaling can be done by implementing a simple task that would watch upon the amount of messages waiting in the command queue of data processing bounded context, adjusting number of command handler instances accordingly.

Final Words

This approach is in not a silver bullet. It just summarizes some limited experience gained while developing and maintaining non-realtime big data processes that could be hosted both in the cloud and on-premises. As such, it can have numerous applicability limitations (especially if you are working within constrained enterprise environment). Some alternative approaches and references worth mentioning are available in the reading list on Big Data.

However, if you need to quickly deliver out some scalable multi-step data process with one person, no money for expensive software licenses and just a few weeks of time, then this approach might give you some ideas.

If you want to read more along these lines, here are a few more relevant posts:

Continuous Delivery with Lokad.CQRS

Rinat Abdullin — Thu, 26 Apr 2012 12:02:45 +0000

Today I was presenting at the Roots about Lokad.CQRS architecture style. As part of the presentation I created a quick deployment of Lokad sample project, tweaked for a continuous delivery scenario.

In short, every time a change is pushed to master within this repository: Lokad.CQRS-AppHarbor, AppHarbor performs a new full deployment of this site: http://lokad-cqrs.apphb.com. It is the duty of Lokad.CQRS to rebuild any projections that might have changed in the code.

For the most fun: this deployment is actually about 2 clouds. AppHarbor (located within Amazon) deals with builds and hosting, while data is persisted on Azure. I just didn't have time to write adapters for the persistence available within the AppHarbor (the entire deployment thing was delivered within few litres of coffee and 6-8 man hours of work).

Naturally, while working with the system within local development environment, persistence is based on dead-simple file storage.

Currently this repository is an off-shot of latest Lokad.CQRS, created for the demo purposes.

However, this experience enables totally new development approach by massively slashing down development friction. I'm tempted to push it to the master of Load.CQRS and keep it hooked with this continuous deployment, while maybe even adding more domain "meat" around inventory management concept. I think, some fun could be had around the process, where every accepted pull request is immediately deployed to production.

Video: Quantile Forecasts - Part 1

Wed, 25 Apr 2012 09:24:25 +0000

Quantile forecasts offer a radically new and better way to compute optimal reorder points. Here is our first video about this little supply chain breakthrough.

Video summary (6min25):

What are quantiles?
How do quantiles work?
What are the advantages of quantiles?

Stay tuned for more.

DDD: Evolving Business Processes a la Lokad

Rinat Abdullin — Sat, 21 Apr 2012 08:46:30 +0000

As you already know, there are multiple ways to express any given core business concept in the code via domain modeling (we discussed this topic in previous article). These ways usually depend on the architecture style selected for the bounded context, in which we are currently working.

For now, let's focus on one of such domain concepts: long-running business processes.

In a cloud-based SaaS company, we could have following business processes (among many other):

if invoice has a non-zero amount and was not paid within 15 days, then send customer a reminder.
if customer balance stays below -5EUR for more than 30 days, then issue a lockdown.
if distributed computing process has not finished processing all data batches within 1 hour, then restart it once (except cases, when it was already restarted - then issue a termination alert)

As you probably already noticed, these examples share a few similarities:

they are aware of the passing of time and deal with it;
these processes express rather complex precondition that is based on current state of the system and leads to one or more then outcomes.

Let's assume that we are dealing with a distributed system, where information about current state is shared with events. In such case, our business process might resemble a piece from complex event processing and would look this from the logical perspective:

How can we implement this "Business Process" box? There are multiple alternatives, depending on the architecture style you have chosen.

For example, you can use a state machine, where each instance of state machine would correspond to a specific process instance that you are tracking. Events would then be used to navigate an instance of the state machine across the nodes. It will also use external timer service to send messages "to future" (where message is put on hold till certain time comes).

State machines are good for formalized domains. You can learn more about such approaches in the materials provided by Gregory Young and Udi Dahan.

However, when we are dealing with business processes, that are rich with fuzzy logic, uncertainty and also happen to evolve rapidly, then a more simple solution might be needed. Especially, when you have almost no development time to spare.

What is the most simple solution in case with locking customer balance for overdrafts? For instance, we can project all events to a view, which will track all active customers that used our services and went below the threshold at some point. Then our execution will be responsible for regularly checking this view and sending "Lockdown" to every customer that had his balance below the threshold for too long.

This component would also need to keep in mind that certain customers require special handling and investigation before being locked out, while others can be locked right away. Naturally, these rules will be changing really often.

What is the fastest and most flexible way to implement such component in a rapidly growing and changing environment?

You simply wire view to the UI, attach a button to send "lockdown command" and ask a person from the business department to spend half an hour per week processing all late customers. This will save dev department hours on implementing these complex execution rules, testing them and then changing (as business discovers new corner cases). Essentially we let the rules evolve and change in the environment that shapes them: in the minds of business managers.

In other words, at this point we avoid large development effort with a little bit of human time.

Please, keep in mind, that once business processes are established and we have so many cases, that manually processing them takes too much time (that should be a profitable company by then), we can always rewrite these lockdown rules as a continuously running server-side task (rules would be mostly established by then). We could still keep the projection and a corresponding view.

At this point we invest a fixed amount of development to automate a large portion of manual work.

This gradual evolution of business processes is currently the recommended approach within Lokad.CQRS architecture style for delivery of non-formalized and rapidly changing business rules.

DDD: From Reality to Implementation

Rinat Abdullin — Tue, 17 Apr 2012 07:17:24 +0000

This is yet another post in a series that were triggered by fruitful discussions with Vaughn Vernon over content for his DDD book.

I think, one of the sources of confusion in DDD/CQRS world is that we often mix terms and concepts that belong do absolutely different layers (and that we don't know how to go from one to the other). Let's start by introducing the following separation:

For the new readers, DDD stands for Domain Driven Design, which was introduced by Eric Evans in the book with the same name. CQRS stands for Command-Query Responsibility Principle, which is often associated with architecture styles for implementing systems with DDD and optional Event Sourcing. The term was coined and explored by Greg Young.

Reality

Reality is that thing around us, which we perceive through our senses and continuously try to understand. In the context of business and software, reality contains core business concepts which are important for the competitive advantage of our business. We want to capture them and then somehow express in code for automation purposes. For example, business concepts could involve things as:

Customer
Registration Process
Customer Subscription
Invoice
Invoice Payment Cycle

I'm taking examples from the environment of Software-as-a-Service (SaaS) company, since that's what I'm mostly familiar with.

Domain Model

As we learn more about reality and business concepts, we could distill our understanding into the domain model, which contains all things that are relevant and important in the current situation. For the sake of simplicity, we will break down the entire model into set of bounded contexts (BCs) which are separate by the natural boundaries we've discovered in the real world.

In SaaS world we could highlight BCs like:

Customer Subscriptions and Billing
Client Portal
Reporting
Product 1
Product 2
Cloud integration
etc.

Each of the bounded contexts in this model stems directly from our understanding of the reality and the natural boundaries that we have identified (read more).

If we dive inside one of these bounded contexts, we could discover more fine-grained concepts:

Ubiquitous Language
Aggregate and Aggregate Root
Consistency Boundary
Business Process

Please keep in mind, that these are purely logical concepts, that have (yet) nothing to do with the implementation and all the less important details!

The process of identifying BC boundaries can take into consideration things like: teams, skills, available resources and technologies. However, at this level we still don't care about technical details like: frameworks, databases, message middleware, service buses etc. We just create foundation for making conscious choice later down the road.

Architecture Styles and Implementation

Only after we have identified bounded contexts, we can focus on each BC and start thinking about implementation matters, while considering project specifics. Result of this exciting process would be a choice of key elements for the specific bounded context:

development process - how do we organize and manage our development.
architecture style - how do we structure and design software implementation.
technology stack - what technologies do we use and how do we get them
resource allocation - how do we get resources (budgets, people, knowledge) for the project delivery.

For instance, if our teams are familiar with the SQL/RavenDB and NService Bus, we can pick architecture style described by Udi Dahan (blog), where:

aggregates are persisted with SQL+NHibernate or RavenDb;
command handlers and application services are hosted by NServiceBus;
business processes are implemented with NServiceBus sagas;
consistency boundaries happen within the transaction scope;
views are created either by in-memory events or via projected audit logs;
development process will be aligned towards Waterfall or Agile.

If environment requires event sourcing or teams are hyped with AR+ES architectural style of Greg Young (blog), we can:

persist aggregates with event sourcing in event streams;
host command handlers in custom message dispatchers that use something like AMQP or direct socket communication;
business processes are mainly implemented with state machines hosted within event handlers or via document-based state machines (where state is persisted in messages);
views are disposable and are projected from event streams to whatever technology that is needed;
consistency boundaries are within aggregate;
use Agile development process.

At Lokad we are mostly using Lokad.CQRS architecture style (sample) that is derived from Greg's but is fine-tuned to:

fit cloud computing environments while supporting on-premises deployments;
reduce development friction and development effort at the cost of higher requirements for team skills and discipline;
support rapid domain evolution in rapidly changing business environment.

This architecture style involves following technical choices:

aggregates are persisted with event sourcing in event stream;
message handlers are hosted in custom message dispatchers provided by Lokad.CQRS sample project (with adapters for on-premises and cloud deployments);
business process transitions are implemented as part of the aggregate behaviors (they could be triggered by user interactions, stateless event handlers sending commands in response to events or tasks that sending commands on a schedule);
views are disposable and are projected from event streams, using dead-simple key-value persistence for the majority of cases (with adapters for on-premises and cloud);
consistency boundaries are per entity (aggregate or view instance);
rapid development process is used for multiple releases per week/day.

Obviously, these are just a few options of implementing a given bounded context. There are more architecture styles available out there (and each architecture style can have multiple implementation options and variations).

DDD Modeling Process

Now, for the most fun part. This trajectory from reality to architectural style is just a happy path scenario that happens only in dreams. In reality you might need to iterate from reality to implementation multiple times:

These iterations are the foundation of the approach to explore and capture core business concepts in domain model (or, one of the approaches). Approach is totally attributed to Greg Young.

We start by sketching out domain model without even trying hard to be precise from the start. Then we try to implement it in the code using the most hacky approach possible. Lokad.CQRS style with file-based persistence and messaging works for us, because it is designed for rapid iterations and has the least friction (I'll need to do a quick video on that process).

One of the goals here is to build a set of unit tests that use specifications to verify behaviors of aggregate roots with event sourcing (AR+ES). These specifications can be printed out as use cases in human-readable way.

More often than not, a lot of problems and questions show up during this implementation phase. At this point we usually forget about the implementation (while keeping our use cases) and go back to the domain experts with these questions (more often than not, for me this boils to going and talking to the mirror). Then we adjust the domain model according to the lessons learned. Depending on the nature of the adjustment, implementation is either discarded completely or refactored to fit (AR+ES specifications are usually kept between these iterations, to make sure that we don't loose any captured use case).

The process is repeated till we distill our domain model to the point that it captures all required business concepts in a way that can be easily implemented in the code. At this point we can print out specifications, reconfigure implementation to use adapters for production environment (e.g. Azure), push it to production and try to call it a day (only to have next challenge handed to us).

PS: If you are interested in this topic, next article in the series might interest you: DDD: Evolving Business Processes a la Lokad.

Lokad.CQRS Architecture Style: Plans and Boundary

Rinat Abdullin — Sun, 15 Apr 2012 09:11:46 +0000

Все фигня, кроме пчел, да и пчелы - тоже фигня (c)
Ответ старого пчеловода на вопрос о смысле жизни.

Over the course of last few months I was lead to a simple realization: CQRS/ES is not a top-level architectural style, but rather a tactical choice. Yes, I know that this is what people have been talking about for all the time; but hearing is one thing, while understanding is the other.

This simple realization makes CQRS/ES much less important on the big picture (or maybe my own picture just got bigger). So, when we have a complex problem at hand, we start by identifying natural boundaries around some core business concepts, which would let us identify separate bounded concepts. Only then we can decide about architectural styles that could be applied within a specific bounded contexts. (I went into more detail on that in my last post)

Lokad.CQRS (in it's current anatomy branch on github) is currently a sample project demonstrating my favorite way of implementing bounded contexts that are:

rich in business behavior;
require rapid changes and releases (we are rapidly learning about environment);
require elastic scalability and ability to be deployed to various cloud environments.

This is a sharp tool, that requires discipline as well as people with certain knowledge and experience. On the bright side - it is verified by practical experience, cloud outages and startup environment.

As you can see, we've just defined applicability boundaries of Lokad.CQRS+ES approach. This actually helps it to focus and stop attempts to handle all possible scenarios. The approach works and I don't plan a lot of changes any time soon (maybe just more documentation and tooling improvements).

My current friction points currently reside on a higher level - making multiple bounded contexts (that are deployed across clouds and datacenters) to work together. Especially, when you have a rapidly growing software-as-a-service company that tends to introduce multiple services and changes per year; where each one brings new bounded contexts and details on the global strategy map (and these guys just don't know how to stop).

Once again, I'm happy with the current state of Lokad.CQRS architecture style and don't expect a lot of changes to it. CQRSGuide will probably gradually transition into a documentation guide across that specific architecture style.

Please keep in mind, that this approach is just one of many out there. There are two other options in .NET world that I want to highlight:

NServiceBus and things that Udi Dahan teaches. I might have strong personal disapproval of values and grounds of his approaches, however they work in world's largest companies. You can't argue with that.
Microsoft CQRS P&P Journey, which has a strong technical team with a diverse advisory group. In my opinion they are focusing too much on debates and less important technical things, but the progress Microsoft is making is impressive. I wish them luck.

If you are interested in pushing state of the art in this area, I encourage you to dive deeper, learn and share what you have learned. It does not matter, which project you would choose for that - you will gain and give a lot either way.

Software War Starts with a Map, Context Map

Rinat Abdullin — Sat, 14 Apr 2012 11:49:03 +0000

Let us continue revisiting the big picture overview of all DDD and CQRS things, based on the things I've learned recently in collaboration with Gregory Young and Vaughn Vernon. We will start with the most important things.

Let's imagine that you are a software manager challenged with a new project to deliver. The project is really interesting and challenging, customer can talk about it for hours. Sometimes there will be references to similar projects to copy and cool technologies that should help. You and your team are already itching to start flush out some specs and start developing.

Is it really where you start? Wrong.

Complex software project is a war - it is unpredictable and brutal fight to hit moving target, while always running short on time and resources.

NB: I'm currently talking about "startup" environments. Enterprise situations with available resources and preallocated budgets are a different story that we are not interested right now.

You don't enter software war with low-level details. You don't start with detailed tech specifications or strategies (unless you want to have perfectly planned and failed blitzkrieg on your hands). First you need a strategic map with bird's-eye view of the current situation at hand. Maybe this war is not even worth entering?

One of the approaches of getting such map is to make your way through "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans (just make sure to read it this way: chapter 11 - END; Beginning - END).

Domain Driven Design (DDD) is a special way to look at core business concepts that exist in a real world and deeply connect them to evolving domain model, that could be easily implemented in software to solve specific problems. In other words, it can help to look at real world, understand it and divide into a set of separate territories that can be conquered separately, step by step.

“One step at a time, ... I can walk around the world. Watch me.” (c) L.M.Bujold

Separate territories are called "bounded contexts", while the big map is called "context map".

We use DDD toolset (set of rules, hints and guidelines) to look at the complex mess of important business concepts and identify natural boundaries around some of them. These natural boundaries would be discovered in the real world and then transferred to our "context map". Area within the boundary will be called "bounded context"

This process is equivalent to geography or geology, where explorers map the terrain and draw borders around areas that look the same according to some arbitrary criteria. Criteria for finding such natural boundaries can be extremely different and will depend on your situation (synonym to "situation" is "context"). As it has always been: drawing maps is a challenge, especially when half of the territory is terra incognita (or covered by the "fog of war").

Please keep in mind, that Context Map is not a plan of some distant future. It is merely a reflection of current situation that we have in our software project or a company. It is a map of terrain that has to stay updated and real, in order to be of any use.

Let me be clear: you don't necessarily need to map all the terrain of software project on a context map, before starting to work on it (sometimes research and development is the only way to move forward). However, staying aware of the business situation (context), uncharted areas, and potential unknown risks, will make you more prepared for unexpected changes in the future. Being able to divide complex problem area into a set of separate bounded contexts will make it easier to think through the situation and approach it.

The biggest advantage of separate bounded contexts is about their explicit separation from each other. Once we have clear boundaries, we can consciously focus on the situation inside in relevant isolation. For each specific context within a boundary, we can pick the most efficient combination of technologies, teams and development approaches.

For example, given a SaaS battlefield and a new secret "Product XYZ", the latter could allow division into two separate bounded contexts. One specific bounded context (highly complicated and requiring special approach) can be handled by a special research and development team, while the other neightboring BC could be delegated to a team specializing in solving diverse and messy situations.

As you can already see, our context map not only allows to start tackling problem space, but also enable considering the allocation of limited resources over a seemingly endless battlefield of possible projects to deal with. Same works with risk mitigation, time and long-term campaign planning. At certain moments in the course of software war, you can even identify situations, where certain projects could be worth a sacrifice, risky spike, massive refactoring (or all of these at once).

It might be really boring to read all this text without any mention of cool technologies (e.g. self-rebuilding CQRS view projection host with unlimited scalability for reads), however technology choices are mostly irrelevant on a higher level. Technology or an architecture style can be an enabling factor or even a strategic asset, but they are never the ones that drive the campaign.

One of the best places to learn such things in practice is by working in a startup. Such places tend to have rapidly changing battlefield and rather low tolerance for stupid decisions. In war of startups you win or you die.

Out-of-shelf trilemma

Sat, 14 Apr 2012 09:05:49 +0000

Most people are familiar with the notion of dilemma when two possibilities are offered neither of which being acceptable. Safety stock analysis is a classical mathematical dilemma: you can choose between more stocks or more stockouts, yet both of them generate extra costs.

However, it exists situations where the trade-off is more complex in the sense there are more than 2 unfavorable options to balance. When there are 3 unfavorable options to be balanced, the situation is called a trilemma.

Out-of-shelf (OOS) monitoring, ala Shelfcheck, is facing a trilemma when it comes to the quality of the alerts being delivered:

Sensibility, the percentage of OOS problems being captured.
Precision, the percentage of true alerts within all OOS alerts.
Latency, the delay between then start of the OOS problem and the alert.

Pick any two, but you can't have them all. In fact, for any given demand forecasting accuracy, improving any of those 3 metrics come at the expense of the 2 other metrics.

Increase your conversion by nurturing trust

Matthias Steinberg — Fri, 13 Apr 2012 16:01:10 +0000

Sales cycles in business software can range from days to multiple month and even years. Both the complexity of the product itself, and the dependency of customer value on implementation and business context, will increase the average time required for a sale.

The number one challenge in this process is to not lose the prospect along the way. A key ingredient is the ability to create and maintaining the prospect’s trust in the value of your product. Expressed differently, the sales process is the exercise of creating and maintaining the client’s trust in a better return on investment compared to the alternatives, which include not buying at all.

It is easy to underestimate the non-monetary cost for a prospect to go through an evaluation and purchasing process. In the earlier stages of a sales process the investment of time, effort and emotions as well as the risk of failure are often far more important considerations for a prospect than the price of the product or service.

It is therefore key to nurture and maintain your prospect’s trust in a competitive return on investment throughout the sales process.

1. Create trust it is a ‘cheap’ investment

Make it easy to understand what your product does, how it will solve your prospects problem, and how it can be evaluated. If this is not rapidly and easily understood, how much trust will your prospect have in a smooth and successful evaluation process?

Be specific and direct in the description of company and products. Avoid corporate happy talk and generic messages. Switch on your ‘happy talk meter’ and read your own website. Beware if you come acrossed things like (real life example) “We provide IT solutions focused on the customer’s needs. We excel in the industry due to our large experience and wide business knowledge.”

Distill your message of all the things you would like to explain about the great functions, benefits and reasons to buy your product into the very essence to arrive at your core message. This is not always easy, but worthwhile the effort.

Create short loops of positive reinforcement. Guide your prospect through an evaluation process that is broken down into smaller pieces, and that ideally will provide several ‘intermdiate results’ that allow early feedback.

2. Create trust you deliver what you promise

Make the credibility of your messaging a high priority. Avoid extraordinary claims that you cannot back up with case studies, examples or a trial. Avoid ‘sales speak’ that sounds cliché and overblown. And don’t take your prospect for a fool. Banging on about how your software is ‘free’ (real life example) when really this only concerns your super limited ‘basic basic’ plan is a sure way to annoy.

Be specific on where you excel and where the limits are of what you can provide. As I mentioned in an earlier post, the feature you don’t have might be one of your best sales arguments – for the simple fact that it boosts your credibility.

Know ‘where’ to sell and where to educated and inform. Of course you should toot your horn on your product, tour and homepage. Yet, in your educational and background materials, do not mix your content with blatant sales messages. Rather place a link to your product pages at the end of a piece of content.

3. Create trust you know what you do

It’s the content, again!. The materials you provide on your website will have a huge impact on the trust your prospects will put in your ability to deliver.

Work on quality over quantity. Information is available anywhere and in masses, high quality information is all the more scarce. The ‘depth’ and quality of the information concerning ‘your’ topic will directly reflect on your company and products. And the more trust will prospects put into you as the right place to spend time and money to solve ‘his’ problem.

Educate your customers. Providing learning and educational materials covering the topics that are relevant to your prospects undertaking. Primers, how-to guides, white papers, FAQs etc. will have the double positive effect of creating trust as well as putting your prospects into a better position to determine the quality of your offering. The first quality info I ever read on lead nurturing was Marketo’s guide on lead nurturing. Where will I turn first if I need a lead nurturing software?

4. Create trust you are alive and kicking

The closer you are to your prospects, the more comfortable they will feel in investing in the evaluation process.

Make it easy for prospects to contact you by making phone numbers and email clearly and always visible. Get local phone numbers for your main markets. More resource intensive, but even better are life chat applications such as liveperson.com.

Surprise your prospects in the speed and quality of your follow-up. Use clear prioritization metrics and processes to insure your support focusses activity and provides quality where it matters.

Be proactive by monitoring client activity. For this purpose we have built an application at Lokad that provides sales with real time information on client actions. It allows us to contact the client and provide support right at the moment when the prospect is engaged and needing support.

There are many ways to nurture your client’s trust, which will vary according to your product and customers. Regardless, I believe it is a profitable undertaking to find and pursue the most efficient and powerful ones for your business.

Lokad.CQRS is not

Rinat Abdullin — Tue, 10 Apr 2012 04:20:09 +0000

Lokad.CQRS Sample Project is NOT a framework. It also is not the only way to do CQRS. It is just sample for one of many ways to provide technical implementation for a given Bounded Context.

If you have team that is friendly with all of these at once: DDD, CQRS and ES, then this specific CQRS architectural style would be cheap and reliable way for you to rapidly deliver complex domain models to continuously changing world.

If this team is also enhanced with cloud computing experience and lean development practices, project deliverables could be easily evolved and deployed to various environments: starting from on-premises and up to the cloud.

This brings up the most common mistake that I make in my blog posts. I forget to stress:

how important DDD is for our projects.
how important it is to have people with the proper skills for such projects.
how important is low-friction development for our projects.

CQRS architecture style that is used by Lokad is based on these principles. It will be applicable only if they match your environment.

NB: please note, that I didn't mention cloud deployments and massive scalability in the list above. These are side effects of Lokad.CQRS architecture style which are valuable but less important.

Bird's-eye view of a Distributed System - Context Map

Rinat Abdullin — Sat, 07 Apr 2012 14:47:46 +0000

In one of my previous posts on Anatomy of Distributed System à la Lokad we were zooming into the design of a system that could be built as a part of SaaS company. Such system was built with and around CQRS/ES concepts.

This approach looks like a nice by-the-book design: bounded contexts that are based on a uniform design and connected together to deliver some functionality. This is the kind of drawing that could be produced by an ivory tower architect or a consultant that is "too expensive to ever touch the codebase".

However as we know, nothing exists in isolation from the real world. Every entity (either biological or digital) is always connected to much larger environment (and is affected by it). In software projects, for instance, you would have other departments to cooperate with, customers to serve and partners to integrate with. You might also have Microsoft and Apple OS to curse about. Even political rivalry between departments A and B in an organization could matter (especially if they share a database).

So there is an immensely complex and diverse ecosystem that surrounds every single software project. There are different technologies, languages, concepts, mentalities and resource constraints. These things do not necessarily belong to the project directly, but could have an extremely strong impact on risks and costs, potentially leading to the difference between success and failure. Good software developer will always consider the most important of these strategic factors, while making tactical decisions.

One of the ways to take some of these factors into consideration is by changing perspective of your system and by looking from bird's-eye view at it and other systems that it is linked to. Let's zoom out of our CQRS/ES-based set of systems in a department (which was discussed in Anatomy post) and look at a bigger picture. We'll include other departments, some of the customers and partners.

This view will be based on "Context Map" approach of DDD but slightly expanded to cover ecosystem within and around the company. I will keep CQRS/ES-based bounded contexts marked with orange border, while "external" ones will have borders of other colors (just like countries on a map).

Ok, now that's a subtle change. We get a lot more variety in colors and shades, which represent differences:

outside elements have technologies and context specifics that differ greatly from ours;
our own elements turn out to have different shades of CQRS/ES implementations as well.

In other words, each bounded context is different. These differences can be caused by a huge amount of internal and external factors. For example, consider these two contexts, which happen to be owned by different organizations:

Obviously, these differences would make different approaches more or less successful than the others. And it actually is perfectly OK to have different approaches and technologies living in the same organization or a project, if this is justified by the environment. Unless, of course you are a developer from a Soviet Russia that has to employ absolutely identical set of tools everywhere (i.e. SQL everywhere, NHibernate everywhere, NServiceBus everywhere etc).

A few vivid examples of ignoring the strategic context, while charging into the battle were clearly demonstrated by Napoleon and Hitler. They came over to visit Russia and stayed over for the winter with such extended and fragile supply lines.

So, please, don't repeat mistakes already covered by history books (these are the most shameful ones) and:

Take into consideration real world that surrounds this project, trends and risks that surround in future.
Split your environment into set of bounded contexts, that could be distinguished by similar language, match with organizational boundaries or technology manifestations. Map the terrain to make it more understandable.
Before considering to apply CQRS/ES (or any other tech) to a given bounded context - consider and compare it with other approaches, their risks and costs.
Delay non-essential decisions as much as possible.
Push for approaches that allow you to capture feedback from real life as fast as possible (lower development friction, faster iterations, simple architectures).
Keep it simple and separated (KISS).

Let me reiterate.

Domain-Driven Design with its approach of bounded contexts that can be joined into a strategic context map - is one of the ways to visualize and represent environment surrounding and affecting a project. This approach can help to take into account all important factors and figure out the tactical details of most implementation, architecture and technology. Sometimes CQRS/ES approach would be the best fit, however more frequently you would have a different set of conditions that require a different solution to the challenge ahead.

Pick your weapons wisely, for they might affect the outcome of the battle and war.

Bizarre pricing, does it matter? (B2B)

Joannes Vermorel — Mon, 19 Mar 2012 20:08:45 +0000

My company has just released quantile forecasts upgrade. It's no less than a small revolution for us, however, unless you've got some inventory to manage, it's probably not too relevant to your business.

Another salient aspect is our new pricing for quantiles (the old pricing for classic forecasts remains untouched). Lokad is selling a monthly subscription, and if $q_i$ represents one of the actual quantile values retrieved by the client during the month, then the monthly cost $C$ is given by:

$$C = $0.15 \times \left(\sum_{i=0}^n q_i^{2/3} \right)^{2/3}$$

~~We hesitated to round 0.15 as $\frac{\pi}{2}$ because formula look better with Greek letters.~~ Obviously, it's not simple, and most people would go as far as saying it's downright obscure, but it is really a good pricing, or just plain insanity?

To understand a bit where Lokad is coming from, let's start with the fact that we are a B2B software company. About 95% of competitors don't have any kind of public pricing: you can only ask for a quote, and then a talented sales guy will contact you to figure out your maximum budget, only to get back to you with a quote at 120% of the figure you gave him.

However, I strongly favor public pricing, not because it's more transparent, honest, fair, whatever, but because it's a massive time saver. At Lokad, we don't enter into time-consuming pricing negotiations except for the largest clients, where it does make sense to spend time negotiating.

The cardinal rule of software pricing is that it should capture the willingness to pay of the client, which, in B2B, is typically related to the economic gains generated by the usage of the product. In the case of demand forecasting, benefits can be accurately computed. However, turning this forecasting benefits formula into a pricing formula is insaly complex in the general case.

Hence, we decided to settle for heuristics that somehow mimic this theoretical willingness to pay, ran many simulations over our existing customer base, and finally figured out the formula. I do not claim that this pricing formula is optimal in any way: it is not. However, it does bring a very reasonable pricing for clients ranging from 1-man companies to 100,000+ employees companies.

Pros:

(As far we can judge) It's aligned with the value Lokad creates for clients.
It's still simple enough to be memorized in 20s.
It does not put incentive to game the pricing by excluding slow movers (i.e. products with low sales) from the forecasting process.
There is no threshold effect, where the pricing jumps to a much larger number just because the company has 1 more product than what the license would support.

Cons:

It certainly falls into the category of bizarre pricing.
The only way to know for sure the real monthly cost is to give a try (1).
Some prospects try the pricing formula on their own, and get it wrong (2).

(1) This statement applies to most metered SaaS, even if the pricing is linear. For example, at Lokad we had very little clue about our exact bandwidth consumption until we migrated toward the cloud (with dedicated servers, bandwidth was part of the package).

(2) I believe this partly explains why 95% of our competitors don't put any public price on display. That, and the fact that a very expensive pricing is likely to scare away prospects, before getting the chance of cornering them into the sales process.

I would be interested to see if other B2B niches have designed their own bizarre pricing formulas. Don't hesitate to submit them in comments.

SaaS pricing: Getting your pricing plan right.

Matthias Steinberg — Wed, 14 Mar 2012 09:57:31 +0000

The other day I came across a SaaS pricing plan that stated for the most feature rich option: ‘Please contact us for a quote’. My buying momentum reduced instantly to something close to zero.

Public pricing today is the norm for SaaS offerings, and investigating the individual prospect’s willingness to pay is largely a thing of the past. In a public pricing model, the seller is trading in pricing flexibility for lower barriers to entry, increased ‘self-servability’ and transparency. All the more important is therefore the design of a sensible, and profitable, pricing plan.

1. Know your pricing criterion: Customer value

The single criterion you should use to model your pricing plan is customer value. Think through your main customer groups. Segmentation might be by vertical application, size, or by type of use and application. Identify your customers’ primary motivation to use the product. If you are unsure, it is time you speak to prospects and customers. The reason customers bought in the first place will give it away. Ask prospective customers what main characteristic(s) would make them buy and/or switch vendors.

2. Find the ‘best’ proxy for customer value

The challenge is to identify the pricing criteria that most closely tracks customer value. 'Features' and 'seats' are the usual suspects in software price lists. Yet, Software provides a lot more pricing possibilities, given the high contribution margin of each sale. Performance, throughput, number of projects, storage space, resilience and availability are a few ideas. A combination of several characteristics bundled in a subscription plan can help to more closely track different customer groups.

3. Resist the temptation: Don’t think customer profitability

Customer acquisition and customer service cost can be high. It is therefore tempting to think bottom up and price ‘cost plus’. Yet, ultimately your customers decide what they are willing to pay. Focus therefore first on approximating customer value, and work to control cost. Disregard the customer groups that will not be profitable anyway.

4. Calibrate to reflect your market strategy

Once you have identified your pricing criteria, you need to calibrate. Model the price for your different customer groups and then play with scenarios. Benchmark the outcome against alternative options in the market and calibrate according to your own competitive strategy.

5. Don’t lose any sleep: Once size will not fit all

Finding a pricing plan that fits all potential customer groups is most likely unrealistic. Know your core target customer groups and get it right for them, and don’t lose any sleep over the rest.

6. Let your customers self-select

Your client is the best positioned to approximate willingness to pay. A good way for you to capitalize on this is by providing to your clients with the opportunity to trade convenience against cost. The cost insensitive clients will naturally go for the “full package” deal, the cost sensitive clients will gravitate towards painstakingly optimizing their cost, while you avoid diluting you product’s core performance.

7. Give your customer a chance to grow

A friend recently commented: “Salesforce.com seems cheap in the beginning, but you always end up adding on more features until it ends up being very expensive”. Growing with and within your existing clients is a great way of growing your own business. Customers will be more likely to increase their spending with you once they are satisfied with your product and trust has been established. You should give them the chance!

In addition to any amount of analysis and thought you put into devising your payment plan, it is always recommendable to take a look at the pricing of competing as well as unrelated SaaS businesses for ideas and to get a feel for the market—even if it is only to identify what you don’t want to do.

Quantiles = Inventory Optimization 2.0

Mon, 12 Mar 2012 08:00:35 +0000

Getting more accurate forecasts, that turn into profits, is the No1 priority for Lokad. However, demand forecasting has been extensively researched for more than a half a century, and each 0.1% of extra accuracy is typically nothing less than a uphill battle.

Sometimes though, we make a breakthrough. Today, we are announcing the most significant technology upgrade of Lokad since its launch 6 years ago: the immediate availability of quantile forecasts.

Quantiles are disruptive in the sense that in many situations they make classic forecasts plain obsolete as far inventory optimization is concerned - for retail, wholesale and manufacturing businesses.

We have identified 3 situations where quantiles really shine:

High service levels at 90% and above.
Intermittent demand (slow mover's).
Bulk orders (spiky demand).

In those situations, benchmarks against our own classic forecasting technology indicate that quantile forecasts typically bring either 20% less inventory or 20% less stockouts.

Extraordinary claims require extraordinary evidence. Carl Sagan

However, the many benchmarks that we have made so far with our prospects and clients indicate that our classic forecasting technology is already ahead of the competition; but with quantile forecasts, it's whole new level of inventory optimization that can be achieved.

Don't hesitate to put quantiles to the test.

The story behind the quantile upgrade

Quantile forecasting (also called quantile regression) has been around for decades among academic circles. Then, in finance, analysts have been extensively using quantiles for Value at Risk (VaR) analysis since the late 1980s.

At Lokad, quantiles have been around for a long time as well. For example, back in 2009, Sequential Quantile Prediction of Time Series. IEEE Transactions on Information Theory, March 2011, vol. 57, n°3 has been published by one of us. However, until very recently, quantiles were very mistakenly considered a mathematical distraction (business-wise) rather than a mission critical concept.

What did hold us back was not lacking insights in statistics, but lacking insights in the profound relationship between quantiles and inventory optimization. This insight was triggered, mostly out of dumb luck, when a client did ask us to figure out a formula to compute optimal service levels for her inventory.

A breakthrough yes, but a late one

This quantile breakthrough is only very relative in the sense that quantiles have been already applied successfully for decades in other trades. However, there is one aspect that partially explains this late arrival: quantile models typically require about 10x more processing power compared to classic forecasting models. Without cloud computing, we would not have been able to put quantiles in production, while preserving an aggressive pricing.

Cloud questions from Syracuse University, NY

Joannes Vermorel — Wed, 22 Feb 2012 16:45:58 +0000

A few days ago, I received a couple of questions from a student of Syracuse University, NY who is writing a paper about cloud computing and virtualization. Questions are relatively broad, so I am taking the opportunity to directly post here the answers.

What was the actual technical and business impact of adopting cloud technology?

The technical impact was a complete rewrite of our codebase. It has been the large upgrade ever undertaken by Lokad, and it did span over 18 months, more or less mobilizing the entire dev workforce during the transition.

As far business is concerned, it did imply that most of the business of Lokad during 2010 (the peak of our cloud migration) has been stalled for a year or so. For a young company, 1 year of delay is a very long time.

On the upside, before the migration to the cloud, Lokad was stuck with SMBs. Serving any mid-large retail network was beyond our technical reach. With the cloud, processing super-large retail networks had become feasible.

What, if any, negative experience did Lokad encounter in the course of migrating to the cloud?

Back in 2009, when we did start to ramp up our cloud migration efforts, the primary problem was that none of us at Lokad had any in-depth experience of what the cloud implies as software architecture is concerned. Cloud computing is not just any kind of distributed computing, it comes with a rather specific mindset.

Hence, the first obstacle was to figure out by ourselves patterns and practices for enterprise software on the cloud. It has been a tedious journey to end-up with Lokad.CQRS which is roughly the 2nd generation of native cloud apps. We rewrote everything for the cloud once, and then we did it again to get sometime simpler, leaner, more maintainable, etc.

Then, at present time, most our recurring cloud problems come from integrations with legacy pre-Web enterprise software. For example, operating through VPNs from the cloud tends to be a huge pain. In contrast, modern apps that offer REST API are a much more natural fit for cloud apps, but those are still rare in the enterprise.

From your current perspective, what, if anything, would you have done differently?

Tough question, especially for a data analytics company such as Lokad where it can take 1 year to figure out the 100 magic lines of code that will let you outperform the competion. Obviously, if we had to rewrite again Lokad from scratch, it would take us much less time. However it would be dismissing that the bulk of the effort has been the R&D that made our forecasting technology cloud native.

The two technical aspects where I feel we have been hesitating for too long were SQL and SOAP.

It took us too long to decide to ditch SQL entirely in favor of some native cloud storage (basically the Blob Storage offered by Windows Azure).
SOAP was a somewhat similar case. It took us a long time to give up on SOAP in favor of REST.

In both cases, the problem was that we had (or maybe it was just me) not been fully accepting the extent of the implications of a migration toward the cloud. We remained stuck for months with older paradigms that caused a lot of uneeded frictions. Giving up on those from Day 1 would have save a lot of efforts.

How much do you get for 1% extra accuracy?

Mon, 20 Feb 2012 17:03:57 +0000

One of the problems that comes with being specialists of a subject is that you tend to take for granted what is obscure for anyone but your peers. At Lokad, despite our best efforts, we are no exception, especially when it comes to forecasting...

Recently, we realized that we had never provided any in-depth quantitative assessment of the financial gains generated by an increase of the forecasting accuracy, which is about the raison d'être for the company. Furthermore, after investigating the web, we realized that other forecasting vendors (competitors) were rather fuzzy too about the financial rewards that could be achieved through better forecasts.

However, it's not that complicated. With the following variables:

$D$ the turnover (total annual sales).
$m$ the gross margin.
$\alpha$ the cost of stockout to gross margin ratio.
$p$ the service level achieved with the current error level (and current stock level).
$\sigma$ the forecast error of the system in place, expressed in MAPE (mean absolute percentage error).
$\sigma_n$ the forecast error of the new system being benchmarked (hopefully lower than $\sigma$).

The yearly benefit $B$ of going for the new forecasting system is given by:

$$B = D (1 - p) m \alpha \frac{\sigma - \sigma_n}{\sigma}$$

For the proof of this result, check the full length article.

A strong sales argument: The features I don't have.

Matthias Steinberg — Thu, 02 Feb 2012 20:49:25 +0000

It’s obvious: The better your product, the easier the sale. If you have ever sold anything, you acted accordingly. You polished, presented, explained, praised. Talking about all the beautiful things your product can do comes naturally to most sellers. What is far more difficult is talking about what your product cannot do.

Saying NO to prospects when you want to just say YES

I explain product and features, quantify business value, highlight competitive advantages, and demonstrate how wonderfully my product will satisfy my prospect’s needs. It seems to go well. Then my prospect thinks, pauses, and says: “Ok, but it is important to me that your product also does xyz, can you do that?” or “Other companies we are considering can do xyz, what about you?”. And I know we can’t. It usually feels awful. Everything inside me wants to SAY YES. Or at least something mushy like “I am sure we can make that work”. Or “I will have to check but I am confident that it can be done”. Or another of the hundreds of things I can say that are not a a no. Yet, I believe usually the best thing to say is ‘no, we cannot!’.

Why it is good to explain what you can’t do.

It builds trust. I believe that in making a sale, particularly a more complex sale as is typically the case in software, at least as important as features and performance or price is trust. Making a purchasing decision is always a risk, even when the price is low or zero. The buyer risks losing time, nerves, reputation, goodwill… and often money. Therefore building trust is a key element of the sale. Brand name, references, testimonials, free trials are all typical elements that help in this regard. I find that explaining clearly the limitations of my product is another great way of building trust.

It calibrates what you say about your product, and makes your positive claims much more credible. Imagine a sales meeting or call where all you do is talk about the brilliant properties of your product, and in which you say yes to all requests and questions. Your prospect has no way of knowing if you always say yes, or whether you just happen to have the ‘perfectly suited’ product.

It portrays your honesty and respect for your prospect. What is more honest than saying ‘I cannot provide or do this’? I believe that saying honestly and clearly where the limits of my products lie has often pleasantly surprised my prospects and helped me to build relationships with prospects.

It sets you apart from many competitiors (at least in software). Particularly in enterprise software claiming too much and agreeing to every client request has been commonplace. This phenomenon has even produced terms like ‘Vaporware’ or ‘Shelfware’. Vaporware is software (features) that is sold despite the fact that it only exist in the minds of, errr, software salespeople for example. Shelfware is the result of projects that never made it into production. Yesterday I was on the website of a sales forecasting provider that claims 99% forecasting accuracy. Sure. That reads like “I take my customers for stupid but I take them for a ride”.

It gives you a great opportunity to educate your customer. Especially in cases where the requested capability is unrealistic, and competitor claims are sales BS, explaining the reasons behind the limits of your products is a great way of educating your prospect at the same time as debunking your competition without sounding aggressive or defensive. By giving your prospect more relevant concepts to understand, and questions to ask, you will make it more difficult for your competition to sell to this prospect.

If you lose them, better lose them now... Unless you can and want to engage in selling Vaporware, it is in your interest to not waste time on a prospect that either has legitimate requirements or unwaveringly unrealistic expectations that your product does not meet. Particularly in SaaS where trials are the typical way customers evaluate a product, there is no hiding from the facts of what your product can deliver, even if you wanted to. It is better to bow out in a positive and constructive manner than spend your time on a low probability case.

....and they might just come back. It might just happen that reality hits your prospect and competition sooner or later.In this case, a vendor that has truthfully outlined the scope and limitations of his product might just become much more attractive.

Optimal service level and order quantity

Wed, 25 Jan 2012 10:47:30 +0000

In the inventory optimization literature, one of the most recurring concepts is the service level, i.e. the desired probability of not hitting a stock-out situation. The service level expresses the tradeoff between too much inventory and too many stock-outs. However, experts remain typically vague when it comes to choose service level values; a pattern also followed by most inventory software products...

That's why we have spent a bit of time to craft a formula that gives optimal service levels. Naturally, the optimality is not obtained without assumptions. However, we believe those are reasonable enough to preserve the efficiency of the formula for most businesses.

Then, another subject, that receives too little attention, is the optimal order quantity: the quantity to be ordered in order to minimize the combination of purchase costs, carrying costs, shipping costs, etc. As of January 2012, it's fascinating to notice that most of the industry still relies on the Wilson formula devised back in 1913. Yet, this formula comes with strong assumptions that do not make much sense any more for the supply chain of the 21st century.

Thus, we have designed another economic order quantity formula that emphasizes volume discounts (instead of a flat ordering cost) for larger purchases. The formula (or rather the approach) is fairly general, and could be applied to any pricing structure, including non-linear situations where specific quantities are favored because they matche the size of a crate or a pallet.

Both situations are illustrated with Excel sheets (so you don't even need Lokad to get started).

Big data in retail, a reality check

Tue, 03 Jan 2012 10:12:58 +0000

Cloud computing being so 2011, big data is going to be a key IT buzzword for 2012. Yet, as far we understand our retail clients, there is one data source that holds above 90% of total information value in their possession: market basket data (tagged with fidelity card information when available).

For any mid-large retail network, the informational value of market basket data simply dwarfs about all other alternative data sources, may it be:

In-store video data, which remain difficult to process, and primarily focused on security.
Social media data, which are very noisy and reflect as much bot implementations than human behaviors.
Market analyst’s reports, which require the scarcest resource of all: management attention.

Yet, beside basic sales projections (aka sales per product, per store, per region, per week …), we observe that, as of January 2012, most retailers are doing very little out of their market basket data. Even forecasting for inventory optimization is typically nothing more than a moving average variant at the store level. More elaborate methods are used fore warehouses, but then, retailers are not leveraging basket data anymore, but past warehouse shipments.

Big Data vendors promise to bring an unprecedented level of data processing power to their clients to let them harness all the potential of their big data. Yet, is this going to bring profitable changes to retailers? Not necessarily so.

The storage capacity sitting on display on the shelves of an average hypermarket with +20 external drives in display (assuming 500GB per drive) typically exceeds the raw storage needed to persist a whole 3 years of history of a 1000 stores network (i.e. 10TB of market basket data). Hence, raw data storage is not a problem, or, at least, not an expensive problem. Then, data I/O (input/output) is a more challenging matter, but again, by choosing an adequate data representation (the details would go beyond the scope of this post), it’s hardly a challenge as of 2012.

We observe that the biggest challenge posed by Big Data is simply manpower requirements to do anything operational with it. Indeed, the data is primarily big in the sense that the company resources, to run the Big Data software and to implement whatever suggestions come out of it, are thin.

Producing a wall of metrics out of market basket data is easy; but it’s is much harder to build a set of metrics worth the time being read considering the hourly costs of employees.

As far we understand our retail clients, the manpower constraint alone explains why so little is being been done with market basket data on an ongoing basis: while CPU has never been to cheap, staffing has never been so expensive.

Thus, we believe that Big Data successes in retail will be encountered by lean solutions that treat, not processing power, but people, as the scarcest resource of all.

Roadmap for 2012

Tue, 29 Nov 2011 10:00:59 +0000

For the third year (see the 2011 and 2010 editions), we will share some insights about the future developments of Lokad.

Forecasting Technology

Since the very beginning, forecasting accuracy has been the foremost priority of Lokad. Over 2011, we have extensively leveraged Windows Azure (our cloud computing platform) to develop forecasting models that would have been completely out of reach without the capabilities of the cloud.

We have made progress over patterns as simple as seasonality, trends or product life cycles. Those patterns are supposed to be well-known for decades, but the more we learn by looking at the data of our growing customer base, the more we realize that we are only scratching the surface.

In 2012, we are planning to dedicate efforts on forecasts at the point-of-sale level for both retail networks and eCommerce. This effort will boost the development of Shelfcheck.

Then, we will also explore alternative ways to make a better use of tags and events. More and more of our clients are now capable of feeding our forecasting engine with high-quality tags and events, which offer more opportunities to refine forecasts.

Pricing

The Lokad pricing for forecast consumption hasn’t changed since November 2009, and we don’t expect any significant change for 2012 apart from minor adjustments. However Shelfcheck will benefit from a distinct pricing, not directly bound to the forecast consumption.

Salescast

Over 2011, our webapp delivering inventory optimization has grown to a relatively mature and stable product. Contrary to what we announced last year, we have finally opted against the idea of importing data from Excel Instead, the majority of our users are now using our intermediate SQL format which offers a simple and reliable path to achieve complete automation with a minimum of efforts.

For the year to come, we will polish Salescast further, especially around the intermediate SQL format. Indeed, we feel that database administrators still struggle too much to import their data in Salescast. For example, we will provide better and more explicit errors messages.

Shelfcheck

Shelfcheck is our latest product, only announced a few months ago , that focuses on on-shelf availability optimization for retail networks.

At this point, a beta version of Shelfcheck is already in production on multiple stores in Europe. We plan to bring Shelfcheck out of its beta during 2012. Processing the ongoing sales stream of a large retail network at low costs is a tremendous challenge (even with the cloud). In addition, we want to establish Shelfcheck as the technology delivering the most accurate OOS alerts (out-of-shelf) of the market.

Hub

The “Hub” is the webapp in charge of managing registrations and subscriptions. Over 2011, we haven’t invested much effort on this webapp, and now, it feels somewhat antiquated, especially when compared to the more polished user interface of Salescast. Thus, in 2012, we plan to extensively refactor the Hub to simplify the management of users and subscriptions.

This roadmap isn't carved in stone. Don't hesitate to voice your opinion.

Lokad.Cloud vs Lokad.CQRS, tiny insights about the future

Joannes Vermorel — Wed, 23 Nov 2011 22:11:38 +0000

Among the (small) community interested by the software practices of Lokad to develop entreprise software over Windows Azure, Lokad.Cloud vs Lokad.CQRS comes as a recurring question.

It's a good question, and to be entirely honest, the case is not 100% solved even at Lokad.

One of the core difficulty to address this question is that Lokad.Cloud and Lokad.CQRS come:

from different backgrounds:
- Lokad.Cloud orginates from the hard-core data analytics back-end.
- Lokad.CQRS originates from our behavioral apps.
with different intents:
- Lokad.Cloud wants to simplify hard-core distributed algorithmics.
- Lokad.CQRS wants to provide flexibililty, auditability, extensibility (*).
and different philosophies:
- Lokad.Cloud is a sticky framework, it defines pretty much how your app is architected.
- Lokad.CQRS is more a NoFramework, precisely designed to minimally impact the app.

(*) without compromising scalability, however scalability is not the primary purpose.

Then, historically, Lokad.Cloud has been developed first (which is a mixed blessing), and, as we have been moving forward, we have started to partition into standalone sub-projects:

Lokad.Cloud.Storage, the O/C mapper (object to cloud), dedicated to the interactions with the Azure Storage.
Lokad.Cloud.AppHost, an AppDomain isolation layer to enable dynamic assembly loading within Azure Worker roles (aka reboot a VM with new assemblies in 5s instead of 5min). (**)
Lokad.Cloud.Provisioning, a toolkit for the Windows Azure Management API.

(**) Lokad.Cloud does not leverage Lokad.Cloud.AppHost yet, it still relyies on a very similar component (which was developed first, and, as such, is not as properly decoupled than AppHost)

Those sub-projects end-up combined into Lokad.Cloud but they can be used independently. Both Lokad.Cloud.AppHost and Lokad.Cloud.Provisioning are fully compatible with Lokad.CQRS.

The case of Lokad.Cloud.Storage is a bit more complicated because Lokad.CQRS because Lokad.CQRS already has its own Azure Storage layer which focuses on CQRS-style storage abstractions. In particular, Lokad.CQRS emphasizes interoperable storage abstractions where the local file storage can be used in place of the cloud storage.

The Future

As far I can speak for Lokad.CQRS (see the projet boss), the project will keep evolving focusing on enterprise software practices, aka not so much what the framework delivers, but rather how it's intended to structure the app. Then, Lokad.CQRS might be completed by:

tools at some point such as a maintenance console.
refined storage abstractions (probably event-centric ones).

In constrast, Lokad.Cloud will continue its partitioning process to become decoupled and more flexible. In particular,

the cloud runtime
the service execution strategy

are still very heavily coupled to other concepts within the execution framework, and likely candidates for sub-projects of their own.

Combining Lokad.Cloud and Lokad.CQRS?

I would not advise to combine Lokad.Cloud (execution framework) with Lokad.CQRS within the same app. At Lokad, we don't have any project that adopts this pattern, and the resulting architcture seems fuzzy.

However, if we consider the sub-projects of Lokad.Cloud, then the combination Lokad.CQRS + Lokad.Cloud.AppHost + Lokad.Cloud.Provisioning does make a lot of sense.

Then, it's possible to adopt a SOA architecture where some heavy-duty functional logic gets isolated, behind an API, into the Lokad.Cloud execution framework, while the bulk of the app adopt CQRS patterns through Lokad.CQRS. This pattern has been adopted to some extent at Lokad.

Out-of-shelf can explain 1/4 of store forecast error

Thu, 20 Oct 2011 07:00:37 +0000

The notion of forecasting accuracy is subtle, really subtle. It's common sense to say that if the closer the forecasts from the future, the better, and yet common-sense can be plain wrong.

With the launch of Shelfcheck, our on-shelf availability optimizer, we have started to process a lot more data at the point of sales level, trying to automatically detect out-of-shelf (OOS) issues.Over the last few months, our knowledge about OOS pattern has significantly improved, and today this knowledge is being recycled into our core forecasting technology.

Let's illustrate the situation. The graph below represents the daily aggregated sales at the store level for a given product. The store is open 7/7. A seven-day forecast is produced at the end of the week 2, but an OOS occurs in the middle of the week 3. Days marked with black dots have zero sales.

In this situation, the forecast is fairly accurate, but because of the OOS problem, the direct comparison of sales vs forecasts look like as if the forecast was significantly overforecasting the sales, which is not the case, at least not on the non-OOS days. The overforecast measurement is an artifact caused by the OOS itself.

So far, it seems that OOS can only degrade the perceived forecasting accuracy, which it does not seem too bad because presumably all forecasting methods should be equally impacted. After all, not forecasting model is able to anticipate the OOS problem.

Well, OOS can do a lot worse that just degrade the forecasting accuracy, OOS can also improve it.

Let have a look at the graph to illustrate this. Again, we are looking at daily sales data, but this time the OOS problem starts on the very last day of week 2.

The forecast for the week 3 is zero the whole week. The forecasting model is anticipating the duration of the OOS. The forecast is not entirely accurate because on the last day of week 3, replenishment is made and sales are non-zero again.

Obviously, a forecasting model that anticipates the duration of the OOS issue is extremely accurate as far the numerical comparison sales vs forecasts is concerned. Yet, does it really make sense? No, obviously it does not. We want to forecast the demand not sales artifacts. Worse, a zero forecast can lead to a zero replenishment which, in turn, extend the actual duration of the OOS issue (and increase further the accuracy of our OOS-enthusiast forecasting model). This is obviously not a desirable situation, no matter how good the forecast happens to be from a naive numerical viewpoint.

Bad case of OOS overfitting

We have found that the situation illustrated by the 2nd graphic is far from being unusual. Indeed, with 8% on-shelf unavailability (a typical figure in retail) and a rough 30% MAPE on daily forecasts, OOS situations typically account for 8% x 100 / 30 ≈ 27% ≈ 1/4 of the total forecast error being measured. Indeed, by definition of MAPE, a non-zero forecast on zero-sale day (OOS) generates a 100% error.

Because the fraction of the error caused by OOS is significant, we have found that a simple heuristic such as "if last day has zero sales on a top seller product, then forecast zero sales for 7 days" may reduce the forecast error from a few percents by directly leveraging the OOS pattern. Obviously, very few practitioners would explicitly put such a rule among their forecasting models, but even a moderately complex linear autoregressive model may learn this pattern to a significant extend, and thus overfit OOS.

Naturally, Shelfcheck is here to help on those OOS matters. Stay tuned.

Oddities of machine learning software code

Joannes Vermorel — Fri, 14 Oct 2011 13:24:05 +0000

Developping machine learning software is special. I did already describe a bit how it feels to be in a machine learning company, but let's be a bit more specific concerning the code itself.

One of most shocking aspect of machine learning code is that it tends to be full of super-short cryptic 1-letter or 2-letter variable names. This goes completely against the general naming conventions which emphasis readability over brievity. Yet, over the years, I have found that those compact names where best for mathematical / statistical / numerical algorithms.

Indeed,

Logic is typically overly intricate, with tons of nested loops and seemingly random stopping conditions. Hence, even if the variables were perfectly readable, the logic would remain show-stopper for any fast-reading attempt.
Variables typically hold intermediate computational results, which cannot be associated with 2 or 3 English words without being extremely ambiguous at best. It's not a = OnButtonClick but rather a = InterpolatedDetrendedDeseasonalizedQuantile90PercentsOfPromotionEffects.

As a result, extreme variable name brievity makes the code much more compact which in turns makes it easier to understand the logic. It forces the coder digging into the code to learn by heart the semantic of the variables (because names are cryptic), but this effort is only marginal compared to the amount of effort to grasp the logic itself anyway.

Then, magic numbers are all over the place, frequently inlined with the rest of the code. Again, for non-machine-learning, magic numbers are a big NO-NO, and a cardinal rule of sane software design consist of clear speration between data and logic. Yet, in statistical algorithms, those seemingly random numerical values are the result of the incremental tuning that is necessary to obtain the desired performance and accuracy.

There is no benefit in isolating the magic number, because it is used only once.
The actual numerical value is typically more insightful than the variable name. It helps the developer to get a sense of the behavior of the algorithm.

Then, it remains a good practice to add a lot of inline comments to justify the purpose of the magic numbers, and how they have been optimized.

If your code is super fast, you're probably getting it wrong. For most machine learning problems, it's better to try to take advantage of the outrageously large amount of processing power available nowadays to improve results. I am not saying that super fast code is bad in itself, but if your code is super fast, then it means that you've got room to go for more complex methods that would consume more resources in exchange for better, more accurate, results.

Unit tests are both very handy to validate small block pure-mathematical operations, and yet, quasi-useless for the bulk of the machine learning logic. Indeed, when it comes to statistical accuracy, there is no black & white, but only in shades of gray. As long performance is acceptable, the overall accuracy is the only metric that matter. In particular, it happens, from time to time, that a bug - aka a piece of code that does not reflect the original intent of the developer - turns out to behave well over the data. On average, bugs tend to degrade accuracy, but sometime, it just stumbles upon an interesting (and counter-intuitive) behavior.

Finally, Object-Oriented Programming is still around, but seldom used: Functional Programming is king. This pattern reflects the fact that the machine learning problem itself, either classification or regression is nothing but trying to build a big complex function to tackle real-world data.

Video: introduction to Salescast

Mon, 26 Sep 2011 10:00:43 +0000

Since Salescast now benefits from an extensively improved user interface, we have decided to produce a new video introduction as well.

Again, special thanks to Ray Groover for the voice over.

Seasonality illustrated

Mon, 19 Sep 2011 10:00:41 +0000

Seasonality is one of the strongest statistical pattern that can be leveraged to refine forecasts. Below, 4 time-series aggregated at the weekly level (159 weeks). Historical data are in red and forecasts are in purple. Vertical gray markers indicate January 1st.

When illustrating seasonality, everyone (Lokad's included) tend to use long time-series, much like the first three series here above. Indeed, it's more visual and more appealing.

However, long time-series do not represent your usual situation. On average consumer goods have a lifespan of no more than 3 or 4 years. Thus, long time-series are typically a small minority in your dataset. Worse, those long time-series might be outliers that do not reflect the behavior of other shorter-lived products.

Here above, the short 4th time-series is a much more representative case with less than 1 year of data. In such a situation, however, it's much less clear how seasonality can be leveraged. The Lokad trick to do that consists of using multiple time-series analysis.

Learn more on our seasonality definition article.

Video: How the Forecasting Engine works?

Tue, 13 Sep 2011 07:00:08 +0000

Questions about under the hood details of Lokad are frequent. We have recently added a big FAQ to our Forecasting Technology section. Today, we are releasing a new video that give the big picture on how our forecasting engine is working.

Again, special thanks to Ray Grover for the voice over.

Understanding a business better by asking simple questions

Matthias Steinberg — Wed, 10 Aug 2011 15:14:43 +0000

I love reading about and trying to understand new businesses. The fast pace of technology innovation especially in internet, cloud, SaaS and social media technologies has provided the basis from which a large number of new businesses and business models are emerging. Vente Privee and Groupon come to mind when thinking about successful European and US examples.

Understanding these businesses and their business models is not always easy. Start-ups tend to be protective of IP and key figures for obvious reasons. For example, one of the best kept secrets in European eCommerce is Vente Privee’s profit margin, and Groupon only recently let down the pants on profit, cash flow and other KPIs in the run-up to the IPO. Yet, even when transparency is given, it is easy to get caught up in thinking about market, strategy, competition and other contextual business elements without ever fully understanding the core workings and quality of the business model. A similar situation can occur in a young company that is still working on finding the right business model and in the process pursues and tests several distribution channels, products, client segments, etc. During this process, such companies can similarly miss the important and basic economics related to their choices, while focusing only on high-level strategies. I suggest approaching the analysis of a business and business model by asking the simple questions.

Asking simple questions

What works well for me is to understand in detail how a business makes money (not including internet start-ups that defy profit and cash logic in their early years). Essentially, I ‘follow a Euro’ in accounting and cash terms from start-to-finish. A good way of doing this is by looking at the ‘client economics’ of an average customer from the time of acquisition to end of the customer lifetime and figuring out the

step-by-step process
profitability and
cash flow.

This process is the backbone of any business, and by dissecting it I get to the core of how a business (model) works. It also provides a good basis from which to derive further analysis. A former investment colleague gave this piece of advice to me, and it can be applied to almost any business. Here is an example of an analysis made by asking the simple questions using a fictional, simplified eCommerce.

Step-by-step process

The typical new customer starts as a visitor in the eCommerce's webshop. This website traffic is ‘acquired’ exclusively via Google Adwords and a fraction of this traffic is converted into paying customers. Once a customer purchases a product, eCommerce fulfils the order completely in-house. This means that order handling, product inventory, packaging and dispatch, as well as service and support are handled in-house. Product is kept in stock for fast delivery. Customers can only pay by credit card, and returns are handled in-house.

Profits (and losses)

The contribution margin (revenue minus variable cost directly attributed to the purchase) of a purchase minus the customer acquisition cost is the profitability of the first purchase; if a certain average number of repeat purchases is given their contribution margins are added to result in the customer life time value. My average order size is 50€ at 20% contribution margin and the customer acquisition cost is 20€ (0.2€ per hit on Adwords, traffic conversion 1%). As a result, eCommerce looses 10€ (50*20% - 20) on the first purchase of a new customer, which would be a terrible business, were it not for repeat purchases. The average customer of eCommerce makes 2.5 purchases, breaks even on the second purchase (50*20% - 20 + 50*20%), and has a ‘life time value’ of 10€. Now these 10€ contribute to covering the fixed cost such as running the website, leasing the warehouse and machines, general marketing, company overhead, etc.

Cash cycle

This is arguably the most relevant view on the business, especially for young companies. Businesses die because they are out of cash, not profits.

eCommerce’s product is purchased for cash from a supplier (cash out), the customer is acquired on Google (cash out) and pays for the item with credit card (cash in). All the while eCommerce is paying fix costs for warehousing, operations (incl. order fulfilment), overhead, financing, marketing, etc. All these costs are assumed in this example as fixed, but might also be (partly) variable in practice. By placing this sequence on a timeline we can understand the cash profile of a customer. It becomes clear that we first have to invest cash in products and customer acquisition before we see the first Euro back from the customer, and need to wait for repeat purchases to recoup the cash invested. The result of this analysis is the cash cycle, i.e. the time it takes to recoup a Euro that can then be reinvested. It becomes clear that even if a new customer is profitable over its lifetime, eCommerce will need cash to invest in products and customer acquisition as it grows.

Using this framework to assess a business will point to, and answer some important questions, including:

Cash need (to grow)
Vulnerabilities/defensibility
Core skills and assets (e.g. very low customer acquisition cost, efficient order fulfilment, high contribution margins etc.)
Sustainability
Margin potential
KPIs that can be benchmarked against the industry (e.g. customer acquisition cost, inventory turns, customer profitability, gross margins, cash cycle.
Competitive advantages

While by far not covering all aspects relevant to the business, knowing the answers to such questions can help you when making important decisions related to a company, such as whether to 'back' a business with your money, time or even name. Groupon is a good example of a business where a close look at the economics of a single deal along the lines outlined above is extremely revealing. It is particularly interesting to do this from Groupon’s perspective (the client is the merchant) and from the perspective of the merchant (Groupon is the supplier, the consumer is the client) - especially when thinking of buying stock as an investor, or when considering selling a deal for one’s own business on Groupon.

Cold Calling: It's tough, but it works

Matthias Steinberg — Thu, 16 Jun 2011 22:09:00 +0000

One day our business will have sufficient ‘gravitational’ pull to sell by itself. Web visibility and traffic will be significant, conversion high, coverage in industry media extensive and the name part of the industry’s ABC. My phone will ring constantly.

Until then, If we do not proactively establish the contact with prospective large customers, investors, advisors, no one will. Surely, we are pushing heavily an in-bound marketing strategy which is successful in the SMB market, but the industry top 100 has not called yet.

Calling is still a powerful method and ‘center’ around which to build a targeted approach. The good news is: it works. I would make the claim that you can get people on the phone far beyond your wildest expectations. The fine print: It sucks. Are there ‘silver bullet’ tricks that can be passed on: I don’t think so. Success is 50% hard work, 40% psychology, 10% technique. Here are a few gotchas.

Getting ready to labor

Cold approaches are very hard work. They require dozens to hundreds of phone calls, emails, letters, research, ideas. The better prepared I am the higher the chances of success. The more relevant to the individual the more noticeable my communication is. It is repetitive, it is often boring. It takes blood, sweat and tears.

Building up patience

If anything, it will take time. It is not that I am at the bottom of my targets’ priority list, I don’t even exist on it when I begin. Patience is a key ingredient of persistence. It helps me stand out and to be there at the right moment. I try to learn about the individual, the organization, what is happening and what is on his mind.

Embracing rejection

Forget fame and money – let’s face it, the single most powerful motivation for me to work hard has always been praise. Interestingly, it seems only secondary from whom and for what, my system will purr happily as long as it is praise. And I believe I am no different from most people – I have seen this pattern constantly in my friends and colleagues.

Rejection is roughly the opposite of that. It is a cold, wet place. Unfortunately cold approaches deliver a good dose of it in the form of unreturned calls, deleted emails, negative feedback, and forgotten promises.

It helps me to know and expect this. The trick is to think positive and believe that it will work, while having a realistic benchmark on what to expect. Experience and practice definitively helps calibrate this benchmark. And, it will help in growing a thicker skin.

Keeping the moral high

I brace myself for a long feedback loop and savior the successes, as small as they might be. I know that I will not win them all – it is in the end a numbers game.

‘NOs’ are frequent and I try not to take it personal – it very seldom is. Secondly, I keep in mind that there is no universal ‘NO’. Situations can change rapidly. A ‘no’ today from a company is a ‘no’ from an individual, in a given situation and with changing priorities. A promotion, a new CEO, unexpected financial results … there are millions of reasons why the situation might change. A ‘no’ today is therefore rather a ‘no for now’.

Thinking small steps

A main challenge is to ‘legitimatize’ myself. Initially I will be filtered out by my contact’s physical and mental filters. Spam folders, secretaries, front-desks, trash cans and the depth of voice-mail and inbox are the playground. It often requires many small steps to increasingly gain legitimacy and mind-share of my contact.

Getting a personal recommendation or introduction is ideal, learning the name and building a relationship with the secretary is important, referring to these people in my communications helps, being persistent but polite, relevant (research) and timely is required. The better I understand what is on my contact’s mind, the more relevant and convincing I will be.

Enjoying it

This is the top game. When I enjoy it, my morale, style, work ethic, and conversion rate get a boost. And being in a good mood is the best of armors. Not all days are the same – I put more time into it on the good ones and will do something else on others. So: Smile while you dial.

A simple, non-technical definition of cloud computing

Matthias Steinberg — Fri, 03 Jun 2011 14:36:29 +0000

Last year, I found myself researching the market for investment opportunities in ‘cloud computing companies’, driven by the insight that this was a rapidly growing market. Yet, it felt a bit like hunting the Yeti as I was having a hard time understanding what exactly cloud computing is, and what it is not. Realizing that I shared this confusion with a lot of my peers, I thought it is worth sharing some insights I gained in the last month. I probably better emphasize that the following aims at explaining cloud computing purely from a market perspective; I leave the technical explanation (and heated discussion) to technology experts.

'Computing services sold through the internet like a utility’

There it is. Let’s take a closer look at this statement. ‘Computing services’ describes infrastructure such as computing power, storage and bandwidth but also ready to use applications. A programmer ‘renting’ servers in the cloud is an example of the former, Gmail an example of the latter. In both cases the user replaces a ‘physical’, on-premise resource such as physical servers or an email application (e.g. Outlook).

Yet, what really differentiates cloud computing from other technologies are its low cost, flexibility and scale.

The scale of the underlying, accessible infrastructure is unprecedented

Let’s start with what cloud computing ‘physically’ actually is: The underlying infrastructure of cloud platforms provided by vendors such as Google, Amazon and Microsoft are massive, high security data centers. Each vendor has built a network of these datacenters around the world.

When data usage and bandwidth exploded in the 90s, companies invested massive sums in equipping their data centers with extremely expensive ‘supercomputers’. Google, who was a driving force in the development of cloud computing, set out to develop a cost effective way of building and running data centers. I the process the company developed basic principles of cloud computing infrastructure. Core ideas include the use of thousand) of cheap standard servers instead of a few supercomputers which reduces equipment cost significantly, and the reduction of operating cost through a massive scale of each datacenter. Managing, maintaining and running applications on this infrastructure is part ot the technological challenge, and several complex software layers on top of this ‘army’ of small servers form part of the technology.

The massive scale of the underlying infrastructure does not only reduce cost but gives users access to an unprecedented amount of computing power and storage.

Competitive cost is the key to ‘mass market’ adoption

The most important achievement of this technology from a market perspective is the low cost at which cloud computing is available. While it has a number of heavyweight ‘selling points’, the primary driving force behind the adoption of cloud computing are ultimately its attractive economics. Cloud computing is not a specialized ‘niche’ technology; it rather serves the ‘mass market’ of companies and private individuals and therefore competes directly with the corporate data center and desktop computer. Today already cloud ressources are often significantly cheaper.

‘Elasticity’ provides a whole new way of ‘consuming’ IT

The term ‘elasticity’ is often used to describe the ability of the cloud computing user to adjust consumption to the actual need at any point in time, which in combination with a consumption based pricing adds to the economy of the resource from a user perspective. For example, Windows Azure charges for its services by the hour and/or megabyte. In contrast, corporate data centers for example must be built for peak times, and average capacity usage is extremely low.

The term ‘utility style’ is often used when describing the delivery model of cloud computing: The user chooses timing and amount of consumption matching his need, and is billed on usage – just like electricity.

My guess is when Steve Jobs presents the iCloud on Monday it will prove to be flexible, cheap and quite powerful - and I hope it won't be the name alone that tells you it's cloud.

LinkedIn DirectAds, early thoughts

Joannes Vermorel — Tue, 02 Nov 2010 14:08:53 +0000

I just started my first LinkedIn DirectAds campaign a few days ago. I had significant previous experience with Google Adwords, and I was interested to see how DirectAds could perform compared to Adwords.

From an outsider perspective, LinkedIn looks the perfect marketplace for a niche B2B software technology such as Lokad which specializes in demand forecasting. Indeed:

I know exactly the profile of the people I am trying to reach: vertical, job description, company size, location, etc.
My willingness to pay for each super-targeted lead is rather high.

DirectAds are extremely similar in their format with AdWords. The only minor difference is the presence of small 50x50 icon along your add (the illustration of this post is a screenshot of one of my DirectAds).

The core difference with Adwords is that instead of betting on keywords, DirectAds are selected based the profile of the audience you want to reach. The criteria available for audience filtering are:

Company Size
Job Function
Industry
Seniority
Gender
Age
Geography

Yet, it must be noted at that, at present time, only 4 (out of the 7 available) can be selected at the same time within a campaign. This restriction is rather odd and annoying. In my case, company size, job function, industry and seniority are good enough, but geography would have been a bonus too - especially for localized ads.

Then, the job function offers only 18 categories which is a very rough granularity. Again, I would have preferred to be able to directly specify keywords listed in job description entered by the LinkedIn members.

Finally, my initial selection is giving me about 14k members as my target audience. After 48h of display, I have 2k impressions for a single $2 click ($2/click is the minimal bid).

Very low traffic is probably the downside of LinkedIn DirectAds. With such a limited audience, even assuming a good conversion rate, but it will take months to recover the 2h spent initializing the campaign.

Wish list for Relenta CRM

Joannes Vermorel — Tue, 27 Jul 2010 08:25:53 +0000

At Lokad, we have using the Relenta CRM for nearly two years. It's an excellent lean CRM that comes with a core focus on emails which happen to represent about 90% of our interactions with clients and prospects.If you happen to be an ISV, Relenta is worth having a closer look.

Although, I have been missing a few key features in Relenta for a long time. Hence, I taking the time here to post my wish list for Relenta.

1. Accounts

Relenta only deals with Contacts yet, when prospecting larger companies, many contacts are typically involved. It would be much nicer if it was possible to create 1-to-many relationships between Accounts and Contacts. In particular, this would let the Relenta user browse at a glance all the latest interactions related to a particular account, instead of jumping from one contact to the next.

2. Recent updates

One of the feature that I like the most in wikis are their abilities to display the recent changes. Through recent change, you can gain immediate insights in what other people are doing, without having to bother to actually ask them.

Presently, there is no way to easily figure out who has been doing what in Relenta. It would much nicer if a stream of recent updates was available for browsing. In particular, display could be made more or less compact by aggregating updates per contact (or per account). Eventually, the stream could even be made available as RSS.

3. Activity capture API

The Lead Capture API of Relenta is a killer feature due to its simplicity. For an ISV, it's a super simple way to collect all trial registrations that keeps flowing through our online apps with extremely limited integration grunt-work.

Yet, although it's very simple to automate the Contact creation in Relenta, it's not possible to automate the insertion of Activities later on the very same contact. This feature would be extremely handy to automatically report payments, or any kind of noticable activities (in the case of Lokad that would be large forecasts retrieval for example).

4. Refined tagging

Tagging is one of the best idea of the Web 2.0 wave. It's a great way to organize complex yet little structured content.

Relenta already provide a minimal tagging system, yet there is no tag auto-completion (killer feature) and it's not possible to search against multiple tags. Pushing a bit more work on tags would be a great move forward to make the most of them.

5. iCalendar support

iCalendar is a very nice and popular format to send meeting request. Presently, Relenta does not support .ics attachments and meeting requests appears as completely garbled. It would be really nice if Relenta was support iCalendar with the possibility to acknowledge meeting requests.

BIG award for a TINY company (Lokad)

Joannes Vermorel — Wed, 23 Jun 2010 13:13:37 +0000

Lokad just won the Windows Azure Partner award of 2010. That's an extremely big award for an exceptionally small company. The last French company to get such as an award was no less than Dassault Systèmes, the largest software company in France. I am proud of the work done by the Lokad team.

Strategies Logistique event in Paris

Joannes Vermorel — Tue, 15 Jun 2010 11:31:02 +0000

I have been giving a talk at the Strategies Logistique event in Paris last week about cloud computing, supply chain and Lokad. Beyond forecasting, I believe that supply chain will be one of the entreprise area that will benefit the most in the next decade of the migration toward the cloud.

More pictures. Special thanks to Gilles Solard for the smooth organization of this great event.

O/C mapper for TableStorage

Joannes Vermorel — Thu, 03 Dec 2009 15:46:37 +0000

The Table Service API is the most subtle service provided among the cloud storage services offered by Windows Azure (with also include Blob and Queue Series for now). I did struggle a while to eventually figure out what was the unique specificity of Table Storage from a scalability perspective or rather from a cost-to-scale perspective as the cloud charges you according to your consumption.

Since the scope of the Table Storage remained a fuzzy element for me for a long time, the beta version of Lokad.Cloud does not include (yet) support for Table Storage although. Rest assured that this is definitively part of our roadmap.

TableStorage vs. others

Let's start by identifying the specifics of TableStorage compared to other storage options:

Compared to Blob Storage,
- Table Storage provides a much cheaper fine-grained access to individual bits of information. In terms of I/O costs, Table Storage is up to 100x cheaper than Blob Storage through Entity Group Transaction.
- Table Storage will (in a near feature) provides secondary indexes while the Blob Storage only provide 1 single hierarchical access to blobs.
Compared to SQL Azure,
- Table Storage lacks about everything you would expect from a relational database. You cannot perform any Join operation or establish a Foreign key relationship and this is very unlikely to be ever available.
- yet, while SQL Azure is limited to 10GB (this value might increase in the future, this is really not the way to go), Table Storage is expected to be nearly infinitely scalable for its own limited set of operations.

The StorageClient library shipped with Azure SDK is nice as it provides a first layer of abstraction against the raw REST API. Nevertheless, coding your app directly against the ADO.NET client library seems painful due to the many implementation contraints that comes with the REST API. Further separation of concerns is needed here.

The Fluent NHibernate inspiration

TableStorage has way much less expressivity than relational databases, nonetheless, classical O/R mappers are great source of inspiration, especially nicely designed ones such as NHibernate and its must-have addon Fluent NHibernate.

Although, the mapping entity-to-object isn't that complex in the case of TableStorage, I firmly believe that a proper mapping abstraction ala Fluent NH could considerably ease the implementation of cloud apps.

Among key scenarios that I would like to see addressed by Lokad.Cloud:

A seamless management of large entity batches when no atomicity is involved: let's say you want to update 1M entities in your Table Storage. Entity Group can actually reduce I/O costs by 100x. Yet, Entity Group comes with various constraints such as no more than 100 entities per batch, no more than 4MB by operation, ... Fine-tuning I/O from the client app would have to be replicated for every table, it really makes sense to abstract that away.
A seamless overflowing management toward the Blob Storage. Indeed, Lokad.Cloud already natively push overflowing queued items toward the Blob Storage. In particular, Table Storage assume than no properties should weight more than 64kb, but manually handling the overflow from the client app seems very tedious (actually a similar feature is already considered for blogs in SQL Azure).
A more customizable mapping from .NET type to native property types. The amount of property types supported by the Table Storage is very limited. Although a few more types might be added in the future, Table Storage won't (ever?) be handling native .NET type. Yet, if you have a serializer at hand, problem is no more.
A better versioning management as .NET properties may or may not match the entity properties. Fluent NH has an exemplary approach here: by default, match with default rule, otherwise override matching. In particular, I do not want the .NET client code to be carved in stone because of some legacy entity that lies in my Table Storage.
Entity access has to be made through indexed properties (ok, for now, there isn't many). With the native ADO.NET, it's easy to write Linq queries that give a false sense of efficiency as if entities can be accessed and filtered against any property. Yet, as data grow, performance is expected to be abysmal (beware of timeouts) unless entities are accessed through their indexes. If data is not expected to grow, then you go for SQL Azure instead, as it's way more convenient anyway.

Any further aspects that should be managed by the O/C mapper? Any suggestion? I will be coming back soon with some more implementation details.

Serialization in the cloud: SharedContract vs. SharedType

Joannes Vermorel — Thu, 03 Dec 2009 10:00:31 +0000