Omnichannel B2B Architecture

1
Omnichannel
B2B Architecture
Piotr Karwatka, CTO / pkarwatka@divante.co

INTRODUCTION
Research shows¹ that consumers expect from B2B sales systems functionality and
experience (User Experience) familiar to them from their everyday dealings with
e-stores. Delivery within 24h, up-to-date inventory, individual prices and promo-
tions and fast user interface are just some of the challenges.
With the scale of activity that occurs in B2B commerce fulfilling these expectations
is not easy. It requires automation and integration of multiple business systems -
previously acting independently. To provide the customer with updated pricing
and availability of the products we need to efficiently exchange information be-
tween storage, ERP /financial accounting and CRM systems.
The challenges are followed by new possibilities. Businesses that begin selling
through the online channel often focus on testing the business model - ignoring
integration with other ways to reach customers.
With Magento 2.2 on horizon implementing Online B2B Store becomes faster and
easier than ever. With many pre-implemented and ready to use features Magento
becomes default platform of choice for many medium and large scale distributors
and producers.
The online store is then an independent island - entire customer service takes place
in the administration panel. It’s a great simplification as compared to the real world
- where customers call, visit branches or use mobile devices. The implemented B2B
system it is usually another channel to reach customers. Planning ahead launch-
ing a CRM system integrated with the platform we can provide all the information
about purchase history and contractor preferences for each touchpoint through
which customers contact our company. In this way, the implemented Omnichannel
solution can become a significant competitive advantage.
¹ Read our report concerning. B2B implementations: divante.co/knowledge

Since choosing software solutions is associated with high costs and is time-con-
suming - it is crucial to establish such IT architecture that could be developed
through evolution, not revolution.
Some of the information in this e-book comes from the book I wrote “Technology in
e-Commerce. Manager’s Handbook” published by Helion.

5
Or maybe Magento? 29
PIM – PIMcore
How to choose the software? 31
31

6
B2B functions overview
What kind of features do successful B2B systems have? In my experience, the best
systems can become a tool for our business partners, not just a marketing platform
presenting a product catalog. Such systems are truly addictive. It’s hard to jump
ships if our platform employees create offers, customize carts and provide their
customers with discounts. The added value is very high.
This eBook presents only few of Magento 2.2 B2B features. Please contact us to
schedule a fully-fledged online demo to show all capabilities.
Individual prices for customers
The basic requirement towards a new sales channel is of course to map the existing
offer. A B2B store should allow taking into account all aspects of the pricing policy
- pricing tiers, individual pricing, quantity discounts. Having a large number of prod-
uct indices and contractors you must definitely pay attention to the performance
of a given solution. Good B2B systems allow interactive customer tendering – by
combining a CRM system with a quotation system, vendors may individualize their
offer on an ongoing basis. Prices are collected in real time and updated in the store
- and by calling the call center customers may negotiate special terms.

7
Figure 1 Magento 2.2 provides you with feature called Catalogs and Shared catalogs. One’s can provide
individual pricings for specified companies and users
Good B2B systems allow interactive customer tendering – by combining a CRM
system with a quotation system, vendors may individualize their offer on an ongo-
ing basis. Prices are collected in real time and updated in the store - and by calling
the call center customers may negotiate special terms.
Credit limit
Trade credit allows placing orders with deferred payment date. It should be syn-
chronized with the terms of trade recorded in the ERP or CRM system. In an online
store it’s usually used as a special form of payment (chosen during the purchase
process) – with limited date of visibility and quota limit to which it applies.

8
Figure 2 Credit limit is now a default feature of Magento 2.2. Credits can be used acress Companies ac-
cording to user priviledges
Multi cart
If our system is to become a tool that will get our contractors addicted to it - multi
cart is certainly one of the most important functions. Its simplest use lies in creating
different orders for different contractors or creating “open orders”. Our implemen-
tation shows that this is one of the most frequently used functions in B2B.

9
Figure 3 Magento 2.2 uses “Multiple requisitions lists” approach to provide users with Multi carts. Requisi-
tion lists are stores in User’s or Company’s account
Our implementation shows that this is one of the most frequently used functions
in B2B.
Figure 4 Tools associated with shopping carts allow you not only to share and combine orders, but also
prepare offers for the end customer . Example from our project for TIM.pl

