Plugin Architecture: Reversed Effort

DZone 's Guide to

Plugin Architecture: Reversed Effort

Marcelo Mayworm

Apr. 30, 09 · Java Zone ·

Free Resource

Like (0)

Comment (3)

Save

{{ articles[0].views | formatCount}} Views

Are you considering plug-ins in your next application/tool? Plug-in architecture is not a new concept, probably as you know it comes from a long time, and there are a bundle of stable "solutions" to support that, such as "Eclipse/OSGi" and others. Indeed there are several good technical arguments that can catch the development team's eyes when they decide to adopt this kind of solution, taking into account what they are planning for their application. For example:

How can a functionality be added in a future moment?
How can the functionality be increased after delivering?
How can activated a component at runtime, following a specific component/plug-in lifecycle?

There are some strategies/patterns/definitions behind the scenes when the talk is plug-in architecture. I really encourage you delve into this subject.

On the other hand, nowadays we can see interesting points from a business perspective , when a team decide to develop an application/tool on top of a plug-in architecture. It is fact that the market has been accepting these new applications/tool in a good way, not "just" because there are relevant good technical arguments (but again, it depends of what you are planing to develop in terms of application/tool), but because there are different benefits that can be seen through the business perspective.

Usually the business team can take advantage of the ecosystem created around of a plug-in architecture, and define a business model to support the application on the market, involving your costumers and patterns throughout a profit relationship. It is possible to do it in an easy way, because one possibility is introduced naturally:

The application can just create a "contract", defining a functionality/opening that it does not provide itself, although must be added by plug-ins.

This interesting possibility opens the doors for actions that aggregate values for the business around the application/tool, even if it is a close or open license. These actions can be represented as:

The extensibility power, what brings for the costumers and patterns the sensation of "freedom", where they want to improve/add function as they want, without your interaction.
The startup of a plug-in market, where third parties will put their mind to think, trying to create some interesting plug-in adding naturally value for your application, what really well worth. Even if they make money without involving yourself, they will be adding value for your business.
The feedback power, where your application/tool will be all the time being "touched" for others code, and comments/suggestions will popup.

Maybe we can call it as the reversed effort, where your application/tool will be really supported by the third parties, just because you provided a way for them to take part in your business. Of course that there are several others things additional on that, as for example the motivation of your application/tool and etc. But at least the plug-in architecture approach can bring/open more flexibilities and/or opportunities in terms of business, if it fits on your technical stuff.

From http://mmayworm.blogspot.com/