"Order" as an app

Concept catalog
1

Hello

Is an “order” a concept or an app? I quote Daniel’s thoughts on an email stream, in order to port the discussion to this forum:

" I’ve been pondering exactly this example (but thinking about Amazon and how I’d describe its behavior with concepts). The way I currently see it is that there is a concept for an item type in a catalog (a book with an ISBN, for example); a concept of an item that is purchased (I might call this concept “shopping cart” because it has actions for changing quantity, submitting the order, etc); a concept of a payment in return for some goods; a concept of a warehoused item, with issues of being in stock, finding the item, etc; a concept of packaging, perhaps, in which multiple items are assembled into a box; a concept of a shipped item that has a manifest, tracking etc; and then finally concepts such as return merchandise authorization. In a system like Amazon’s, all of these must be synchronized together. In a conventional implementation, you might have a single order record with fields corresponding to each of the concepts (and some applying to more than one concept). Now the question that you seem to be asking is: is there a single concept that somehow fits all of these concepts together, and has in its operational principle the fact that an item is usually bought, stocked, packaged, shipped, returned, etc."

Indeed, it seems that we could see an order as an object which purpose is traceability of the transaction, which computes the current statuses (ordered, paid, packed, shipped…) and keeps track of the full history of events. It is an object which has memory and which is stateful.

In terms of usage, an order file should be accessible by the customer service, by the customer herself on her personal page, but also by bots which track pending orders, lost orders, claims, and so on.

In this regard, it looks like there would be an order status and order history concepts, which would be synced by an order app with events happening in the billing and logistics systems.

But an order is also more than that. It is foremost complex business logic, which holds the rules binding the actions together, for example that you issue a bill only after shipping, or that you accept returns 90 days after purchase. Of course these rules may themselves be depending on the customer VIP status, or on the product type, or some logistics constraints. Object logic seems to sit inside concepts rather than apps, if I am not mistaken?.. But given the flexibity required on “business logics” should’nt we make that a concept on its own sake, which would be attached to a particular order given the meta-rules outlined above?

2

I think “order” may be too abstract. Here’s my thinking about that.

There was a time when order forms were a thing and there were digital counterparts. On the books, the order form was tied to a customer and pricing of line items (product and quantity entries) was obtained by consulting product information. Discounts might apply at that level and also the overall order level, tied to some particular triggers.

The confirmation of orders and the fulfillment of orders also introduces matters of inventory and in some sense individual inventory entities, perhaps made non-anonymous when tied to an order line item and possibly returned, lost/damaged in shipment, etc. A great inventory connection has to do with online selling of reserve-seat ticketing to events. It is similarly tricky with regard to airline and similar travel arrangements.

There are also connections with systems of taxation, shipping–including across custom boundaries, and the accounting system of the firm and the management of accounts payable and accounts receivable and the provision of management and required reports (it all being subject to audit).

It may be useful to consider these instruments (forms and reports, transaction records) at some level and not abstract too much past them. Inventory items sometimes have customer destinations (that happened on computer mainframe assembly lines and also in the factories of custom-ordered automobiles). Passenger aircraft are a great example. These are essentially customized, every one, as-built and also as maintained.

If I am understanding the application of concepts here, one needs to simplify. How the business process is characterized might not be directly-reflected in the persistent forms of record. There is such a thing as order/shipment status, but it is on the surface a simple thing, even when tied to a delivery arrangement.

A lot of this is not visible to the customer, although more might need to be visible in different ways to customer service and to something like the billing office.

I do think that a concept-based approach is called for. In particular, it is useful to consider the conceptual model(s) of the actors in such a system and how those are afforded.

Years ago, I had a discrepancy with a mobile phone bill. It took me a while to realize that the customer service rep that I was speaking to did not have on-line access to my bill, but had to figure out and resolve my problem from a completely different view of the system. Stuff like that still happens.

An afterthought: When these systems are automation supported, maybe even completely manual ones, there are ways to intervene in the strict/automatic procedures. In those cases, those empowered to correct records, alter orders, offer rebates, have ways of doing so that require authorization and entry of some sort of annotation that explains the action. It is inconceivable to automate every detail, even at massive scale. Human systems all need a way to over-ride the automated way of doing things.

Regarding the afterthought and how stuff still happens. Recently, I and my spouse started receiving bills from a health-care system in which we were being offered installment repayment systems for large amounts when our balance dues were actually 0 or some small amount. I have no idea how those were produced and how they ever left the IT department of the billing organization. In my case, there was a co-pay balance due and that had been paid in advance of treatment and weeks before the closing for billing. It turns out that there is some sort of back-office process by which payments from credit card systems are applied to the individual accounts, and that had not been happening. This was part of a change of systems along with some mergers of hospital systems.

I see desperate need for concept-based design and development of far more than the UX surface of systems. Management issues are also plentiful.

3

@Henri: I agree with your observation: that somehow there is too much going on in the synchronization of the other concepts (that are not an “Order” concept) to be relegated to the glue in the app. I see two options here. One, which I resisted in EOS, but I’m coming round to, is to be able to form concepts recursively, so Order becomes a composition of several smaller concepts (that handle purchase, fulfillment, shipping, etc). The other, which your narrative hints at, is to think of Order as a concept independently of all the others that manages the workflow, traceability, status, etc.; it is then composed with the other concepts to form the app. That’s appealing because you could imagine such an Order concept being generic and domain-independent.

4

@orcmid: Your examples are very compelling, and I think it would be really interesting to formulate some of the intricacies of reserve-seat ticketing as concepts. Your point about human intervention is well taken. My assumption, in concept terms, is that these interventions are expressed as concept actions that the customer service rep can perform (even if the user can’t), which are chosen to compensate for the problem at hand. Maybe when you design a concept you could figure out, given a set of things that might go wrong, what compensatory actions might be needed (beyond the actions already in the concept).

5

I keep thinking there is a data-system model under here and it serves as conceptual model around what the items and relationships represent. Then one can pose transactions and consider validation and verification as well as integrity of the system and its maintenance.

Users of the system then have view into it and ways they can interact via conduction transactions. That can involve interactions with external parties, like things a customer service rep would do, how someone would take an order over the phone or review one entered by an external party. The interfaces should evoke appropriate conceptual models of operators and users, and that might be fed back and reconciled with the data-system conceptual model.

So layering and interactions between layers and within layers.

Just thoughts. I need to get more exposure to concepts and how applied in this kind of organization of a system. I presented it bottom-up (interior first) but its conceptualization would be more based on understanding of intended purpose and fitness for that.

6

I agree with the directions of this stream of thoughts… It would be great to have a real project to work on. May be there are already some?.. I saw one post proposing one…

@dnj, your intuition to “resist” concept recursivity seems to me (also intuitively…) quite right, because you would lose the “locality” of concepts, you would have “hard-wired” dependencies, if I am not mistaken. So you would have also modules or libraries of concepts, etc. And then It seems that the framework would start to look like a functional language. But of course these may be superficial remarks.