10
Quoting end customers
Sharing carts is inseparably connected with generating quotes for the end custom-
er. This simple tool - depending on the model – allows for adding margin to the
base price, or discount prices depending on the negotiated terms. The prepared
offer can be downloaded in PDF format with individual logo or stationery, or even
sent (within the platform) to the end customer with a request for approval. In the
second case there is full automation - after accepting the offer products are added
to the cart and the customer realizes the order.
Figure 5 Quotes are one of the most powerfull features of Magento 2.2 with discounting systesm, accept-
ing workflow and permissions based system.

11
Discuss your offer via chat
Integrating a solution such as LiveChat with our website can help increase conver-
sion. If a customer thinks about a particular product for a long time, an operator
can “chat them up” to clarify any doubts. If we combine live-chat with quoting fea-
ture, the customer can negotiate and accept offers on-line.
Figure 6 Quoting and negotiating terms online accelerates purchasing decisions and increases conversion.

12
Quick cart and accumulated orders
Some B2B customers don’t want to negotiate (because they already have right
individual terms!) - they want to quickly make a repetitive purchase. Making the
quick order option possible, where you just have to provide product indices, al-
lows avoiding frustration and saving a lot of time. Importing cart from a file (e.g.
CSV), created manually in Excel or generated by another system, may be equally
helpful.
Figure 7 Quick orders are often already available from customer cockpit - along with other useful functions
(like tips, news, etc., as seen above).

13
This function is often used together with the option to accumulate orders. Accu-
mulating orders allows for operating on many open baskets (e.g. order-for-order
option for a given contractor or branch). The carts are automatically sent at a time
set in the panel (usually at the end of the day). Of course, all short-term promotions
and terms of offers changing during the day are taken into consideration.
Hierarchical accounts
If our contractors to larger companies, they usually have a lot of branches and
departments and the purchasing decisions often have to be accepted by a couple
of people. Of course, you can skip this “detail” when designing a platform. It sim-
plifies a lot, but unfortunately it also has adverse repercussions on the adaptation
stage of our system. The solution will be uncomfortable, as it is inconsistent with
business reality.
In the optimal solution, our customers can define any number of branches and
accounts (along with authorization), giving their employees the ability to place and
accept orders.
Figure 9 Full self-service. Customers can add sub-accounts and accept orders. In Magento 2.2 you can
draw-out Company hierarchy.

14
Solution architecture
Cooperation of IT systems operating within an integrated platform (a collection of
system relying and dependent on each other) requires an appropriate distribution
of tasks. Controlling processes in a company is usually done by dividing IT solu-
tions into classes in accordance with the role they have to play.
System classes that can be distinguished are (in a slightly simplified version):
• ERP (Enterprise Resource Planning) systems are used to assist company man-
agement by aggregating (gathering from various sources and centralizing)
data and automating decision making. ERP systems are inherently modular
software, that is, they consist of independent applications that work together.
• SCM (Supply Chain Management) software is used to manage network sup-
ply chain. It supports synchronization of material flows between companies
cooperating with each other. Such approach helps the company to adapt to
market demand, as SCM systems can integrate the company with its suppli-
ers and customers (e.g. by sending automatic orders for inaccessible goods
to suppliers upon the occurrence of such orders from customers).
• MDM (Master Data Management) is computer software designed to provide
high-quality news and the most important reference data used in various
business processes and by various organizational units. The software central-
izes information and is a reference point for distributed systems.
• WMS (Warehouse Management System) is an inventory management system
that helps to coordinate the work of logistics warehouses. These are highly
specialized systems that improve the processes that occur in warehouses,
e.g. accepting deliveries, sending goods, optimizing the arrangement of
SKUs and inventory management.
• CRM (Customer Relationship Management) solutions support the company
in managing customer relationship. CRM systems facilitate creating customer
classification and support employees who have direct contact with custom-
ers (e.g. Call Center or sales representatives).
• BI (Business Intelligence) is a very broad concept in IT. Business intelligence
is mainly based on the construction of a data warehouse containing stand-

