Event Driven Architecture and Retail

For those of you who don't know me, I currently work in the retail industry.  Software written for the retail industry is prime for Event-Driven Architectures (EDA).

Almost everything that occurs in a store is an event:

• Completed sale
• Inventory arrived at store number 123
• Inventory loaded on to a trailer 321
• Sales start

Events in a retail enterprise stream from system to system.  These streams are defined by business processes like an Item Setup process or a Sale Process.  For example, when a Sales Complete event occurs, both the accounting and inventory systems take action.  The accounting system posts the sale to that stores ledger.  The inventory system decrements that item's store count.  A change in store count below a threshold could in turn trigger an Inventory Low event.  A replenishment system at the warehouse gets notified of this event and schedules a replacement item be pulled from the warehouse stock and be shipped on the next available trailer.  Now if the warehouse stock is below a threshold, it could then fire a Stock Low event.  In turn a purchasing system could cut a purchase order to the vendor and so on.

Historically our company performs a great deal of batch processing (COBOL on IBM mainframes), especially at night.  All of that processing has undesirable side effects:

• table locking
• delayed processing
• no real time analytics

Sometimes I get asked, "Why don't your stores open at 12am on black friday like Wal-Mart or Target?".  The simple answer is "We can't!"  When batch is running, we cannot post sales due to table locks and our batch runs from 11pm to 5am.

Apply that situation to the data flow above.  The accounting and inventory system is working with yesterday's data.  Replenishment is working with data 2 days old.  The poor purchasing system is utilizing 3 day old data.

Okay that is a bit of an extreme example, but the point is still valid.

I'm not saying that there isn't a place for batch processing in retail because I believe that there is a place for it.  What I'd like to see is a drive in using EDA within our shop and in our B2B relationships.  Let the events stream!

Maybe soon I'll look at reactive streams and some frameworks which implement it like Akka streams and RxJava.

Inverted Management Structure and Agile Practices

Fig 1

The Inverted Management Pyramid
The Inverted Management Pyramid (IMP) is a reversal of traditional management styles.  In this style non-supervisory roles, those closest to customers or production processes are placed at the top of the pyramid(Fig 1).
  Each level supports the level above, by trusting and enabling the level immediately above to accomplish the organizations goals.


Agile Software Development
Part of the core of Agile practices is the idea that smaller feedback loops result in decreased development time/costs and/or software that more accurately meets the businesses needs.  This is due to increased communications between the development team and the line of business, often mediated by a role called the Business Analyst.  In this sense the development team almost operates autonomously.


How they work together?
If the development team is nearly autonomous by working directly with the line of business, then what is the function of management?  I have heard that it is a common scenario of IT shops that adopt Agile practices that those in management operate in a very chaotic fashion.  Referring back to the IMP, the role of management in an Agile shop is to ask this question to the level above "What do you need?".  On the Agile teams I've been involved with, the top-most role to ask this question is the Iteration Manager, but that should not be the only role asking that question.

Needs that can be solved by Management

• Contracts - negotiations, authorization, etc
• Financial - budget management
• Human Resources - hiring, reviews, salary, etc
• Escalations - work with management in the line of business to resolve issues to which the team is unable to resolve themselves

EventSourcing Example

After watching the "An Autobiography of a Reactive Application" video from ScalaDays 2014, I became very curious about EventSourcing and CQRS (Command Query Responsibility Segregation).  I find the EventSourcing pattern very interesting because my team and I almost used this pattern without actually knowing anything about the pattern beforehand.

EventSourcing does not store the current state of the app but instead keeps an "audit log" and reconstructs an object's current state from the log.

My quick and dirty sample: