Big Smokes - Who cares about manufacturer stock levels?

[J J Wright]

The Big Smokes requirements document contains the following Inventory related statements:

Big Smokes has an existing inventory system that tracks all cigars they have in the warehouse

Big Smokes manually calls their manufacturers to check the availability of a cigar. This availability check should be automated. Each manufacturers has an inventory system that uses an industry standard interface based on the Java Message Service (JMS)

Whilst the first step of the Check Availability use cases is:

System sends a request containing the product ID to the inventory system

I think it's reasonable to assume that Big Smokes maintains stock, in its own warehouse, of all its saleable items. The first step of the Check Availability use case, “[the] system sends a request containing the product ID to the inventory system”, reinforces this. The use of the word “the” implies the inventory system is singular, i.e. the Big Smokes warehouse inventory system.

Considering Big Smokes has invested $2m in increasing its warehouse capacity I would assume they also have some kind of demand forecasting and/or supply chain management software in place. In which case why on earth would you ever need to query a manufacturer's inventory system. We know that Big Smokes has multiple sales channels (shop, mail order, and now online) so any demand forecasting and supply chain management should be integrated with the inventory system.

In which case, the important number for Big Smokes is not a manufacturer's stock level but their agreed lead time. It is entirely up to the manufacturer as to how they implement this. i.e. their mix of stock level and manufacturing batch quantity.

So my question is; why are we being asked to query a manufacturer's stock level?

The only possible reasons I can think of are:

There are some cigars that big smokes does not hold stock for (however, this is in no way evident from the workshop output or use cases).

Big Smokes entire demand forecasting and/or supply chain management process is entirely manual. In which case checking whether or not a cigar is available electronically is a waste of time as they'll still have to pick up the phone to place an order!

As per usual, any thoughts would be greatly appreciated.

Regards,

Jonathan

[Ionut Bucurescu]

Another reason would be if the stock quantity is not enough to fulfill an order.

[J J Wright]

Another reason would be if the stock quantity is not enough to fulfill an order.

OK, say a massive order comes that clears out all the stock in the Big Smokes warehouse. You basically have two options:

Decline the order, which makes no business sense.

Notify the customer there isn't enough stock, increase the time to delivery to factor in the manufacturer's lead time, give the customer the chance to proceed based on the new delivery time.

In the second case the Big Smokes inventory level will fall below the reorder level. This in itself should be a trigger for updating demand forecasts and placing a new order for more product.

All Big Smokes cares about is how long it takes to get the product. The manufacturer may show only one in stock but at the same time may have just started a production run of 10,000. In this case, simply knowing the stock level is not enough. In the above scenario Big Smokes would decline the order on the basis the manufacturer only had one item in stock when the reality was 100s more were just about to be made.

Maybe I'm reading more into this problem than is warranted but it makes the assignment unnecessarily complex when some of the requirements make little or no business sense.

[Ionut Bucurescu]

I think the focus here is not on the manufacturer's inventory and stock management, so you don't need to care that the manufacturer displays only 1 item available but there are more items in production.
For sure Sun included the statements about manufacturer with a purpose. What is important here is that you can check the availability using JMS in real time. There is possible to remain out of stock not only with a massive order but with many lower quantities orders if the sales were not anticipated correctly. In addition to the two option identified by you, the customer might want to order only the quantity that exists in the stock or it might cancel its order if the delivery time it's unacceptable.
You must keep it simple and write very clear your assumptions if it cannot be deduced from the requirements.

[J J Wright]

What is important here is that you can check the availability using JMS in real time

I still can't see a use case for this when you assume the following (which is pretty much how any business works)

1. Item stock level falls below reorder level.
2. A demand forecasting module calculates the reorder quantity
3. A procurement module places a new order with the manufacturer
4. The manufacturer acknowledges the order and responds with a lead time
5. The retailer's inventory system is updated with the new lead time

Any subsequent orders for the out of stock product will use the updated lead time to provide a modified delivery time to the customer.