15
ardized historical data from various systems used for generating reports and
analyses.
Communication between systems requires solving some basic problems such as:
• ensuring a sufficient level of reliability. Systems must operate in a continuous
mode and the communication between them should take place without any
interruptions;
• keeping strict limits for delays in data exchange. If we want communication
not to become a bottleneck in making business decisions, it has to take
place in a strictly defined timeframe;
• the need to use different methods of data exchange (e.g. WebService/SOAP,
text files, FTP, etc.). Systems have different capabilities, which you have to
adjust to;
• presenting data in a uniform manner that is understandable to all systems
involved in the process.
Transferring data from one platform to the other is quite easy to imagine - theoret-
ically. There are often considerable practical problems due to the different tech-
nologies used in applications. Incompatible and closed technologies (i.e. tech-
nologies not based on open standards) often hinder the implementation of the
common communication interfaces.
In the case of e-commerce, data exchange interfaces typically include a number of
documents, such as:
• orders — information on a customer placing an order in the online store is
usually transferred to the sales system (including accounting) and later to the
warehouse system;
• customers — customer data should be synchronized and consistent across all
systems that participate in the sales process. Most often the data is trans-
ferred together with customer order data or in the process of registering to
the store;

16
• inventory — it should be updated in all sales systems, including online ap-
plications. The data should be collected directly from the warehouse system,
which is the overriding source of current information on the subject;
• product catalog — information on the range offered by the company should
be taken from the system which contains data on what products are available
for sale and at what prices;
• descriptions — presentation of the offer requires consistent and current
information on the offered product. Photos, attributes and descriptive data
are very important elements of product presentation. Various systems may
require different information (e.g. translation). Data, however, should be
centralized in the product information system (PIM) and distributed to all the
other systems from there, including the online store;
• complaints —a complaint filed in the online system should go directly to
the order management system and then, depending on the result of the
complaint it will be forwarded to the appropriate systems (e.g. in the case of
a sales adjustment to accounting and storage systems);
• trade documents— in the case of partner sales, the data of customers who
signed a partnership agreement should be collected in the appropriate
system and available for others. It includes documents such as, e.g. KRS and
REGON numbers, as well as specific trade terms (e.g. discounts);
• trade credit — selling online is not only connected with a product offer for
retail customers. An offer for B2B customers is often defined on the basis
of deferred sales. Such information is stored in domain-specific systems for
sales management and in CRM systems.
Manual copying (rewriting) of data is really time-consuming and very prone to er-
ror, even in the case of small quantity sales. When sales grow, this is the phase of
information exchange that is the least scalable. Therefore, it’s important to think
about automated integration from the very beginning.
The first thing you should do is to accurately determine the scope of the transmit-
ted data. The scope should contain general descriptions of objects that will be
sent and received, as well as the detailed data included in the defined objects. The
result of preparing such a compilation should be documentation of data exchange
protocol.

17
Before you define the protocol, decide on the format of information exchange.
Readymade and recommendable formats that can be used include:
• OAGIS (Open Application Group Integration Specification) — a non-profit
organization, which aims to create a standardized description of the objects
that can occur in business processes. The standardized XML messages for-
mat can be used for most of the solutions in systems integration.
• EDI (Electronic Data Interchange) — it’s also one of the formatting standards
for messages that can be transferred between IT systems. The purpose of
EDI is to eliminate reentering data and increase the accuracy of the informa-
tion flow.
In addition to the simple exchange of information in Point-to-point model (data
exchanged between two systems), there are very flexible buses for exchanging
information in the enterprise called Enterprise Service Bus.
ESB is intended to link messaging in the form of, for example, a standardized XML.
Data flows through ESB and systems that need information spot out messages ad-
dressed to them from the communication flow. Enterprise service bus standardizes
messages and allows for dynamically connecting new systems. Systems don’t need
to know about each other, as they constitute independent nodes providing service
trays.
For example, a warehouse system sends an update within the bus after a change
in a commodity index. An online store can download this information and update
product availability. When we add a wholesale B2B (business to business) system
to our environment, there are no modifications needed in the warehouse system.
When connected to the bus, the new system will also collect the required informa-
tion.
Individual applications work with each other through messages that enter and

