Design Your Software Architecture Using Industry-Standard Patterns

In this chapter, we are going to cover the plug-in architecture, what it is, and why it was created. At the end of the chapter, I will show you a real-world example (Pacific Product Viewer), and then you will solve a similar case applying what you’ve learned. Are you ready?

What is a Plug-In Architecture? 

Many people are worried about privacy, whether it’s protecting their banking data, passwords, or making sure no one is reading their messages or emails. One way to ensure privacy protection is via encryption, and many software programs do so.

Most encryption applications are installed in our browser (Chrome, Mozilla, Explorer, etc.) as an add-on: a module that works on top of the browser for any communication and encrypts it. This application is called a plug-in.

A plug-in is like a kid seat on a bicycle: it adds functionality to the bicycle (the ability to carry a kid on the back) that was not present before. You can even add functionality to an existing application designed for something else. Let’s take our encryption example: a browser might be  designed for navigating the web, visiting websites, and reading email. The plug-in, however, is designed to add functionality (encryption) to this existing browser.

What Is the Structure of a Plug-In Architecture? 

Let’s see what this looks like:

As you can see in the diagram above, a standard plug-in architecture has four parts:

• Baseline product requirements: This is the set of minimal requirements that define the application, determined at the beginning of the development process when an initial set of features were included in the product.

• Main system: This is the application we plug the plug-ins to. The main system needs to provide a way to integrate plug-ins, and therefore will slightly vary the original baseline product to ensure compatibility.

• Customer Interface: This is the module that interacts with the customer, for example, a web browser (Chrome, Mozilla, etc.).

• Plug-ins: These are add-ons that enlarge the minimal requirements of the application and give it extra functionality. 

Imagine you are a headhunter who often looks up candidates' LinkedIn profiles (sometimes every two minutes). You use a tailor-made profile selection application developed in your firm.

For each profile you look up, you have to switch tabs in your browser (from the selection application to LinkedIn), type the name of the candidate, and look for it. Then you must select the candidate and extract some relevant information. Then you must copy and paste this information into your firm’s  application.

Wouldn’t it be nice to work only in the selection application and have a little window up to the right to search and extract information directly from LinkedIn? This little window is called “A LinkedIn plug-in” and it can be plugged into your browser.

You enter the name of a person in a search box in the LinkedIn plug-in, and all the person’s data appears in the window. You can have a long report with data coming from many people, and this saves you going to LinkedIn for each one of them.

There are several advantages to using plug-in architecture:

• The plug-in architecture is the best way to add particular functionality to a system that was not initially designed to support it. 

• This architecture removes limits on the amount of functionality an application can have. We can add infinite plug-ins (The Chrome browser has hundreds of plug-ins, called extensions).

There are also a few key disadvantages:

• Plug-ins can be a source of viruses and attacks from external players. 

• Having many plug-ins in an application may affect its performance.

 When Would I Use Plug-In Architecture? 

So, what are some situations that this would be useful for?

Case-Study: Solving a Business Problem With Plug-In Architecture

Let’s apply what you’ve learned about plug-in architecture and see how it works in a real organization.

Pacific is a retail website that is very successful in Southeast Asia. Here are some quick facts:

• The company sells more than 64,000 items on its website, mainly to Southeast Asian customers.

• About 12 items are sold every second on the website, 24 hours a day, 365 days a year. 

• There are heavy users of the site: users that buy many items at once, and they need to do it quickly.  

What’s the Business Problem?

Each time a heavy user wants to buy many items at once, he or she must open separate browser windows for each item, causing confusion and frustration, which can stop the user from making a purchase. For example, some users select ten items, but it the end they buy only six because they go back and forth from the shopping cart to the item pages.

How can this problem be solved? Pacific has developed a plug-in for Chrome called Pacific Product Viewer: when the user installs the plug-in, a list of interesting items is shown in a pop-up window, and there is no need to open multiple tabs. This window allows the user to see many items without having to switch tabs. It is usually located in the upper-right corner of the screen.

This window is the Pacific Product Viewer, a plug-in for any browser. It is a perfect solution to solve this problem! Let’s see how it works:

Let’s explain each component of the ERP system:

• Pacific website: It is the main Pacific website, developed according to a minimal set of requirements.  

• Customer browser: Chrome, Mozilla, Explorer, etc.

• Pacific Product Viewer Plug-in: The piece of software that was developed as an add-on for extra functionality. 

Try it out for yourself!

Now that you’ve seen one solution see if you can apply what you’ve learned to another!

Context: You are a software architect working for an executive search agency.

Your mission: You have been asked to develop a software module to display a candidate's LinkedIn profile each time a recruiter types a candidate's name in their browser. This way, the recruiter can see the target profile without having to log in to LinkedIn each time.

Here are some key questions you can ask yourself to get started:

1. LinkedIn offers a connection to their data through an interface. How are you going to use this to build your plug-in?

2. Some candidates do not have a LinkedIn profile. How will you solve this problem?

Can you produce an architecture diagram for this business setting?

Let’s Recap!