Dans le fichier Zip ci-joint, voici un jeu de slides pour tenter d’exprimer ma vision sur les portails.
En résumé, quelques idées clefs :
- les bénéfices indirects (faciliter l’appropriation de l’informatique par les utilisateurs, rendre visibles les dysfonctionnements ou le manque d’harmonisation des process ou des organisations grâce à la juxtaposition de « vues » provenant de différents businesses) sont supérieurs aux bénéfices directs,
- un bénéfice direct important du portail est un gain en « usability » et notamment en « accessibility » ; mais on peut obtenir les mêmes gains sans portail à condition de les identifier comme objectifs réels (chantier « charte d’ergonomie », etc.) et cette dernière approche est préférable,
- je ne suis pas convaincu de l’utilité de portails pour tous les utilisateurs, pour y mettre les interfaces utilisateurs de toutes les applications informatiques de toutes les business units,
- nous ne devrions pas chercher à faire du portail le lieu UNIQUE d’interface entre l’utilisateur et l’informatique métier car cela serait trop peu rentable voire simplement infaisable ; par conséquent, il est plus prioritaire d’étendre horizontalement la couverture des portails (y brancher davantage de sources d’information, d’un plus grand nombre d’entités de l’entreprise, de manière légère, superficielle, limitée) que de l’étendre en profondeur (y intégrer des écrans d’application plus complets et plus interactifs)
- le portail ne devrait pas être notre principal levier pour simplifier et sécuriser l’authentification des utilisateurs : les solutions de 3SO (Simple but Secure Sign On) habitent dans le back-end du système d’information et non dans l’interface utilisateur.
Pour les débats plus techniques :
- nous devrions privilégier les « remote portlets » aux « local portlets » (couplage faible) mais nous méfier des standards manquant d’ouverture (WSRP est défini par un consortium d’éditeurs et n’a pas fait les preuves de son ouverture pour le moment),
- nous devrions privilégier les technologies de portlets proches des services Web ayant fait leurs preuves depuis de nombreuses années = les portlets fidèles au style REST = RSS dès à présent, RDF pour le futur, voire simplement l’intégration de flux XML en style REST en attendant mieux
- pour découpler au maximum les composants du système d’information d’entreprise et augmenter ainsi sa durabilité et sa capacité de passage à l’échelle, nous devrions privilégier (dans le portail comme ailleurs) l’intégration orientée message pour laquelle les messages sont davantage des documents (ensemble de données) que des appels à des procédures distantes (RPC)
While I agree that in a perfect world, portals are not very useful, I believe we are far from a real world, and there shoukd be no argument on the usefulness of portals. You are being too theoretical. From a practical point of view, Portals can be used to quickly bridge the gap between systems, domains, document types, and also to allow information to be used where it would otherwise not be used.
My Crystar business is a good example. Out BPCS ERP system is old, and there is little justification to replace it. Our staffing is very low, and there is little waste in the transaction side of the system. By building web front-ends to the data, the manufacturing people are now using the BPCS system heavily and it is contributing to business success.
Yes, but of course we could build these same systems using any web-based technology and deploy them outside of the portal.
However that argument is not a good one. In fact we have assembled a broad set of capabilities in this portal…such as blueprints, access database views, access to documents from the LAN, announcements, and highly summarized ERP data from our Data Warehouse. The assembly is based on the needs of the mfg supervisor, not some software engineer. And supervisors have an ability to mix and match and re-sort the tools to their best use.
But again, you can say that a clever Intranet can provide the same benefits.
However a portal is really only a kit for building intranets easily. There is not much magic in it! I agree! But with plumtree I do not have to worry about building a security system, or uploading files to the website etc etc etc. plumtree gives all of these to me in a kit. All I need to do is build the web services/links to make content appear.
Yes there are other ways to do this, but I have found plumtree to be very well suited to my business. The Gadget Server paradigm (and associated methods) are very helpful. By distributing gadget servers I can now make information from a domain accessible to people outside of the domain. I can also leverage my old Access databases accross dozens of users (and they appear to emulate just one user, thus solving the primary problems of Access).
Bottom line is that the portal technology solves a large number of problems and constraints, and simplifies my ability to deliver a useable system to my end users.
And finally I am told that IT is useful to the business!!
Rick said :
> You are being too theoretical.
French people are somewhat supposed to be quite theoretical (you know Descartes and the like…) ! I am afraid my cultural hard-wiring at least makes me sound as too theoretical.
> From a practical point of view, Portals can be used to quickly bridge the gap
> between systems, domains, document types, and also to allow information to be
> used where it would otherwise not be used.
Sure. But my point is that such a quick bridge is limited (it is not a bridge as efficient as a back-end integration made with an EAI). A portal provides juxtaposition of information and interfaces, it does not provide application or information integration. And it is still quite expensive (even if it is not compared with EAI). Or it is not so cheap that it should be adopted as an absolute rule : « thee shalt build no GUI outside of the portal ».
From a practical point of view, I think we should focus on « portalizing » only some very limited numbers of a very high number of applications and data sources. But the experience of the user should still mainly reside in the application itself. More precisely, we should generally not « develop » portlets. We should parameterize generalist portlets (or in the worst case, develop generalist portlets) so that they retrieve chunks of data (RSS) or interfaces (ultra-simple forms) from sources or applications. With ultra-light-weight portlets, we would be able to spread them very widely instead of trying to dive into business applications trying to « portalize them ». Specific development should focus on building business applications not on presenting portlets in the portal. Does it still sound too theoretical ?
> My Crystar business is a good example. Out BPCS ERP system is old, and there is
> little justification to replace it. Our staffing is very low, and there is littl
> waste in the transaction side of the system. By building web front-ends to the
> data, the manufacturing people are now using the BPCS system heavily and it is
> contributing to business success.
Sure you are right to cost-effectively build simple web front-ends. But building them as specific portlets sounds to me as sub-optimal in terms of cost-effectiveness in the long term.
What will you do when your mother company will say : it is now time to throw your BPCS out of the window and replace it with the fresh SAP of your sister division ? (it sometimes happen even when you wish it does not ). You would have to throw away your specific portlets too. And to rebuild new ones. Same thing when your mother company says : » We adopted a new portal system as a Group-wide standard ; you should comply with this new standard. » (you know how mother companies can shamefully be annoying…). ;-)
I think that, with the same money, you might have better built a set of web services presenting very standard presententations of your BCPS data (with the help of RSS or RDF) and then used existing RSS portlets to publish this data into your portal. You would have lost a little in terms of end-user features in the short-term. But you would have earned much more in terms of sustainability and long term cost. (Not mentioning it would have been much more fun for you or your developpers !)
Building web services is not sophistication or over-engineering if you choose the right and simple way to build them (think RSS, RDF, XML-RPC and avoid the SOAP, WSDL and UDDI artillery). It is a clever way of hacking your system to make it published in any portal system.
> Yes, but of course we could build these same systems using any web-based
> technology and deploy them outside of the portal.
>
> However that argument is not a good one. In fact we have assembled a broad set of
> capabilities in this portal…such as blueprints, access database views, access to
> documents from the LAN, announcements, and highly summarized ERP data from our
> Data Warehouse. The assembly is based on the needs of the mfg supervisor, not
> some software engineer. And supervisors have an ability to mix and match and
> re-sort the tools to their best use.
I do not deny the value of juxtaposing chunks of your information systems outputs in a portal. I just think that doing it with specific portlets is not always as cost-effective as throwing simple and robust web services (RESTful web services) into the game. And I think that your ability to build portlets should not force you to use them as s standard specific development paradigm.
> But again, you can say that a clever Intranet can provide the same benefits.
In my humble opinion, a clever intranet is better than a set of portlets when you build a brand new applications. In your case, you are mentioning the need of easing the access of users to a legacy software package. In your case, presenting features in portlets makes much sense. My point on this case is just that you might have better used intermediate web services.
> However a portal is really only a kit for building intranets easily. There is not
> much magic in it! I agree! But with plumtree I do not have to worry about
> building a security system, or uploading files to the website etc etc etc.
> Plumtree gives all of these to me in a kit. All I need to do is build the web
> services/links to make content appear.
Using a set of existing code in order to build an intranet is of course simpler than coding everything from scratch ! But a portal system is not the universal solution for every intranet problem. « There is not silver bullet » for intranets, especially regarding security. Plumtree is a nice kit. But it does not mean it is the kit you always have to adopt and use when something sounds « intranet-like ». Plumtree may be one of the best software package for managing juxtaposed views of portlets. And its distributed architecture (portal server, gadget servers, job servers) is very clever and well suited for building portals. But everything is not and should not be a portal. And you should not put everything into a portal just because the system and your skills allow you to do it. You must know the proverb about everything looking as a nail when you’ve got a hammer in hand.
> Yes there are other ways to do this, but I have found plumtree to be very well
> suited to my business. The Gadget Server paradigm (and associated methods) are
> very helpful. By distributing gadget servers I can now make information from a
> domain accessible to people outside of the domain. I can also leverage my old
> Access databases accross dozens of users (and they appear to emulate just one
> user, thus solving the primary problems of Access).
Definitely, it is a good product.
> Bottom line is that the portal technology solves a large number of problems and
> constraints, and simplifies my ability to deliver a useable system to my end
> users.
Great. But there are other ways to achieve the same results. And my point is that some of these other ways are more cost-effective and sustainable in the middle and long term.
> And finally I am told that IT is useful to the business !
You lucky IT manager ! :-)
On this side of the ocean, I am still told that IT is a « mal nécessaire » (an harmful but needed reality…).
Please forgive my formulation if I sound too « moralist » or « Mr-Know-It-All » in this post.
And thank you for the feedback you gave me in your comment.
Jean, some comments:
You said:
« From a practical point of view, I think we should focus on “portalizing” only some very limited numbers of a very high number of applications and data sources. But the experience of the user should still mainly reside in the application itself. More precisely, we should generally not “develop” portlets. We should parameterize generalist portlets (or in the worst case, develop generalist portlets) so that they retrieve chunks of data (RSS) or interfaces (ultra-simple forms) from sources or applications. With ultra-light-weight portlets, we would be able to spread them very widely instead of trying to dive into business applications trying to “portalize them”. Specific development should focus on building business applications not on presenting portlets in the portal. Does it still sound too theoretical ? »
My reply is: Yes, I agree 100%. The packaged ERP systems (and other systems) are used by the front-end people who need a full ERP capability. The portal is merely providing a view into the database. However this is only one aspect of what the portal does. The portal also:
1) Provides a framework for developing additional applications which are not covered by packaged solutions (for Crystar, it includes customer complaints and corrective action applications).
2) Provides a ‘portal’ into a varitety of documents, such as ISO documents and others which are not controlled by a document control system (these systems are often unneccesarily complex, especially for small businesses).
3) Provides a summary level of access. For example ERP systems do not typically summarize business metrics for display, but a data warehouse may do this. The portal can then display the metrics to a wide audience graphically.
4) I am sure there are more examples.
It is nice to think that our portlets can be simple and generalizable, however I have not found that to be the case. The business needs differ. We generalize portlets as much as possible (good example: business metrics) but some applications require custimization (example: complaint systems, which must pick up and react to very specific issues such as CVD coating problems for Crystar or optical issues in Crystals.) So I DO believe in custom development in these types of examples.
You Wrote:
« What will you do when your mother company will say : it is now time to throw your BPCS out of the window and replace it with the fresh SAP of your sister division ? (it sometimes happen even when you wish it does not ). You would have to throw away your specific portlets too. And to rebuild new ones. Same thing when your mother company says : ” We adopted a new portal system as a Group-wide standard ; you should comply with this new standard. ” (you know how mother companies can shamefully be annoying…). ;- »
My Reply is: Portlets need to be designed, where possible, to not tie us into a specific ERP or packaged software. Of course this is not entirely possible, but they can be written to separate the SQL calls from the presentation, and so we only need to modify SQL calls in some cases. This is also what we do when we take one Portlet and use it for several different ERP systems. Some portlets are entirely independent of the ERP system (for example the Metrics portlets utilize an interface to load ERP data into a standard format. As ERP systems change, they just need to be ‘re-pointed.’ So I di not see this as a PROBLEM per se, just as an issue that needs to be managed.
Yoe said: « I think that, with the same money, you might have better built a set of web services presenting very standard presententations of your BCPS data (with the help of RSS or RDF) and then used existing RSS portlets to publish this data into your portal. You would have lost a little in terms of end-user features in the short-term. But you would have earned much more in terms of sustainability and long term cost. (Not mentioning it would have been much more fun for you or your developpers !) »
My reply is: I love the idea of using Web Services, but have not started to do this yet (it is planned for some of the portlets I am working on). However I don’t think that this really solves the problem. I can segregate SQL calls from presentation in ways that are easier than Web Services, for most of my portlets, I think. SO maybe I do not understand your point.
Also, while I have dabbled in web services, it is always using SOAP/WSDL, etc as supported by my Microsoft tools. I do not understand why I would want to use the different toolset (RSS, RDF, etc). Does this cause me to move out of Microsoft world? I need some help understanding why I would want to do that!
You wrote: « In my humble opinion, a clever intranet is better than a set of portlets when you build a brand new applications. In your case, you are mentioning the need of easing the access of users to a legacy software package. In your case, presenting features in portlets makes much sense. My point on this case is just that you might have better used intermediate web services. »
I do not understand the distinction between a ‘clever intranet’ and portlets. In fact what I am trying to do is build a ‘clever intranet.’ The Plumtree portal is just my tool of choice! And I need some help understanding the role of Web Services. My thinking was to use web services when I need to get/put data into multiple ERP systems from the same application. What I am doing now is to separate the presentation from the data fetching/putting, so that it is easy to modify the data pieces as I move from ERP to ERP.
You wrote: « And you should not put everything into a portal just because the system and your skills allow you to do it. You must know the proverb about everything looking as a nail when you’ve got a hammer in hand. »
My comment: I agree 100%. My biggest project this year is not portals…it is making better use of the ERP systems that we have. And we also have systems like an SPC/data collection system that is a much better idea than trying to use a Portal to do SPC and data collection. In fact just last month I made this recommendation. We need to choose tools for best fit. However if it is a choice between custom developing a VB system to do Quality complaints, or designing the complaint system to be portal-based (using Intranet tools) then I will go with Portal. But Portal does not replace existing tools or good packaged software. The role of packages software is to meet the needs for standard business requirements (or requirements that can be met cost-effectively with portals). There are a few different roles for a portal, as noted above, but it does not replace good packaged solutions.
SO I think we agree on many points. I need to learn more about your ideas for using web services, and also about why you suggest that I use a different toolset than I have learned about from my friends at Microsoft!!
Thanks.
Ping : AkaSig » Portails / CMS en J2EE