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:

How to not evolve your organization's IT dept.

• Don’t expect excellence
• The last thing that an enterprise wants is for IT systems to run smoothly.  If they did, then support people would not have work to do which in turn leads to layoffs and a bad public image.  The IT dept should strive for barely adequate.  That way bugs will be introduced and all stay employed.
• Don’t open source your software
• The software you write is critical to your business and the data is irrelevant.  The success of your business involves how well the IT department keeps its secrets and has nothing to do with how many products or services you sell.  Open sourced software will also be instantly sabotaged the moment it is released because it is not possible for a person external to your organization to want to make your software assets a success.
• Don’t experiment
• The last thing an IT department needs is to try anything new.  New things cause problems and break, and they cost more money with less return to the business value.  Additional cost will also be incurred when engineers need books or training.  All new ideas must be squashed immediately.
• Don’t plan or design
• The last thing the IT department needs is a direction.  IT people love to wander aimlessly through the hallways or just surf the web.  They also get the best sense of job satisfaction from collecting a paycheck for producing zero output.
• Don’t support your engineers
• Engineers aren’t smart.  They were not hired to solve problems, only to put hands on the keyboard and type pages and pages of computer-understood text.  They certainly don’t know the organization’s systems nearly as well and the person(s) sitting in offices on the top floors of buildings.  Engineers are also certainly never to be interested in solving business problems.
• Don’t care about who you hire
• Talented engineers are egotistic and for some reason like to be compensated for their potential they bring to an employer.  This is not monetarily feasible.  Since all engineers produce at the same pace and level, it is much more economically sound to hire 3 or 4 college graduates for the price of 1 experienced engineer.
• Don’t build an engineering culture
• Since talented engineers are not smart and are expensive, we don’t want any more of them around.  Talented engineers tend to attract each other like magnets.  The IT department must keep engineers as far away from each other as possible or else the organization will get overrun.  Also, all public images of the IT department must be kept as un-sexy as possible to prevent talented and expensive engineers from wanting employment in the organization.  Especially do not market the IT department to anyone, lest engineers learn what a pleasure it is to work in your organization and will seek employment there.