Item Changed Location Exception Design Pattern

Background:

On a previous trip to visit my son, I met a student at Arizona State University (Alex Wood). Alex is on a software development internship while he finishes his degree. Alex and I had a great conversation and I promised Alex I would keep him updated on technologies that I am working on. It is always fun to engage with young people that are eager to learn. Alex is going to be a rock star technologist.

The Business Problem:

Understanding the business question is always the most important step in creating a good technology solution. The question is, "When a person changes an item, where is that person located?" This question is very similar to a supply chain question UPS had in 2001 when they first launched e-Logistic Online Tools. The supply chain question was, "When inventory falls below a certain level, where is the product located in the supply chain?" Overtime I see business questions or problems in different industries that can be solved using the same design pattern. The key is to abstract the nouns in the business question with generic words like "Entities" or "Items".

The abstracted business question is, "When an Item changes, what is the location of the Entities related to changed Item?" Below is a good design pattern that solves this business question regardless of the industry. You can replace "Item" or "Entity" with any industry specific noun.

Item Changed Location Exception Design Pattern:

The "Item Changed Location Exception Pattern" is ideal for the business question described above.

• Step 1 - An Entity (someone or something) causes the Item to change
• Step 2 - The system that manages Item raises an Item Changed Event notifying all interested systems that the Item has changed
• Step 3 - Get the location of the person (related Entity) that caused the Item to change
• Step 4 - Compare the location of the Item to the Person (related Entity) to see if a location exception should be raised
• Step 5 - If a location exception has happened, notify everyone of the exception
• Step 6.1 - Notify anyone interested of the exception
• Step 6.2 - Store the location exception for historical reporting

The Importance on Product Agnostic:

This concept of product agnostic architecture and design was forced on me very early in my career. When I first became a Java Architect for Encore Development back in 1999. My Chief Architect specialized in the Microsoft technology stack. As a matter of fact, I was the only Java Architect in the company. Although I was the Java Architect, all of my designs had to be approved by the Chief Architect (a Microsoft technologist) before getting proposed to our clients.

Any diagrams or documents that included:

• NetDynamics, Weblogic, WebSphere or Apache
• MQ Series or JMS
• DB2 or Oracle DBMS

Would have be to corrected with words like:

• HTTP Server
• Pub/Sub Provider
• Relational Datastore

The conflict of having all my clients operating Java shops but having my design recommendations approved by a Microsoft slanted Chief Architect forced the separation of architecture and design from product selection. Although I benefited in the long run, the Microsoft Architects used words like IIS, MS SQLServer and MSMQ all the time. Since the Chief Architect was absolutely brilliant, I never called him out on the discrepancy of my reviews...(lol)

I could write all day about companies that have asked me to architect or design a solution and the first question they ask is..."How should we use bla, bla, bla product?"

Closing:

Many design patterns can be abstracted and applied to different industries if you look beyond the nouns. After 20 years my most impactful read remains:

Products, languages and tools will come and go but good design patterns will live on.

Alex, If you find the opportunity to use this pattern in your career, remember to send me a message.