Join the DZone community and get the full member experience.
Join For FreeAre 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/
Topics:
Opinions expressed by DZone contributors are their own.
Comments