Osama Mustafa
pg. 1
Case Study for
Software Architect
Contents
Abstract:.................................................................................................................................................2
Introduction: ..........................................................................................................................................3
Overview: ...........................................................................................................................................3
Why we use application integration:.....................................................................................................3

Osama Mustafa
pg. 2
Implementation of application integration: ..........................................................................................4
APIs and Web Applications:...................................................................................................................4
An API or the System that Supplies it?...............................................................................................5
Useful components in this diagram:..................................................................................................9
Limitation:..............................................................................................................................................9
Technical Limitations: ........................................................................................................................9
Legal Limitations: ...............................................................................................................................9
More solutions can be implemented: -..................................................................................................9
1. Full inclusion.............................................................................................................................10
2. No inclusion..............................................................................................................................10
3. Micro services-based................................................................................................................11
criteria for to determine which design to choose ...............................................................................12
Considerations .....................................................................................................................................12
Abstract:
We have two separate applications that we would like to integrate together. One is a WYSIWYG
application for generating static websites. The other is an admin application for managing an online
shopping site. We would like to be able to use the features of the Website Builder to design pages
in the Web shop. In addition, we would also like to be able to manage product details (name, price,
images, etc.) while updating Web shop pages in the Website Builder.

Osama Mustafa
pg. 3
Introduction:
Overview:
The ecosystem of e-commerce and business applications has evolved: highly specialized vendors
now offer every kind of specialty tool, plug-in feature, and business operations application
imaginable and still new applications are appearing every day. Incongruous operating systems and
distributed applications installed on diverse hardware, with hundreds of different types of
messages being sent and received simultaneously from the web and inside the organization require
businesses to devote special attention to application integration possibilities.
There is hardly a single web development project today that doesn’t involve some kind of 3rd party
vendor integration, be it for adding the latest must-have consumer features, ensuring you have the
appropriate site analytics and marketing metrics or integrating your business process applications
into your website.
As much as we would like to complete all our work in a single application, doing so is nearly
impossible. There are various developers and entrepreneurs creating applications that specialize in
assisting with specific needs and roles within companies. So, rather than relying on a single
application, we inevitably end up relying on many. While this helps us complete multiple tasks,
managing multiple applications and the data they store can be difficult.
Application integration helps maintain, manage, and keep all your applications up to date while
alleviating data duplication and redundancy. By creating an application integration network that
allows applications to communicate with each other, business and work processes can be done
more effectively and efficiently. Enterprise application integration (EAI) is used to describe
application integration at the enterprise level where multiple applications are interconnected.
Whether on the enterprise level or not, application integration can mitigate challenges related to
data silos.
Why we use application integration:
The need for application integration stems from the need to move data between applications. This
includes transferring data from one application to another in a scheduled, ongoing way or moving data
once from a legacy system into something new. Or, in short, application integration is used to make life
easier. With application integration, you can enter data once and connect it to multiple applications
instead of entering the same data as many times as you have applications. When you add new data into
an application that has been integrated with other applications, the data will be automatically
distributed throughout the connected applications. This reduces human error, the need for manual

Osama Mustafa
pg. 4
intervention, and overall ensures consistency across your platforms. By having a comprehensive system
that forms a bridge between heterogeneous applications, you won’t have to be concerned about
whether your applications were originally intended to communicate with each other or not. This gives
you the freedom and flexibility to choose applications of your choice, not just apps that are within a
collection of technologies or from the same vendor.
Implementation of application integration:
The basic of APIs: Application integration is typically done with the use of APIs. An API (application
programming interface) is a package of functions or rules that allow a user to reference and interact
with parts of an application for their own purposes. This allows for control and flexibility for the end user
while allowing the original creators to maintain their application without interference. Within an API are
the protocols that allow for application integration to take place. While APIs these days are most often
referencing web APIs, APIs have long been used to integrate on premise software systems. They have
played a significant role in SOA (service-oriented architecture), which has mainly taken place on
premise. This means application integration was only really able to take place internally. With the web
and the development of cloud applications, application integration is more commonly an external
process. You do not necessarily need to have an application stored on your computer for you to be able
to access the API of an application.
APIs and Web Applications:
APIs for web applications have become very popular and essential for various tasks due to the increase
in mobile applications and cloud-based software. Web APIs are distinct for the following reasons:
• They are exposed over the web using an HTTP or HTTPS protocol
• Public web APIs are available over the internet, typically with supporting documentation
• They are most often built using JSON or XML
While web APIs do share consistencies, most web APIs will be unique in the way that you can use them.
These differences are dependent on how the developers of the application decided to create the
corresponding API. Therefore, the specific information that is needed to fully make use of a specific API
relies heavily on the documentation that is provided.
Here is the work flow diagram of the whole working system.