18
leave service trays. With this solution, applications don’t need to know anything
about communication protocols, they know just where to send and where to re-
ceive data from. This allows you to easily expand, move and swap services without
interrupting and modifying the cooperating systems.
In communication via ESB, XML is the most widely used language, as it provides
high flexibility in creating messages. It makes software more resistant to applica-
tion and business process changes. Using XML, ESB can automatically transform
the contents of a message from one format to another.
Online store
ERP
B2B system
WMS CRM
Figure 10 Exchanging information without ESB in P2P (point to point) model can be intimidating!

19
How does ESB communication work?
All services are described in a common repository (catalog). ESB uses routing (i.e.
determines the shortest routes) of a message currently stored in XML files, speci-
fying the required sequence of services through which the message must pass in
order to complete all the required information. Message routing can be changed.
Sample use of ESB in completing an order from an online store:
• The customer’s order arrives to the system through the online store.
• The order is sent to the accounting system where information on the cus-
tomer’s solvency is checked. If the check is positive, the system generates an
invoice.
• The order is then transferred to the CRM system by the application adapter.
• The order is sent to the warehouse system through file drop adapter.
• The warehouse system sends the order for execution.
• The order is sent to the partner cooperating in its execution (e.g. a courier
company gets information about shipment ready to be received).

20
Responsibility shared among the systems
B2B systems are rarely implemented “in a vacuum”. Thus, responsibility shared
among the systems is often already determined. Each system is historically respon-
sible for different activities.
At times, in the course of company development there are systems added – actu-
ally, they are usually glued in - in such a way that the responsibility is duplicated or
unclear. The theory of computer science says that each system strives to increase
its level of entropy (chaos) - and it actually happens.
We should therefore ask ourselves a question: what is the ideal state?
Online store 1
Accounting system
Online store 2
Warehouse system
ESB
Other systems
CRM system
Figure 11 Integration through ESB is primarily based on simplification of the amount of integration and
openness to new systems. The number of connections is lowered from N*N to 2*N (where N is the number
of systems)

21
CRM system
In the Omnichannel solution, the customer is in the center of attention. Information
about what did the person/company buy and what are their trade terms should be
available in a central repository. A CRM system usually becomes such a repository.
It is available for call-center operators, for an online store through integration, as
well as for consultants in retail outlets.
This very important assumption allows for creating completely new customer ex-
perience. You can place online orders through offline channels if you have gaps in
stock, or vice versa - you can order products online that will be received off-line. A
call center operator sees what you ordered and can provide you with information
about the order status or accept a return.
CRM implementation can usually be divided into:
• Analytical CRM – it collects information from different channels and about
different events related to the customer; provides 360 degree view of the
customer. Such CRM system is also equipped with sales recommendations
or history of contacts with a given customer. However, you can’t perform
operations. The data is available for inspection and the implementation is
relatively simple;
• Operational CRM– in addition to viewing complete information, you can
make most of the customer-associated key activities, e.g. place orders and
deal with complaints. It’s a great tool for call center operators.
A sales CRM system should combine operational and analytical functions. CRM
should enable:
• managing orders (handling order status, comments, workflow, placing or-
ders) - OOMS (Omnichannel Order Management System)

22
• managing prices and customer trade terms (offer consistency across all sales
channels), because some systems sales (Magento, hybris) allow very flexible
formulation of promotions and price list rules - often this responsibility is
shared with the system of online sales.
• managing mailing and customer communication - including compliance
with the Inspector General for the Protection of Personal Data and accepted
regulations,
• managing complaints and documents related to the customer (e.g. verifica-
tion documents for trade credit, company registration documents, signed
contracts)
• generating recommendations and support for processing of all customer-re-
lated events (big data).
Figure 12 CRM system architecture - not only collecting information (analytical system) but also performing
operations - including handling orders.

