[news.eclipse.tools] Re: How to explain to execs benefits of plugin arch

[Martin Möbius <m.moebius@xxxxxx>]

<kduffey@xxxxxxxxxxxxx> wrote:

>I am trying to put together a simple presentation on why I think our
>companie's future products should be built upon a pluggable architecture
>like Eclipse (possibly even Eclipse is SWT and such is not required), as
>opposed to the standard way of doing things, like building a "generic"
>framework with interfaces, and building upon the interfaces.

Building up a framework is not the wrong thing. Only if your
application really needs plugin capabilities you should include them.
I do not think building good plugins is easier than building good
interfaces, more the opposite. E.g with interfaces you get compiler
checking for free.
But plugin architectures are in general easier to extend with
previously unknown funtionality if done right. The part 'done right'
is the problem. But with eclipse you already have a good thought
through plugin mechanism (but adding plugins during runtime seems not
supported! ). And a lot of good examples.

>So far my only wisdom is saying "Well, if IBM can put together a platform
>like Eclipse and big vendors like Oracle, Rational, BEA, Borland and so
>forth are all building upon it, it must be the way to go..", and to be
>honest, the execs and what not aren't caring about that as much. I also am
>one of many developers in the organization and am having a hard time
>"winning over" the lead developers that are the ones who will decide the
>fate of future application development.

I would not come up with the plugin argument. With eclipse you get a
lot of an application framework for free. Resource managment,
Preferences, Dialogs, Helpsystem. Pehaps easier to discuss these, than
about possible advantages to build an application on plugins. You can
introduce eclipse, its advantages can slowly flow into the team.
Anyway, some points for using plugins are an easier reusability, the
more loose coupeling of components.
Read the Who needs a platform? help page (platform plugin dev guide).
It gives you a view what the user|customers want and where plugins
could  help.

And often software is already parted or evolved  (mental or physical)
into 'components'. Why not define them in a more abstract plugin.xml
manner?

>So, can any of you give me some words of wisdom that may tip the scales in
>favor of plugin development, and if so, examples of why it is better.

For an IDE its definitly useful, look how many plugins are done ore
have started. So for integration purposes its good.

>I think the best thing I can think of is that of the programmers guide,
>indicating that developing individual plugins make up part of a whole
>without breaking any of the other parts... for the most part this is true. I
>suppose if a plugin is depended upon by others and changes its workings, it
>could break the "integration" of other plugins.

Its like defining a set of interfaces on a more abstract level with
better expression possibilities. 
If you change the semantics of a method you have to implement from an
interface it is the same problem. Or you have some of these generic
methods where objects are transfered and than casted to the 'right'
type. 

martin