CQRChess: Learn about our unique approach to building software
Chess is often heralded as a metaphor for life, love and war, but can we learn some lessons about business intelligence from the game as well?
Chess has a rich history of studying masterfully played games to see what worked well, and what ended in disaster.
Can we structure a business around the same kind of data-driver reverence and consideration?
It’s the journey, not the result.
Like sports people, the grand masters of chess are revered not only for their results, but for the way those results were achieved.
Recovering from a skillfully executed Blackmar-Diemer Gambit to win the game flamboyantly is as important as the win itself.
To convey the contents of a match, chess has a standard notation, called PGN, “Portable Game Notation”, your business likely doesn’t have something similar, but it could!
Even if you can’t read PGN or don’t play chess, the advantages are immediately obvious.
A PGN transcript looks like this, and can be used to replay a game for later study:
1.d4 Nf6 2.c4 e6 3.Nc3 Bb4 4.e3 0-0 5.Bd3 d5 6.Nf3 b6 7.a3 Be7 8.c×d5 e×d5 9.b4 c5 10.d×c5 b×c5 11.b×c5 B×c5 12.0-0 Qe7 13.Bb2 Nc6 14.Qa4 Bb7 15.Rfc1 Bd6 16.Qh4 Ne5 17.N×e5
Applying this to business intelligence
Just as the PGN shows us how a specific chess match unfolded, we can do the same for our customer interactions.
Most web based software will update, or overwrite data in the database, take for example an order in a typical hypothetical E-commerce system:
UPDATE ORDER SET FIELDS id [ 101012345 ] status [ pending shipping ] products [ 1× milk , 2× eggs , 10× chives ] price [ 54.00 USD ] shipping address [ example street 123 , exampleville , 90210, CA ] billing address [ the office 456 , worksville , 90210, NY ] contact details [ max exampleman , email@example.com , 776-2323 ]
This is the business equivalent of knowing that white beats black.
It certainly can’t express that it was an epic battle where the user was torn between buying the makings of a pizza, swung the opposite way and nearly resigned themselves to eating a healthy salad, but settled on an omelet.
If we could express the user’s interaction with our product as service, not as a series of final steps but as a journey, a series of changes to the “board”, the state of their relationship with the product we’d have a much better insight into their behavior and be able to serve them better.
A notation to store “changes in state”, or “moves” made by a customer will be wholly unique and distinct for any given project or business domain, but extending the E-commerce example, the “moves” the customer made before closing the game by submitting their order might look something like this:
0 | s = begin_new_anonymous_session("Firefox, Windows, 1900x1280, 126.96.36.199") +02s | request_page_login_form(s) +15s | submit_page_login_form(s, "firstname.lastname@example.org", "•••••••••") +17s | search(s, "pizza") +18s | search(s, "salmon") +22s | search(s, "omlette") +24s | add_product_to_basket(s, "milk", qty: 1) +26s | add_product_to_basket(s, "chives", qty: 10) +26s | add_product_to_basket(s, "butter", qty: 1) +26s | add_product_to_basket(s, "eggs", qty: 1) +30s | visit_checkout_page(s) +34s | remove_product_from_basket(s, "butter", qty: 1) +35s | set_billing_address(s, [the office 456 , worksville , 90210, NY]) +36s | create_order_from_basket(s)
This annotation is a pure fabrication for the purposes of illustration, however it should be evident how taking this transcript of their interactions with the software, and using that to derive the above order state allows preexisting legacy systems to keep operating, whilst collecting much much more entailed information, allowing your business analysts to ask (and answer) questions such as:
- How many people are removing items from their basket a few minutes before checking out?
- How many searches do people conduct before putting a product in their basket?
- Do people coming back to our site log in before shopping, or when finalizing their order?
Without this information your business analytics team might be lucky if they even know whether this order has been changed since it was placed, or how long the user took from landing in your application until placing an order.
Collecting data in this way is certainly more challenging than the simple path, but the business value cannot be argued, with a small shift in developer mindset the benefits of this approach can be enjoyed in virtually any field.
That’s Wacku’s way
This approach to building software is by no means unique, it’s used in banking and insurance, not to mention the stock markets and other domains.
It’s rare however to see it applied to normal businesses, until relatively recently the cost of storing this amount of data was prohibitive, and most businesses could ill afford the overhead.
In contemporary projects, the biggest obstacle to building software in this manner is inertia. Frameworks and languages do not encourage this style of application design.
Talk to us today if you think your business could benefit from this deep insight into your customer behavior.
(c) Author L. Hambley