23
eCommerce system
Frontend available to customers should primarily be flexible, run on mobile devic-
es and work fast. eCommerce is a reflection of all the information collected from
company systems. Inevitably, there are some sales related functions - such as quot-
ing, handling trade credit and trade documents (see inspiration described at the
beginning of this guide).
Choosing eCommerce system one should pay attention to the systems that have
ready-made integrations - especially ERP and CRM (the largest scope of informa-
tion exchange) - for example Magento or OroCommerce (orocommerce.com/
features/).
ERP system
Although by definition ERP is an integrated business management system - full im-
plementation of all its modules is rare. Typically, an ERP system is used to handling
sales - fiscalization, invoicing and bookkeeping service.
In B2B deployments I’ve participated in, this was exactly the role of an ERP sys-
tem. It accepted sales orders from a B2B system, along with calculated sales prices
and discounts taken into account - then it generated invoices, bills of lading, ware-
house documents and sent them to the store.
People handling an ERP system are often separate from those responsible for man-
aging an e-store. ERP is present a company from the beginning, has been used
for processing orders (other than online orders) and therefore integration of the
system is crucial.
Sometimes an order, after placing it in the online store, is processed entirely in
the ERP and the store (and the customer) only receives changing the order status.
This eliminates the need to change the existing way of processing orders/training
people who carry out shipping.

24
If you’ve implemented/are planning to implement a CRM system, consider price
management. Operational CRM and sales platforms usually provide ample oppor-
tunities for editing prices and giving discounts/promotions. If an ERP system has in-
dependent price calculation modules, in extreme it cases can lead to severe price
discrepancies. Such situations must be avoided.
ERP should also have information about customers’ payment conditions - trade
limits in particular.
WMS system
Real-time inventory is a core function that enables fast delivery and provides infor-
mation about the on-line availability of products. Currently, it’s a necessary require-
ment. If a WMS system doesn’t enable such a rapid exchange of information (e.g.
the number of SKUs (stock keeping units) is too large), there are several solutions.
The most commonly used is the separation of warehouse stock for the online store
(so that it’s impossible to ‘snatch’ products and thus order those already unavail-
able).
Solutions that allow ordering on-line and offline reception constitute a new dimen-
sion of requirements. Everything is relatively easy if you process this scenario in the
central warehouse model (orders are processed from the central warehouse and
supplied to the reception point/retail store).
However, the biggest benefits come from using the ‘Order from store stock’ solu-
tion - ordering from stores located near the collection points. Inventory manage-
ment in such case is difficult as there are numerous situations that because of
synchronization delays a person in a retail store is able to buy the last piece of a
product which is ordered online at the same time.
The simplest solution to this problem is to book specific quantities only for e-Com-
merce and replenishing lows in remote warehouses.

25
PIM system
Product description is a key issue when it comes to conversion in an online store.
Customers can’t see the product, enquiring about details is often burdensome, so
the only things they can rely on when making a purchasing decision are descrip-
tion and photos.
Good quality descriptions have a number of advantages - not only they increase
conversion, but also increase visibility in search engines.
Companies often have meager product descriptions (e.g. attributes only) in ERP
systems. In practice, such descriptions are not sufficient for online sales.
Dedicated PIM (Product Information Management) or MDM (Master Data Manage-
ment) systems are used only for product data management.
Why invest in such a system, if descriptions can also be placed in an online store?
PIM systems have far more advanced features such as:
• importing and enhancing product descriptions (ETL – Extract Transform
Load),
• workflow management + accepting products – they need to have complete
attributes, images, prices and specifications before they can appear in the
store; additionally, it’s possible to version such descriptions
• categorization - various category trees, compliance with ETIM and other
standards is also a great help in inventory management,
• language versions and various media - PIM systems allow creating different
descriptions in different channels (mobile, internet, printed catalog) and
managing product sheets in these channels

26
CRM + eCommerce = Oro Platform
Oro Platform (orocrm.com, orocommerce.com/features ) is more than just a CRM.
It’s a platform for creating business applications based on an open license (MIT).
Built in Symfony2 framework, it provides a modern technological base for the de-
velopment of dedicated solutions.
Figure 13 OroCrm is more than just basic CRM functions such as calendar, leads, workflow and client ac-
counts. A very important feature is strong integration with sales systems. OroCRM is a system dedicated
to online sales

