Mike,

Your post got me thinking.  The converse to your question is “why is any OOTB software used?”  In particular, I think we should look at why so much OOTB desktop software is used.  Why don’t people just roll their own word processors and email clients?    I think we need to examine that to find out where portals, portlets, and other web-based technologies differ.

I don’t profess to know all the answers but here are some seed ideas:

• The reliance on the network restricts the functionality that can be provided.  Essentially, putting the application up on the web makes the client computer work with one hand tied behind it’s back.  A local application only deals with hardware restrictions whereas a remote one has to account for network latency and multiple clients.  Therefore, portlets generally are not created as fully-featured as desktop applications.  Instead only the functionality needed to accomplish the task at hand is supplied.
• The cost of creating custom apps is not greatly higher than purchasing pre-built ones.  Why deal with support costs when you can pay development costs and own the result?
• One of the great selling points of portal technologies is personalization.  How does using pre-built apps lead to a personal solution?
• Integration is the killer.  Portals are meant to bring together information from disparate systems.  On the desktop, integration is only expected between suites of products (no one expects deep integration between Yahoo Messenger and MS Word).  In the enterprise, rarely are there a suite of products from just one vendor.  Even in the few cases where an organization does have a single vendor’s wares, at least some of them were acquired or developed separately, still leaving some integration challenges.  Not all organizations use those products in the same ways, leading to different data being important in different cases.  All of this make pre-building portlets extremely challenging.

When working with portal, you have to work with a wide spectrum of people and technologies.  It ranges from the end users, visual designers, and front end developers to integration and SOA specialist and DBA’s.  Technologies include portal, search, content management, ESB’s and other service layers, etc.  That’s part of the fun of my job.   That also means I keep track of a variety of topics.   Eric Roch on IT Toolbox had an interesting article about SOA Sponsorship and the Business.   It’s worth thinking about as it’s so easy to dive into the details and lose the forest for the trees.

As a someone who believes in the power of Web 2.0 technologies, I nevertheless get concerned when I hear companies start asking to “add Web 2.0″ to their intra or internet sites.  The first question I usually ask is “why?”  It’s amazing how many companies want to press on ahead with Web 2.0 initiatives without really thinking deeply about that simple question.  My concern is that a lack of clear-cut direction will lead to a lack of confidence in the technologies, when, honestly, the technologies have next-to-no chance without direction.

(more…)

In case you missed it a few weeks ago, Open Text announced plans to buy Vignette for $310 million.  The Austin American-Statesman has a nice write up on the deal and Vignette’s history here.  Gartner believes that Vignette will continue to operate nearly  autonomously as a subsidiary (read more here) with little integration into Open Text’s existing stack.

I find this interesting on several levels:

As a portal technologist, it’s interesting that one of the early portal vendors is no longer an independent entity and could be facing some significant changes in the future.

As an Austinite, it’s one more door closing on the Internet Bubble chapter of our history.

As a Perficient employee, it’s fun to see that we’re one of the last two standing of 1999 Austin-based IPOs (we like seeing our name in the paper ).

Something has been bothering me for a while.   My clients ask about it and I hear various vendors tout some of their out of the box functionality.   I know various vendors have portlet catalogs.  IBM has a pretty large one.  Liferay touts a variety of out of the box portlets or plugins.  I even see independent vendors like Syncex and Descom.   Perficient even has a number of portlets built in JSR 168 that we are willing to let our clients use without warranty.

Now here’s my issue, at it’s heart, reusing out of the box portlets seems like a really elegant solution to creating a business portal.  I hear it touted by all the vendors.  We see retail examples with Yahoo and Google (and netflakes and others).  I just don’t see anyone using these out of the box portlets.   I talk about OOB functionality and most clients don’t spend much time following up.  They usually dive into the custom built portlet arena pretty quickly.  I have to ask why that is so.   So here are my top reasons why I don’t see business portals using much out of the box portlets:

1. What exists in the various portlet catalogs isn’t easy to use.    I spoke with a client yesterday who tried to lift the Liferay portlets to use in his non-lfieray portal.  It turns out they aren’t encapsulated in nice neat little packages and he has to go through gyrations to get them installed and maintained.  IBM has an extensive library full of some very nice gems of portlets.   I speak to them and they pretty consistently note that a new portlet was also released their portlet catalog.   Their problem is that there are so many portlets in the catalog with so many older portlets or solutions. It’s hard to find the gems.
2. Not enough flexibiliy in the OOB portlets.   Those clients that do show interest in oob quickly find that it doesn’t meet all their needs, it may be a bit ugly, it may not have that one configuration they want and so, the build their own.
3. Mindset – IT is still in a build your own world.   We’ve also taught our business users that neat little trick too.   I won’t mention names but I’ve seen where that can bite you.   One business user wanted some very specific functionality that was 85% supported by an out of the box portlet but we ended up developing it custom.   We created exactly what they wanted but blew a chance to just get mostly there and then add more functionality.   The custom portlet also represented more maintenance for him which didn’t make him or his direct reports too happy.
4. Chicken and Egg: There aren’t enough valuable portlets out there to make a compelling case to go use them instead.  Now the problem is that there may not be enough usable portlets because no one is buying them.  If no one buys them then no one builds more and so, you end up with a bit of a stalemate.

Those are my thoughts.  Is anyone out there using out of the box portlets with success or is my experience pretty common?