At no point do I need to query the manufacturer to find out the availability of a product. If they accepted my order I have a lead time. If the manufacturer can't fulfill the order it's flagged as unavailable or discontinued.

Sure I can include in my assumptions that the business model is suboptimal, the scenario nonsensical, and that despite spending $2m on warehouse improvements they have an absurd or non-existent ERP system... But it still doesn't make sense!

[Ionut Bucurescu]

What if there is no forecasting module? Even if there is one, there might be periods when it fails to do good anticipations. Also as you said there might be some expensive cigar types that the BigSmoke does not hold in the warehouse and orders them from the manufacturer's inventory only when ordered by the customer.
This is the way how a lot of household appliances online stores are working. They are listing some items labeled as in stock or not. The customer can still order an item that is not in stock.
Also in the car industry the process is the same. The customer chooses its car type and accessories. The dealer tells if such a car is available in its or in its importer warehouses, if not the importer orders the car to the manufacturer. The manufacturer starts the production of the new car if it doesn't have it in its stock.

So, lets say that the customer orders a quantity of some kind of cigars. The system sends the product id request to the BigSmoke inventory. The inventory sees that it contains only half of the requested quantity. In this case the BigSmoke inventory will query the manufacturer inventory that responds with the quantity available and with the delivery date.

[J J Wright]

Hi Ionut. Thanks for your feedback on this issue - it's very much appreciated.

No worries; I just have to introduce some additional steps to basic flows of the affected use cases.

[Rajashekar Akula]

Hi Jonathan,

I have got the same assignment, started working on it since last couple of weeks. I totally agree that the check availability of a product should be queried from big smokes inventory system and not from manufacturer inventory systems. Check availability use case clearly says that the inventory system sends response with the number of units(given product) available for sale. So if we assume that the customer should enter the quantity within these limits i.e., les than or equal to the number of units available for sale.
I have a question here - Check availability of a product is queried when the customer selects a product in search catelog and adding a product to the shopping cart. As per the use case, the checkout use case does not check the availablity of a product and the customer can modify the quantity. When the customer modifies the quantity during checkout, Should the system check the quantity against the inventory system. What is/was your assumption? Please correct me if my assumption does not make any sense..

BTW, Did you already submitted the assignment or still working on it?

Thanks in advance,
Raj

[J J Wright]

There are basically three conclusions you can come to here:

Sun have been incredibly sloppy and/or lazy with the assignment, or

We're being asked to design what amounts to a toy e-commerce system, ignoring details of the problem domain in the process, or

The "intensive series of discovery workshops with the in-house business analysts and subject matter experts" constituted an early phase of requirements analysis during inception, i.e. before the key (architecturally significant and high-value) use cases were identified and written in detail. For this to hold true you have to assume the discovery workshops, although intensive, were very brief and not equivalent to an extensive requirements workshop which would typically output the key use cases in a fully-dressed format. This is supported by the fact a fully-dressed use case would include extensions, whereas the use cases in the Big Smokes requirement document don't. The availability check for a third-party manufacturer's product would, therefore, be part of some alternate flow, which you'll have to concoct yourself.

You also have another choice, which is very much rooted in the process of iterative development:

You assume the in-house business analysts and subject matter experts are either really bad at their job, don't understand inventory, or simply forgot to include an inventory allocation step in the basic flow for the checkout process, or

The inventory allocation step and it's associated impact on order status was not deemed architecturally significant or high risk and as such was consciously left out of early iterations. You could support this argument by talking about the fact there's no mention of tax calculation, another key part of any e-commerce system.

At the end of the day there are no right answers. You just have to pick one and argue your case. I do, however, think it's really important that you look at your assignment, the artifacts you've been provided with, and the artifacts you've been asked to produce, in the context of some development process, otherwise you can't really make, or back-up, your assumptions.

[J J Wright]