27
Below are 6 reasons why you should consider Oro:
• Oro uses Symfony2 framework - a modern solution in accordance with de-
sign patterns, a current industry standard for web applications based on PHP;
• Oro was designed by Yoav Kutner - a former CTO and co-founder of Magen-
to;
• Application architecture is based on proven design patterns – e.g. two step
view, EAV, IoC;
• Modular framework - all modules are independent of each other so that the
application can be safely expanded;
• Scalable architecture - it supports different database engines including
NoSQL databases,
• Oro is based on proven technologies (PHP, Symfony2, MySQL/PostgreSQL) -
we are not bound by vendor lock-up, we can move the development of the
application inside the application at any time (unless we used other technol-
ogy providers).
Oro platform, designed and developed by the creators of Magento, is a fully mod-
ular solution, created for scalability.
Oro platform is particularly interesting in B2B solutions due to two productively
mature applications:
»» CRM - which provides all operational functions related to customer service,
including full integration with Magento sales platform,
»» Commerce - B2B sales system directly integrated with CRM.
Similarly to Magento, OroCRM can be expanded with modules created by inde-
pendent developers - available in Oro Marketplace. The amount of these modules
continues to grow –there are already available integrations (e.g. MailChimp, Ma-
gento, popular ERP systems), elements of the marketing automation and others.

28
New functions can be easily added within subsequent modules (without modifying
the existing code, which is important because of the ability to perform updates).
Paid support is also available (Enterprise version).
Within OroCommerce module, we have all the features necessary to handle B2B
sales at our disposal:
»» individual price lists,
»» processing orders,
»» processing individual leads and quoting
»» a 360 degree view of the customer - including integration with user tracking
on the website and in the e-mail correspondence.
Figure 14 Fully managed workflow of processing orders, leads and contacting customers

29
B2B sales functions available in OroCommerce:
»» full processing orders - including splitting and combining orders,
»» support for multiple price lists for customers,
»» quoting, accepting, editing orders on the platform,
»» full integration with PIM systems (including PIMCore and Akeneo),
»» quick order form,
»» reports, editable dashboard for customers,
»» payment methods - including trade limit,
»» multiple sites management (multisite) from a single administrative panel -
including handling multiple companies,
»» a mechanism for customer segmentation,
»» a mechanism for authentication and authorization management.
OroCommerce connected with OroCRM allow a very quick way to build a mul-
ti-channel sales system. What is important, no work on systems integration is re-
quired, as they are integrated from the start.
Or maybe Magento?
Of course. If not OroCommerce, consider implementing Magento to serve the
same purpose. Especially that recently (November 2015) a stable version of Ma-
gento 2 was released. The new version includes:
»» better speed (full cache support also in the Community free version),
»» better code structure (organized, simplified XML, using new possibilities of
PHP, such as namespaces)
»» completely new administrative panel and a default template that supports
RWD.
The advantage of using OroCommerce compared to Magento is that you don’t
need to perform additional integration and the fact that the functions of boxed

30
OroCommerce already cover most B2B applications. It should be also noted that
many of the B2B modules for Magento are available as external plug-ins or mod-
ules created by implementation companies (including all the features described in
this guide, created by Divante).
Magento is now the market standard in eCommerce, confirmed by stability of op-
eration as well as flexibility.
The final selection should be made after – at least short - preimplementation analy-
sis and comparing the effort/cost of implementation on both platforms.
PIM – PIMcore
PimCore is a modern framework for building multi-channel content distribution
systems - available under a free license (open source). It is based on Zend Frame-
work, PHP and MySQL technologies - providing easy possibilities for expansion
and competences to acquisition from the market.
Figure 15 Sample category tree in PIMCore.

31
PIMCore most important functions in the context of B2B include:
»» support for multiple languages and translations,
»» support for multiple formats and media - products may be described dif-
ferently for mobile devices (e.g. shorter descriptions and smaller images),
differently for printed catalogs, etc.,
»» support for printing/DTP,
»» managing multiple category trees - including compliance with the ETIM
classification,
»» ready-made integrations - Magento, Microsoft AX, exchange data through
API REST and XML/CSV formats,
»» product database of any structure (attributes and relationships, dynamic
widgets in product descriptions)
»» workflow for completing descriptions, authorization management system
PIMcore support interface can be freely modified in the course of deployment - it’s
important from the ergonomics point of view. Entering product descriptions is cru-
cial in terms of speed of upgrading offers and even Time To Market (time needed
to launch a new sales channel). PIM implementation should start with analysis and
interviews with Category Managers (those responsible for the store inventory) and
consider implementing functionalities aimed at accelerating their work. Every min-
ute saved in editing the product is time saved on publishing the offer.
How to choose the software?
Choosing a store platform is one of the decisions that are later difficult to withdraw
from. Implementing a new technology is usually long and expensive, especially
when it’s associated with adapting it to specific business needs. A subsequent
change may be even more expensive.

