4 ms·

The complication arises when interfacing the e-commerce with existing infrastructure management systems. If someone buys item X from the online store and says t

The complication arises when interfacing the e-commerce with existing infrastructure management systems. If someone buys item X from the online store and says they want to pick it up at Store A, the commerce site needs to do several things: 1) Check if the item is in stock at Store A, if so, send a message to take it off the shelf to the store -- access to system wide inventory management. 2) If it's not in store A, find the nearest warehouse and route item X to store A. Give the user an estimate shipping time + Alert Store A the incoming item is reserved for the user. 3) Update global inventory lists and decrement one item X from stocks. 4) Update sales/accounting to let them know of the sale. etc. The problem isn't in the ecommerce site so much as everything else it has to interface with and do. It has to interface with systems up and down the whole chain, and depending on how up to date and accessible those systems are, it could get real interesting trying to merge them together.

kawera 15y ago
And it can go even further: now customer wants to return item X and get a refund! Where does he send it? Has it arrived? What about the money? Wow.
porlw 15y ago
...except the ecommerce system won't do things like stock control or replenishment, it just sends messages to the systems that handle those things - so then how do you know when something is going to be ready at the store? I'm a retail integration consultant (currently looking for my next gig, to any desperate Oracle Retail users out there :-). You either 1) Emulate stock control and routing rules in your app (flaky), 2) Hook the ecommerce app deep into the DBs of the other systems (now almost impossible to change those systems due to the level of coupling and the politics it will involve) 3) Go fully realtime with all systems running on a common bus (seriously heavy infrastructure and support requirements) Ideally you should do 3 but most of the time you end up with some combination of 1 and 2. Then the next "must have" idea comes along, and before you know it your fancy new e-commerce solution has become part of the legacy establishment.
- Roboprog 15y ago
  Is there an option between 2 & 3? My experience, albeit only the last 2 jobs, with the concept of "Enterprise Service Bus" is that it becomes a magnet for "Architecture Astronauts" with little functionality delivered :-( But it sounds a hell of a lot more impressive than "we will wrap simple REST or XML-RPC services, for which clients can easily be implemented in various consumer systems, around needed queries and updates, using the technology most amenable to the data store in question, documenting the interfaces, using proper configuration management policies", though. But maybe that's about what you meant, in a nutshell.

kawera 15y ago

And it can go even further: now customer wants to return item X and get a refund! Where does he send it? Has it arrived? What about the money? Wow.

porlw 15y ago

...except the ecommerce system won't do things like stock control or replenishment, it just sends messages to the systems that handle those things - so then how do you know when something is going to be ready at the store? I'm a retail integration consultant (currently looking for my next gig, to any desperate Oracle Retail users out there :-). You either 1) Emulate stock control and routing rules in your app (flaky), 2) Hook the ecommerce app deep into the DBs of the other systems (now almost impossible to change those systems due to the level of coupling and the politics it will involve) 3) Go fully realtime with all systems running on a common bus (seriously heavy infrastructure and support requirements) Ideally you should do 3 but most of the time you end up with some combination of 1 and 2. Then the next "must have" idea comes along, and before you know it your fancy new e-commerce solution has become part of the legacy establishment.

Roboprog 15y ago
Is there an option between 2 & 3? My experience, albeit only the last 2 jobs, with the concept of "Enterprise Service Bus" is that it becomes a magnet for "Architecture Astronauts" with little functionality delivered :-( But it sounds a hell of a lot more impressive than "we will wrap simple REST or XML-RPC services, for which clients can easily be implemented in various consumer systems, around needed queries and updates, using the technology most amenable to the data store in question, documenting the interfaces, using proper configuration management policies", though. But maybe that's about what you meant, in a nutshell.