![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
It's good to be king -- but it's a lot of work
Earlier this year, industry analyst IDC named IBM WebSphere Portal as the leader in the portal space for the fifth year in a row. Given the rate of change in portal technologies, this recognition clearly demonstrates the level of effort and leadership that IBM is investing into its portal products.
I have had the pleasure of working with WebSphere Portal for several years now, having watched it grow from its initial iterations as an early version of Jetspeed to the industry leading product it is today. Although it has certainly been fun, it hasn't all been a walk in the park. Every version has had its challenges, and every user has had their own expectations.
Integration has always been one of the greatest challenges with WebSphere Portal; this is true of portals in general, but integration is also probably the one area that adds the greatest value. Really, it's kind of the point of a portal: a single user interface for people, content, and applications.
During the first few years after the initial release of WebSphere Portal, there was a bit of a craze around developing integration portlets. As a result, the portlet catalog was bursting with dozens of portlets that were available for all kinds of popular customer applications. (Some remnants of many of these portlets, outdated and unsupported, still linger today.) As you can imagine, that strategy was not very scalable. Just keeping up with the incredible array of different third party products and versions -- let alone trying to support them -- was a monumental endeavor. In an attempt at managing these portlets, vendors were asked to provide and support portlets that integrated with their own particular products; this approach wasn't very well supported, especially since many vendors were developing their own strategies that competed directly with portal technology.
So, again, it comes back to integration and knowing where you fit into the overall enterprise.
If you want to own the presentation to the end user, then you have to provide the best value. You have to consider and support single sign-on and co-branding capability to enable users to seamlessly navigate to your application, perform the function, and then move on to the next set of tasks. If your silo'd application provides just a small set of features that only a subset of enterprise users are going to use, then it makes sense to merge your functionality with a broader interface.
I think we can all agree that this is a portal's true strength: the integration of all things user facing.
Content management systems provide content, ERP systems provide access to HR or accounting data, and custom applications provide their particular features, but integrate all of those through a portal, combined with collaboration and process capabilities, and you suddenly have users working in ways as never before. OK, it's not really sudden; it takes a lot of work, but the potential is there, and the vision belongs to you and your organization, not what any one vendor thinks you should be doing.
In my humble opinion, vendors would do quite well to embrace that integration strategy for users who adopt a paradigm like a portal, and provide pluggable and portable technology that would enable their products to integrate seamlessly with the products of other vendors. JSR168, which we now consider the Java™ Portlet API, was designed for just that purpose: to enable portlets to be hosted in any compliant portal environment. Even more powerful is the concept of creating portlets with a published set of input and output messaging parameters so these portlets can participate in composite applications with other portlets.
Is this a pipe dream? Maybe, but consider the idea of a search portlet from a third party vendor that could be wired together with another third party content portlet that displays customer or product names. OK, maybe not the best example, but if you have integrated third party components in your portal, then you can understand what I am suggesting.
IBM is continuing to invest in new features that not only incorporate new technologies, such as Web 2.0 capability, but also enhance the integration capability of the portal itself. Take a look at some of the new services, APIs, and SPIs that are growing within the portal. I was recently reviewing the URI Resolution Service as a way to target portlets within the portal from outside sources. This is a solid example of the continued efforts by the development team to expand the capabilities of a portal, and a suggestion of the commitment that people like me need to make in order to keep this up.
One size does not fit all is something I say frequently when explaining why there are many different solutions to any one problem, and why things are seemingly so complex when trying to understand any one product or solution. Products have to be both robust and extremely flexible; this is the power that WebSphere Portal provides. Yet it is this flexibility and the component structure of the products that requires some level of configuration and tweaking to get the product to fit just right into a new environment. The full-featured aspect of the product is another reason why there is a lot of overlap between different products and tooling. IBM has three or more different tooling recommendations for portlet building, all of which have comparable features, and all of which have strategic differences so that the proper features can be matched to the strategy of the organization that is considering the tools.
I'd be remiss if I did not mention that the Portlet Factory provides several builders for enterprise and external systems. The ability to build an interface on top of ERP systems, Web services, or even custom Java libraries enables IBM to provide the integration capability when it's needed, without trying to keep up with the hundreds or thousands of products that might be used within an enterprise.
Governance has become a popular buzzword recently, brought about mostly with the focus on Service Oriented Architecture (SOA). But the idea of governance is nothing new to any IT organization, and you are probably as tired of hearing it, as much as I am of saying it, but: Are you doing anything about it?
It's one thing to run an advanced, industry-leading portal system or SOA, but it's another thing to do it well and leverage all the benefits that are available. To this end, users also have some responsibility here. This, of course, is true of any enterprise system put in place by organizational IT departments. In Part 6 of our portal project series, my co-author, Ian Uriarte, and I decided to put a major focus on governance. It was pretty high level and meant to provide an introduction to the topic, but it's really all about setting up rules and boundaries around your shared assets, whether they are services, portlets, or even a complete infrastructure. Basically, things that are shared require that everyone who uses them gets along and plays nicely. Convincing organizations that this is a good idea seems to be a constant struggle. We are all bounded by the daily responsibilities of our jobs and the goal of getting projects finished, but it is everyone's responsibility to promote the idea that rules are a good thing. Rules help to promote cooperation, prevent mishaps and misunderstandings, enhance accountability, and enable recovery. That is, assuming we get things right in the first place.
Organizations struggle with defining a governance model (that's the fancy name for it), but I actually think the harder part is enforcing the rules once they are in place, more than setting up the initial strategy. A decent level of research and knowledge are needed to define a governance strategy, but you have more flexibility when you are just getting started. The best place to start is with what you know, and then leverage the experience and best practices that surround you. However, everything should make sense for your team, your project, and your organization. Remember that flexibility is the key, and to try molding governance to your organization and experience level is easier then trying to change the way your organization works.
More often then not, people look to solve problems, either process or otherwise, with some sort of tool or technology; often the solution is a combination of both technology and a change in the way you perform certain processes and actions. Custom tooling or configuration takes time, and sometimes the best approach is to find a tool that fits your way of doing things, rather than having to conform to a different and perhaps stricter set of rules. Usually, we can't have it both ways, at least not successfully, and so some change is inevitable to make things work better, if not easier.
Take a look at a very simple example, such as the application build process using Maven vs. Ant. Maven requires you conform to its prescribed way of defining and performing a build, and if you accept this, then things work reasonably well. If you want to do it your own way, then you are on your own, as far as getting things working right. Or, you can build your own custom scripts using Ant, which provides a much more flexible approach, but requires more work on your part to define the process and build the components.
This might not be the best example, but it illustrates the challenges and compormises you will face as you responsibly incorporate change into your organization toward governance.
There is still a lot of work to be done for everyone. IBM continues making research and development investments in WebSphere Portal to further enhance customer successes and maintain its industry leadership. Likewise, enterprise environments must continue to evolve so they can fully leverage the advantages and benefits these powerful products have to offer. The responsibility of being an industry leader means that no one has any time to rest on their laurels.
Well, maybe for a day or two, but then it's back to work.
Learn
-
URI Resolution Service
-
Portlet Factory
-
IBM developerWorks WebSphere Portal zone
-
IBM WebSphere Portal Business Solutions (Portal catalog)
Discuss
Anthony (Joey) Bernal is an Executive IT Specialist with IBM Software Services for Lotus, and a member of the WebSphere Portal practice. He has an extensive background in the design and development of portal and Web applications. He is the author and co-author of several books, including Application Architecture for WebSphere; Programming Portlets 2nd Edition; Programming Portlets, the IBM Portal Solutions Guide for Practitioners; and from a previous life, Professional Site Server 3.0. He also contributes to his popular blog, Portal in Action.
Table of contents
Next steps from IBM
Rational products offer a complete collaborative lifecycle management set of tools for the IBM i platform for existing and new developers.