32
For medium and large enterprises the possibility of developing and maintaining
software should be the key for selection. Readymade platforms in which only the
appearance is changed are very effective for starting businesses. As a company
grows, there are new requirements that need more and more extensive modifica-
tions.
Common problems with software development reported by IT departments in-
clude:
• License that doesn’t allow changes. Too high costs of developer license (i.e.
extending the license by the possibility of developing the software inde-
pendently). A restrictive license kills the possibility of any changes without
binding to the producer.
• Confusing code – introducing changes is very time consuming and develop-
ers are almost afraid to modify anything.
• Lack of documentation - changes need to be made by trial and error, which
can lead to a measurable loss in sales.
• Lack of producer support, which leaves developers to their own devices
whenever an error occurs.
The cases of transferring and rewriting software from the scratch, even in large
stores, are not so rare. Drastic changes can be avoided by conducting the appro-
priate pre-implementation analysis.
It’s a bit like a marriage - you have to get to know each other first. If it doesn’t hap-
pen, the subsequent revolutions will be paid for with heavy losses.
First and foremost - license
Software is available in a variety of licensing models. Practically, the changes are
not possible if it’s available in a subscription model (SaaS - Software as a Service).

33
If the software runs on your servers, you must carefully study its license. If you’re
dealing with free license (open-source) such as OSL, GPL, BSD, LGPL, you’re free
to modify it.
Open source software encourages the use of plugins. However, it’s necessary to
see if it can be modified and what it will involve, as plugins are often issued under
a different license than the basic software.
Open source licensed software differs in details, including models of distributing
the introduced changes. It’s crucial, as when you create unique software solutions,
often constituting a competitive advantage, you don’t want to share the source
code with others.
In the case of commercial software, the situation is more complicated. Be sure to
find out whether the producer intends to make changes on their own. Do you get
access to the source code? Most often the possibility of changes is guaranteed
only after buying a special developer license, which can cost a lot.
As part of the implementation agreement, you should ensure the transfer of cop-
yright to all modifications and derivative works performed within the software. For
example, without having the right to modify the store graphics files, introducing
changes can be just as difficult as in the case of lacking access to the source code.
Implementation portfolio
A good indicator of whether the selected platform is easy to develop and maintain
is to check its implementation portfolio. It’s also worth checking whether current
users introduce modifications. You should ask them (for example, on an online fo-
rum), how was the process of introducing changes and were there any difficulties.
The sheer number of customers often indicates whether the software is able to
defend itself.
Implementation portfolio and the number of users are particularly important in

34
the case of open source software. By the number of new stores and users you can
assess whether the software is still actively developed.
Producer support
Even if you are using an open source platform, you can often buy a paid producer
support. The mere fact of providing such a service by the authors demonstrates
professionalism. In critical situations, the ability to use support service can help you
fix errors faster.
In the case of closed source platforms, support is very important. Whenever prob-
lems occur, we can’t ask the community (for instance, through online forums) to
help us.
Stability of the producer is also important. For small businesses, there is a risk that
they may discontinue the platform development or their activities in general.
Documentation
Documentation is the primary means of help for developers during application de-
velopment. Technical documentation describing source code architecture, adding
modules and performing basic programming activities is a must.
Creating documentation is a tedious and time consuming process. In open source
projects it is often assumed that the source code documents itself and documenta-
tion is ignored by the authors. This approach is justified to some extent, as because
of it we don’t have to deal with descriptions that are out of date or misleading.
Is hard to do without documentation with large-scale systems. Employing and in-
ducing a new developer itself will take a disproportional amount of time, which
they will devote to learning the software by trial and error.