Osama Mustafa
pg. 5
Figure 0.1 the work flow diagram
As you can see how the user interact with the Application/System and how the Application and
integrated API working combined and give the user a reliable system. And the user can access all the
feature in single Application looks like everything is running on a one place.
Here is a diagram which shows how the Application and API connect and communicate with each other
by using API calls and pre-defined methods.
Figure 0.2 how the Application and API connect
An API or the System that Supplies it?
Whatever symbol we choose, what we've done is to show the *system* rather than the actual API. The
API is a definition of a service provided by the system in question. How should we provide more details
about the API?
There are a number of ways we could do this but my preference is to give details of the API on the
connector (line connecting two elements/boxes). In C4 the guidelines for a container diagram includes

Osama Mustafa
pg. 6
listing protocol information on the connector and an API can be viewed as the layer above the protocol.
For example:
Figure 0.1 listing protocol information
Many API providers supply multiple services/APIs (I'm not referring to different operations within an API
but multiple sets of operations in different APIs, which may even use different underlying protocols.)
• Allow a bulk, batch download of static data (such as details of companies listed on a stock
market) via xml over HTTP.
• Supply real time, low latency updates of market prices via bespoke messages over UDP.
Two of the services use the same protocol (xml over HTTP) but have very different content and use. One
of the APIs is used to constantly supply information after user subscription (market data) and the last
service involves the user supplying all the information with no acknowledgment (although it should
reconcile at EOD).

Osama Mustafa
pg. 7
There are multiple ways of showing this. We could:
• Have a single service element, list the APIs on it and have all components linking to it.
• Show each service/API as a separate box and connect the components that use the individual
service to the relevant box.
• Show a single service element with multiple connections. Each connection is labeled and
represents an API.
• Use a Port and Connector style notation to represent each API from the service provider.
Provide a key for the ports.
• Use a UML style 'cup and ball' notation to define interfaces and their usage.
Some of these questions may come to your mind:
• How are my services currently organized and exposed internally/externally?
• How does the partner want to integrate with my system, e.g., internal networks, protocols, etc.?
• How do I secure, track and manage the integration of my exposed services?
The following integration diagram below illustrates (at a high level) the existing communication
protocols between the components. You’ll also see how some of the services are being exposed to third-
party developers via the External API Gateway at the logic layer.

Osama Mustafa
pg. 8
Figure 0.2 existing communication protocols between the components
From the diagram above, you’ll realize that the system was designed to be API-driven, which makes it
easy for integration. Almost all the services are exposed via web services, including the data storage
components.
The next step is to check with the partner on the list of services that they require, mode of integration,
e.g. internal or external, and cross-reference the requirements with the services exposed via the API
catalogue. There are also follow-up action items, i.e. working with the system engineers to decide on the
security and monitoring of exposed services.
Sometimes, there may be requirement gaps such as partner wants to integrate externally, but your
services are only exposed internally, or certain data attributes are missing. In such cases, efforts would
have to be factored in to cater to the requirements. The integration diagram has to highlight details, i.e.
internal services/APIs, link to API catalogue, etc. to identify such gaps quickly.