A colleague recently turned me on to the ZKoss (ZK) Framework (http://www.zkoss.org/), and I have to say that I’m pretty pleased with it so far. 

It’s relatively simple to start up and get working, and it has a nice, rapid development model.   It has some of the feel of jsps but gives you a lot of RIA functionality with very little effort.   Essentially, you just use the pre-built tags and auto-magically excellent-looking UI results.  There’s no pre-compilation required.  You just drop in your .zul files (by default the .zul extension is mapped to the “zkLoader” servlet) to your webapp and they immediately run.   This makes incremental changes during development very easy.

I found the documentation adequate, but, as with any OSS project, more detail would be helpful.  I couldn’t, for instance, figure out how to change the colors of lines in a chart.

It’s pretty easy to set up and requires no more than a Tomcat server to run.  You simply drop in some libraries, and configure your web.xml file and you’re ready to go.

I recently investigated it for a client to determine whether it was possible to generate charts out of Excel spreadsheets.  At first, my hopes were really high, as I misunderstood the documentation (based on a picture) to mean that existing Excel charts could be extracted from the spreadsheets themselves.  Instead, after more investigation, I discovered that it was easy to retrieve tabular information using the ZK tags, encapsulate it in an object, and then pass it to the chart object (created in a “chart” tag).  This resulted in a very nice Excel-like chart.

One of the nice things about this approach is that it is conceivable to be able to templatize the .zul file in such a way that more advanced business users could create their own charts and deploy them through a content management system.  This is possible because of the lack of pre-compilation.

In an upcoming post, I’ll describe in detail how I created a line chart from an Excel spreadsheet, and I’m sure I’ll be exploring the ZK framework more in the future.  I’d encourage others to give it a shot as well.

I encounter a lot of companies debating SAP’s place in the world.  Many ask if the SAP Portal is good enough.  Many want to integrate to it.   Go Big Always talks about SAP missing the boat as their growth slows.  He makes some interesting points.

The new brain now touches everyone at an organization. But not just them, it also reaches out and touches a company’s partners and customers.  While SAP contemplates it’s circulatory system and uses it as the framework to push into extremities and other systems like CRM (sensory system) or SCM (digestive system), it’s hugely missing out on how to capture the new brain.

Having worked on a couple projects either integrating to SAP or debating use of their portal, I think he may have a point.

I’ve been working with portal and portal related technologies since 2000.  During the first 3-4 years I spent a lot of time answering the question, “Why do I need a portal?”  Then things took off and I almost never heard that question.  This year however, has brought a change.  I’ve been asked that question a lot in the last few months.  I think there are two pieces of information here:

1. A change in the economy has everyone back to asking basic questions about value.  If it’s not going to provide value, people aren’t going to pay for it.
2. In general, people still don’t understand what a portal is and does.  When I mean portal, I mean a commercial or open source product that provides portal services.  Most portal products have portal in their names.

Now I’m not going to spend a lot of time talking about a change in the economy.   It’s here.  Everyone is feeling the pinch.  Almost all my clients are asking me to show some ROI and value.  I think we are doing a pretty good job with that.

(more…)

While working to help resolve some issues for a client, I discovered that finding older BEA products on Oracle’s download pages is not immediately obvious (finding the current versions is pretty easy).  I figured out how to do it by following these steps:

1. Go to this page: http://edelivery.oracle.com
2. Click “Continue”
3. Fill out the “Export Validation” form (be sure to select the “Yes” checkboxes for accepting the license terms)
4. Click “Continue”
5. On the “Media Pack Search” page, select “Oracle BEA” and your platform
6. Click “Go”
7. Select the proper Media Pack

• “BEA WebLogic Media Pack for <platform>” covers the WebLogic product line
• “BEA AquaLogic Media Pack for <platform>” covers the AquaLogic product line

8. Click “Continue”
9. Click the “Download” button for the appropriate product

Mike and I are excited to get a new avenue in which to discuss the technologies that we work with on a daily basis.   The opportunity to address portal and collaboration  in this forum is a real thrill for us, and we expect this blog to be a fun, interactive way for us to reach out to customers and interested parties at large.  Their should ample topics, concerns, and opinions to keep us rolling for a long time.

Now for a little bit about me.  I’ve spent eight-plus years working almost exclusively with portals, beginning with five years at BEA Systems working in the WebLogic Portal group.  While at BEA, I gained first-hand experience with how enterprise-class software is constructed, delivered, supported, and maintained.  Since joining Perficient I’ve worked first-hand on the other side of “the wall” separating software vendors from systems integrators.

At Perficient, my areas of focus have included general portal development and architecture (surprise!), webapp security, and content integration.  As a member of the National Portal Practice, I now focus more on strategic initiatives, helping to get portal and collaboration projects moving in the right direction at the get-go.  To illustrate, I read somewhere that Steve Jobs uses the analogy of a rocket.  The launch angle can be easily and minutely adjusted before launch, but those little adjustments can make  a difference of hundreds of thousands of miles as the rocket hurtles through space.  At Perficient we work to do the little, strategic things right at the beginning of engagements when they can have huge impacts on the overall success of projects.

Some of the things I hope to bring to this blog include insights gleaned from client engagements, discussions of effective techniques (both strategic and tactical), and interesting information from a constantly shifting software landscape (anyone notice that BEA and Sun no longer exist?).

As Mike has stated, throughout the course of this blog, you’ll notice that he and I agree on a lot of things, differ on some, and have somewhat different styles.  We think this will lead to a fun read and a vibrant running discussion.  We hope you will all reach out and feel free to leave comments, topics, and questions that you’d like to see discussed.