35
In the case of dedicated software, make sure to check what documentation is in-
cluded under developer license before signing the agreement.
Architecture
Technical aspects considered, software architecture is crucial.
Before choosing a particular platform, developers should analyze the source code.
Even if it’s closed, it reflects well on the producer if they’re not afraid to show parts
of their code.
Software should necessarily allow for creating plugins and operate in an event-driv-
en model. Such architecture enables adding and editing functions without modify-
ing the base code. It’s hard to imagine a platform without the use of template mech-
anism, which allows for modifying the software appearance without modifying the
code. This is the layer in which changes occur most commonly (at least initially).
It’s worth paying attention if the source code is written using design patterns. They
increase flexibility, but their primary function is to facilitate communication between
developers. Using a pattern is a substantial shortcut on the way to understand how
the code works.
Application should be divided into layers. The minimum division is represented
by the acronym MVC (Model-View-Controller), popularly known as a pattern. The
layers are separated from each other in such a way that changing one of them does
not entail any changes to the other. Thanks to this division introducing changes to,
for example, way of communication with the database, theoretically won’t affect
the operation of the code responsible for forms logic.
The source code should be documented in its basic scope (class designation, the
purpose of methods, necessary types and the meaning of method arguments, es-
pecially in the case of scripting languages without strict typification). In addition,
notice if the code is written on the basis of uniform coding standards, if the varia-

36
bles are named according to the same scheme, if there are pieces of code in an-
other language (e.g. Polish and English names). These factors may seem trivial, but
without order in the code the application will start to increase its entropy (chaos)
much faster, thereby reducing the possibility of extension.
If you want to create other language versions of the software, be sure to note if
the source code was written using tools like gettext or other industry internation-
alization standards. The case also concerns supporting different cultures (currency,
formatting numbers, months and date).
As for the aspects on the verge of functionality and the source code, make sure to
check if the application has WebAPI (e.g. SOAP) or any API at all. API is short for
Application Programming Interface that can be accessed by including libraries to
the application code or online (WebAPI) as Web services.
Through the provision of more complex algorithms via API, developers gain the
ability to automate tasks without making any changes to the base code of the sys-
tem. Import/ export of data via API will also enable easier system integration in the
future.
As part of the changes you will definitely see a lot of modifications of database op-
erations. You should make sure that the database structure is consistent with mar-
ket standards, if it’s normalized and uses commonly known design patterns. Also,
check if the database supports the EAV (Entity-Attribute-Value) model for adding
fields and attributes for all data models. Finally, make sure that there’s a uniform
nomenclature used and that the authors thought about the appropriate use of in-
dexes and search engines.
Automated tests
Introducing changes to the code you didn’t write is associated with considerable
stress. When you add sparse documentation and lack of producer support, the
stress is even greater.

37
If the software you’re going to use has automated unit tests, it’s a huge advantage.
In this case, even if the source code requires refactoring (a change in the structure
without changing the mode of operation), the tests will immediately detect any
errors in the operation of the modified application.
In the case of larger systems, full coverage of unit tests is rare. Open source soft-
ware (such as Prestashop or Magento) has automated tests covering a very small
range of modules. For this reason, automated testing can’t be a key factor in soft-
ware selection, but you should appreciate its existence, as it confirms the reliability
of its creators.
The history of previous changes
When we take over platform development from another company, it’s crucial to
transfer all the information about the changes that occurred during development.
If a version control system and a ticket system (e.g. Redmine) were used, the matter
is simple. Probably these two systems together provide key information about the
changes that have been introduced into the system.
However, if the previous creator didn’t use good practices of software develop-
ment, the transfer can be difficult. It’s like not marking changes in the course of
electric cables in the walls during construction work. You can drill, but there is al-
ways a risk.
You may find that many of the algorithms work differently than described in the
original documentation. In such case it is necessary to ask for updating the project
and documentation.

38
Software & eBusiness experts
in the Omnichannel Era
www.divante.co
hi@divante.co
Divante LTD
17 Dmowskiego Street
50-203 Wroclaw, Poland

Omnichannel B2B Architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Omnichannel B2B Architecture

Similar to Omnichannel B2B Architecture (20)

More from Divante

More from Divante (20)

Recently uploaded

Recently uploaded (20)

Omnichannel B2B Architecture