Osama Mustafa
pg. 9
Useful components in this diagram:
Grouped components into layers and bounded contexts — an indication of internal/external API
gateways and services
Annotations with additional information — reference links to API catalogues where detailed service data
attributes can be obtained to assess gaps
Application details and context — services are named appropriately to allow quick assessment of
requirements v.s. actual.
Limitation:
Technical Limitations:
Many API providers have technical limitations in place. I list a few here:
• Rate Limits: Many API providers have limits on the number of queries you can execute per day.
You would need to make sure your application doesn’t need to exceed that limit, and find
workarounds for that.
• Request/Response Formats: Many API providers require you to create your requests and receive
your responses in a specific format. Make sure that your application can support such requests
without a major overhaul. This is especially true when integrating APIs with existing systems.
• Request Restrictions: Some API providers only allow you to execute requests from specific
domains/IPs. Your integration plan needs to address those issues if they exist.
Legal Limitations:
In addition to the technical limitations mentioned above, some API providers have legal
limitations in place in order to make sure that data retrieved via the API is properly used. For
example, LinkedIn allows you to fetch a user’s connection information, but it doesn’t allow you
to share that data with third parties. Although this is technically possible, it’s legally impossible
to do so, and implementing such a solution will only cause your API access to be cut.
Knowing those legal limitations in advance will help you properly plan your integration and
address any issues earlier in the process.
More solutions can be implemented: -

Osama Mustafa
pg. 10
1. Full inclusion
of web builder with admin app meaning web builder is basically in the administration app. In this case
builder app will automatically have access to all data like product process, photos, etc, which will
eliminate any data flow, hence remove communication delays. However, this might also lead to slow
app response or even legging at times because its heavy since two apps inclusively combined.
Figure 0.1 ARCHITECTURAL DESIGN FOR FULL INCLUSION DESIGN
2. No inclusion
of web builder with admin app meaning instead of combining both apps completely one can integrate
them on module bases. New web builder functionality can be developed separately without have any
connection with admin application. It will be faster in the sense that it will be lighter. However, it will
have quite a lot flow of data between admin app and builder module, which might add some
communication delays.

Osama Mustafa
pg. 11
Figure 0.2 ARCHITECTURAL DESIGN FOR NO INCLUSION DESIGN
3. Micro services-based
integrations of admin app and web builder application. Currently admin app has monolithic
backend which has to be converted to micro services and then implement builder as a service a
well. It will counter all drawbacks of above designs like slow app response and communication
delays. This the best solution with robust solution and opportunity to integrate more features in
future. Please visit https://www.ibm.com/cloud/learn/microservices to learn more about micro
services.
Figure 0.3 ARCHITECTURAL DESIGN FOR MICRO SERVICES-BASED DESIGN

Osama Mustafa
pg. 12
criteria for to determine which design to choose
Criteria Full Inclusion Design No Inclusion Design Micro service Design
Heavy app Yes No NO
Communication delays No Yes NO
Expensive to Implement No No Yes
Is robust No No Yes
Benefits Future
Integration
No No Yes
Require New Technology No No Yes
Considerations
First and foremost, front end users’ experience should be the priority. As it is quite easy for developers
to not consider how their actions might affect user experience when working on back-end project like
this. Depending on current architectural design of the shopping site it will differ how much refactoring is
required to make it changeable and controllable by a website builder. For example, if it does not follow
basic component driven design principles then it can lead to extra work as website itself has to be
refactored significantly before connecting it to a website builder. This refactoring of front end could
result in some changes to UI which might feel unfamiliar to regular users or even lost functionality in
worst case scenario.
Another important aspect to consider would be how admin application will integrate with web builder.
For example, if web builder and current administrational functionalities are implemented on same page
or as described in document as one-page application, then it might cause the application to slow down
or even leggy at points. A robust design will avoid these issues and also give opportunity to integrate
additional functionalities with ease in future.
Last but not least, a separate local environment or testing server should be used for this whole process.
It happens quite often then due to some error or mistake the whole website goes down and obviously
that’s not great for a live website. Furthermore, for extra security the website should have a backup
before start implementing anything.