The only plausible scenario I could come up with for querying a third-party manufacturer's inventory was if Big Smokes didn't stock some items in it's warehouse. In this case you check a manufacturer's inventory the same way you'd check you're own inventory. The difference arises when it comes to allocating inventory to an order. For a non-stocked item you have to raise a purchase order with the manufacturer. Acceptance/confirmation of the purchase order is equivalent to allocating inventory in the Big Smokes warehouse.

whichever way you look at it the use cases are pretty bad. Sack the in-house business analysts and subject matter experts!

[Sharma Ashutosh]

But if you look at some of the leading e-commerce websites, they won't allow a customer to add an item and checkout if the item is "unavailable". To what extent can we change the use cases?

[J J Wright]

But if you look at some of the leading e-commerce websites, they won't allow a customer to add an item and checkout if the item is "unavailable"

This is true. I resolved the issue in my own mind by just ignoring what might happen in the real world and concentrating on the actual requirements. If suppliers are happy to expose their stock levels we have to assume they are managing their stock effectively. If sales are lost because of poor stock / supply chain management, then that's an issue for the businesses concerned, not us as architects.

In addition, Big Smokes may not have a close relationship with the manufacturers of some of its more peripheral products. In which case, inventory levels are all you have.

With regards to your comment on adding a product to a cart; I agree. If you look at the requirements, and in particular the order of the basic flow for the "add product to cart" use case, I think it's clear you can make inferences along the lines you mentioned. The thing to remember about inventory levels is that they can be almost instantaneously out of date for any fast selling product. Again, it's up to the business to manage its stock levels accordingly if it wants to avoid race conditions for items when stock levels become dangerously low. In effect, you can't architect for poor management.

With regards to changing the use cases, my advice would be don't do it. We have to assume the domain experts knew what they were doing, although we are free to interpret their work in whatever way we see fit - that's what the assumptions part of your submission is all about. If you're unsure about your assumptions for a particular issue, then design for protected variation so the architecture can easily adapt to change.

Good luck

[Bigwood Liu]

"If you're unsure about your assumptions for a particular issue, then design for protected variation so the architecture can easily adapt to change. "

This is realistic.

[Ranganathan Kaliyur Mannar]

I think it is a simple case of Sun wanting to test our ability on how we include interaction with third parties in the design - via web services, JMS, CORBA and what not - in this case, they just want JMS... just makes the problem more complex...

[Bigwood Liu]

That is right, and that is what I thought when I got the first glance at the assignment. But problem is the JMS can't be fitted in the scenario for manufactures' availability checking, unless there are unreasonable assumptions. In addition, from the assignment use case, this is not listed. So it is not an option to assume that manufactures' availability will be checked during add item to shopping cart.

[Rajesh V Roy]

I hope you all have passed the exam at writing of this post. My take from this post are

1) Focus only on given business requirements. Negative scenarios and alternate flows will always be there and they are business domain concerns. You can safely make a favorable assumptions and provide extensible/adaptable solutions but avoid modifying or calling a use cases as a wrong as much possible as you can.

2) I am considering the "Separation of Concerns" principle here. Dealing with inventory tracking is a back office operations concerns. The clue is that Company has already made a sizable investment there to expand the capacity or inventory. That means possibility of inventory shortage is rare and company is already tracking the inventory system for this type of scenarios.

[Jeanne Boyarsky]

R Roy wrote:You can safely make a favorable assumptions

Yes. I made a bunch of simplifying assumptions in mine. And documented them so it was obvious what I assumed.

[Paul Balm]

The clue is that Company has already made a sizable investment there to expand the capacity or inventory. That means possibility of inventory shortage is rare and company is already tracking the inventory system for this type of scenarios.

I don't see that. It could be that they've made the investment to minimize their stock, optimize their supply chain management, which reduces costs but increases the chances of a product not being in stock -- especially for large orders. Another question that comes to mind, how is your architecture affected if this case is rare? Either you support it, or you don't. Are you saying you don't support the case where a product is not in stock, but your architecture is easily modified to support it?