Use Case Diagram For E Co

Architecture diagrams in e-commerce

The Must-have visualizations every E-Commerce Project Platform should contain.

With each significant milestone we all reflect on the things we have done, and the ways in which we could have done them better. This internal process is valid and very logical; as with each experience we grow and learn new things. These lessons teach us where we went wrong, and how we can improve our decision making process going forward. With the information gained from our experiences we can start implementing new procedures and bring ever increasing value to ourselves and our organizations.

It is natural and expected that we will go through these phases of reflection, analysis and adjustment so that we are continually improving.

I experienced this all the time when I was actively coding as a developer and I still have the same experience now that I am a Solution Architect. What I can say at this stage is that it is a natural part of the process of continued growth and evolution.

Let me take a moment to share with you based on my experience, what I believe to be the two mandatory; and one case specific diagrams every good E-commerce project platform should have. Two of them from my perspective as stated before are mandatory, while the third is highly recommended, but only in specific cases.

Each e-commerce project should have:

Enterprise architecture diagram
Data flow architecture diagram/s
Enterprise middleware usage architecture diagram

Trending GoBeyond.ai articles:

1. Best Practices for Managing E-Commerce Customer Service

2. Top 15 Magento 2 Extensions For Your E-Commerce Site

3. How Free Influencers Took My Brand To Global Success

4. The Coming Disruption to E-Commerce Search

What are the differences between them, you might ask, or why can't we just have all the information in one layout?

We could have just one diagram to fulfill the purpose of all 3, but that diagram would be very crowded, hardly maintainable, and not clear enough for ease of understanding. To fit into UI elements, you will have to make tradeoffs and skip architecture elements to keep it clean. Having one diagram to handle one job and one logical view will allow you to ensure readability and maintainability along with other software quality attributes.

We can understand the differences between the diagrams if we examine what each diagram should ideally contain.

E nterprise architecture diagrams should ideally contain all the systems that are part of your e-commerce project highlighting the connections between systems. If you have ESB or API manager do not include either in this diagram. The purpose of this diagram is to show what system connections you will have, for example, that system A will connect to system B and system C. That link should not contain any type of relationship, or multiple connections between the same entities. Connection, in this diagram, refers to a single line between two systems that shows that there will be some data exchange. In this diagram, we also include the name of the third-parties. For example, if your payment system provider (PSP) is Cybersource, you will have an object entity with name PSP and Cybersource to showcase that you have a PSP, and that this PSP is Cybersource. The final point, but of equal significance, is to include in each system entity on the diagram what are the main functionalities, features, or roles they will play in your e-commerce project. For example, PSP CyberSource on this diagram shows that it will handle Payment and Fraud validation.

Enterprise Architecture Diagram: Sample (without legend)

Please note that the above diagram is missing the legend, as this is just an illustration. For the actual diagram a legend is a must-have.

D ata flow architecture diagram/s. The Architect of the system usually creates the corresponding data flow diagrams for the particular project. For example, as Solution Architect of SFCC B2C, you will create a data flow architecture diagram to illustrate how your system will directly connect to third-party systems. Depending on the enterprise architecture, your data flow architecture diagram will contain more details on all the connections your product has. In the enterprise architecture diagram you might have only one line between SFCC B2C and PSP Cybersource. In the data flow diagram, you will show all live and batch connections with details, who is a data receiver and who is a data provider. You may also explicitly add the details about what is the data format and whether there is a middleware between the data connection. If you have data connection orchestration mechanisms, such as API manager or ESB, you might need support from the Architect of that system. This assistance will be necessary, as you will be required to describe in this diagram how the API manager initiates a connection and how the API manager responds after sending data to the target system. Then how that target system replies and how the API manager prepares the response for you. You also might have hybrid architecture when some of the connections originate from API manager and ESB, and some are direct data connections. All of this will showcase the data flow architecture. The most vital piece of information you need to describe in this architecture is what data you send and by what feature. For example, if you send newsletter subscription data to the CRM system via API manager or batch jobs, make sure to highlight this in the diagram and explain why "newsletter subscription" will have web services and batch connections. Annotations are principal support instruments that can allow you to direct end diagram users to annex files or other locations that will describe functionality in more detail.

E nterprise middleware usage architecture diagram is essential first of all for the owners of the end product. Such a layout will highlight all clouds or on-premise third-party systems, what systems use VPN, where systems communicate via an intranet, where you have a public network, and where you have a private one. Such architecture is usually done by the Enterprise Solution Architect, (who is the owner of the end product) with the help of all the stakeholders. The purpose of this architecture is mainly to understand the type of systems and their connection clearly, so the design of the relationships, schedule, and systems responsibilities will follow software quality attributes. For example, if you have a system database under a private network hosted in central Europe, be prepared for latency and connection issues from the APAC region. Such information will help you to design your solution more efficiently with a clear view of architecture.

Enterprise middleware usage architecture diagram: Sample (without legend)

Enterprise, Data flow, Enterprise middleware usage architecture diagrams do not limit the amount of possible visualizations you can have on your project. You can have an end-to-end flow diagram for any customer scenario, or your system design diagram, where you show layering and how your SFCC B2C cartridges will leverage each other, override or extend. How you will manage CI/CD is also a possible visualization and much more.

Looking back on projects I have worked on in the past, not all of them had the layout I described in this article. I wish they did, because of the negative effects experienced caused by the lack of this information. This however is all in the past, and now the target is to take the lessons I have learned through experience and share them with others to prevent them making the same mistakes. If you are reading this and have a different perspective, please let me know in a response. I would be glad to improve the quality and adjust the content to make sure it is relevant and valuable to everyone.

My name is Oleg Sapishchuk, and I'm a Senior Solution Architect at OSF Global Services. I write about Salesforce B2C Commerce, and if you are interested in new or previously written material, I invite you to follow my Medium profile.