Revisiting the Question of Build versus Buy for Web Portal Solutions

The general wisdom stated in the architectural principles of many an enterprise is “Buy before build”.  This often makes sense since the cost of a COTS license will be lower than the labor expense required to develop the same functionality in-house. There is also the peace of mind that a reputable vendor will own the maintenance of the system core.

Portals may be challenging this general wisdom.

View from the Outside

Putting aside the myriad of capabilities packaged into the common portal product (though we will come back to them later), the essence of a portal when the business looks at the bottom-line is the presentation layer of a web site. The technologies used in the presentation layer of web applications has been evolving the past several years at pace that is much faster than the average portal product release cycle. When the new versions are released, there is often signification re-work that must be done to upgrade or migrate. Because product vendors need to provide solid, dependable software, some of the included technology may already be out of date by the time it is placed in production.

To be clear, this is not to disparage portal product vendors. Anyone that has ever maintained a portal application much prefers having a thoroughly tested platform backed by 24/7 support when something goes wrong. There are trade-offs required to enjoy those benefits, though.

If being able to quickly put new UI approaches and technologies into production is a key business value in your enterprise, you will need to build rather than buy at least part of your portal platform.

Under the Hood

To compare the value of build vs buy vs customize it is useful to consider what buying gets you. What you get for your license dollar will vary greatly from vendor to vendor and even within a single vendor if they offer many options. To keep this from becoming book-length, let’s stick to the most common features available for the most common purposes and apply your own due-diligence to modify this list when examining your own platform selection.

Because terminology can vary greatly from one product to another, we will define these key, common features for the purpose of comparison.

Feature

Definition

Authentication Verify identity of the user
Authorization What the user is allowed to see or do
Personalization Behavior based on information about the user
Context-Based Navigation Site navigation driven by Authentication, Authorization and Personalization
Page Composition The arrangement of components on a page, sometimes influenced by Authentication, Authorization and Personalization
Content Integration Inclusion of managed content, sometimes influenced by Authentication, Authorization and Personalization
Release Promotion Moving features and functions from Development to Staging to Production

Working with the assumption that these are out of the box features, our comparison needs to consider if we need the feature and what it takes to create it ourselves.

Authentication

Every application server has some form of authentication mechanism, and all of the better application frameworks leverage the underlying server standards. While not the least important feature, it is the simplest to implement without a framework. In some cases, it is actually easier to do so.

Authorization

If you are authenticating against and LDAP, most application servers will have easy to use hooks into roles. Popular J2EE application servers have authorization APIs that are standards-based. Initially this may be a little more effort than Authorization, but if you document your approach and publish it internally where it is easily accessed, this should not be a major hurdle.

Personalization

Many development teams struggle with personalization even with a COTS framework where it is a prominent feature. In some cases where business requirements, developer training, product APIs and enterprise data architecture are misaligned, a custom approach may actually be easier. On the opposite end of the spectrum, when all of those factors are in alignment a vendor-provided solution is a major time saver.

Context-Based Navigation

This is often the most appreciated feature of a portal product. While at the UI layer the result is “show or not”, portal frameworks in concert with IDE and/or administration UI provide a rich set of features for coming to that simple Boolean result. Then again, products need to support a very broad set of circumstances in order to satisfy the most customers. You only need to implement those features that are part of your business requirements. In some cases, that will be a very simple implementation. In others you will learn why portal products are so popular. The key is to get very clear on your requirements and then design your solution to be flexible and maintainable.

Page Composition

This is a feature that all portals provide and would be very difficult to build from scratch with the same feature sets that vendor provide. However, very few organizations use all of those features. The complexity is around satisfying the requirements of all companies rather than just yours. If there is no need for runtime updates to page configurations there is no need for this feature. If the feature need is there, tightly managing the requirements and having technical and business stake holders working closely to review cost versus value will allow you to determine what is the best approach for your implementation.

Content Integration

Content management and portals have had a strange relationship dating back before there were any common standards for either. Some portals have content management features built in and some content management systems provide portal application features. Some have standards-based integration points and others simply recommend processes that allow the content to be re-used.

Release Promotion

What sets each vendor apart is how they implement the features. Each product has its own way of maintaining configuration and this results in either a specific tool or process to move that configuration from development to staging and production (plus any interim steps your enterprise happens to use). For solutions built in-house, you will need to define these processes or create these tools to provide the minimal disruption to services while making updates. If a vendor-provided product is sufficiently customized, an enterprise-specific approach may be needed, anyway.

Conclusion

So we see that we can create all of the functionality a portal provides without a portal product. The purpose of a framework is to provide commonly desirable features that are already built and integrated with each other, which is a key value portal products provide.

If all you need are these features, then standard wisdom of buy before build holds true. It still holds true if you can customize a standard offering in a way that is maintainable for you and supported by the vendor.

However, if you want something that is difficult to customize within a vendor-based solution or cannot be supported by the vendor (support-pricing is based on the product working as designed), then you need to weigh the value of that something[1] against building and maintaining it yourself. You may find that cost of ownership for the latest trend does not have an ROI to support following it and still go the out-of-the-box route.

Or you may go your own way and be the subject of the next web site trend-setter spotlight report.


[1] Here we are thinking about modern UI features, but the analysis holds true for anything you need that is of sufficient value

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.