Have you ever noticed that as application flexibility increases, the more complex
the delivery technology becomes, and the more difficult it is to manage performance
delivered to users?
When applications were monolithic, they were inflexible but relatively easy
to manage because everything was in one place. Then along came web browsers,
Java, and .Net which increased flexibility, but created a tiered architecture
that became a performance management nightmare. And just as IT was finally getting
new application management solutions to deal with those tiers, there's a new
wrinkle - portals.
Portals enable users to have the simple, familiar browser page look-and-feel,
but allow them to interact with multiple services and data-sources. So, instead
of flipping between four browser tabs -- say, a customer history page, inventory
search page, competitor database page and a quote application page -- there's
a single portal with all of the application interfaces displayed simultaneously
as portlets. Plus, if Web 2.0 technologies have their way, you'll be able to
drag-n-drop info between the portlets.
While portal technology makes applications more flexible, the level of technological
complexity has increased from the first Java -based web applications developed
just a few years ago. Not only is there more technology in the mix (portal servers,
web application acceleration infrastructure, and maybe some SOA integration
infrastructure thrown in), but also there are new challenges. For example, it
is critical to understand the elements and interactions controlling the rendered
page, the affect of extensive personalization options on performance, the effect
of client-side scripts on performance, and interactions with external portals
or content are just some of the new issues for IT.
To meet these challenges, here are some quick suggestions to help optimize your
portal implementation:
First, do not depend solely on your portal vendor to give you the tools to
deal with these challenges. The portal vendors will give you tools to monitor
their technology not the custom presentation logic your company will be building.
Second, educate your users and developers that the more stuff and personalization
they cram on a single portal page, the slower performance will be when it gets
out of the lab and into the real world.
Third, educate yourself about what can and should be monitored to understand
the user experience. Monitoring a single portal server will not tell you if
one portlet is holding up the whole page or if Web 2.0 technology on the client
side is killing response time.
Finally, understand how to extend your existing management tools. Many Java
and .Net application monitoring solutions will easily extend monitoring to back-end
portal and integration servers but may not be able to map the presentation logic
driving the page layout delivered to users to that back-end technology. However,
this is not about creating another management silo - we have too many as it
is -- any new management capabilities should snap into what you already have.
