Introductory Portal Strategy Questions

December 4, 2007 at 1:26 pm | In portals | No Comments

I was recently pulled in as an advisor to a portal strategy consulting project and came up with a quick five-minute questionnaire to get a feel for the situation before our first meeting.  I thought it would be helpful to post these questions up as anyone being thrown into a portal strategy project should have these answers lined up before the initial meeting or get to them in the first five minutes. 

There are tons of question one could ask of course, but in my experience these are the ones that result in the most useful answers most often.  So if I only have five minutes to do a kind of end-user portal request for information (RFI), this is what I would ask.  Once I have the answers to these questions I can engage in a useful conversation about any number of portal strategy dimensions (product selection, infrastructure impact assessment, portal timing and roadmap, portal requirements gathering, portal pricing, portal consolidation and rationalization, portal business justification, etc.).

For information gathering about a portal strategy project I want to know:

Introductory

  • What do you mean by portal? To Burton Group, portal products are website factories that aggregate a wide variety of content to deliver dynamic, contextual websites. They provide their users (website builders) with a common set of back-end integration and front-end contextual, dynamic displays that can be used to quickly create websites on a similar foundation. All the websites will share the same infrastructure integration, look and feel, development tools, and management UIs. (from the CCS document “Communication and Collaboration in Portals: Half the Battle”)

Business

  • What is the scope of the portal in question (e.g., just intranet, just a dealer extranet, just as a front end for Oracle Applications, intranet for Division X, intranet for the whole company except our subsidiary ABC which was just acquired) and where does it fit into the other portals the company has?
  • What is driving you to revisit your strategy at this time? Pain points? New initiatives that need to be supported?
  • How much funding have you been given to support the new strategy? Or is the current project being undertaken to determine the funding required?
  • Are there specific metrics that you are aiming to improve? Have they been benchmarked before starting on this project?
  • What products are currently in use today (describe what each is being used for and number of users) and which are being evaluated for the future?
  • What is the timeframe for the portal project (or is determining the timeframe part of this project)?
  • Is this project dependant on any other projects underway or being planned? Do other projects underway or being planned depend on this project?
  • Is there a need to build Web 2.0-type end-user content creation and feedback loops into the portal?

Technology

  • How are the portal products you’re currently using working? Are there problems?
  • Portals pre-integrate with a collection of infrastructure services that are surfaced through the portal UI.  These services include security/identity (authentication and authorization via single sign-on and directory), content management (document management and web content management at a minimum), search, business process management and workflow, and application server and development environment (J2EE server or .NET). What do you currently use for these infrastructure services and are they expected to change? 
  • What is the political context that drives usage of the portal products (particularly with regard to overlapping capabilities of multiple incumbent products) and may affect attempts to change the mix? Are there certain products that must automatically be on the shortlist or are not allowed on the shortlist?
  • What is the mix of development skills (Java, .NET) available for the portal effort?
  • Of the many features that portals can provide or integrate (e.g., collaborative workspaces, discussion groups, document libraries, workflow, access to enterprise applications, search, document management, end user web content creation), which are being used? Which are needed for the future?
  • Personalization and context are a foundation of portals. What are the main categories of roles that the portal addresses? Will need to address? How is personalization utilized?
  • Which enterprise applications will need to be surfaced through the portal?
  • Are mobile or offline capabilities important for your user population?
  • Where do you stand with service-oriented architecture?  Composite application development methods?

The Four Portals of the Apocalypse

October 12, 2007 at 8:06 am | In BEA, Oracle, portals | 1 Comment

ZDNet writes today that Oracle is making a bid for BEA for the demonic price of $6.66 billion. Well, the devil is in the details and there are plenty of them to hash out if this deal ever flies. There is a large degree of overlap in the application server, development tool, collaboration, and portal spaces between BEA and Oracle. At least BEA doesn’t have a content management offering too, so Stellent is safe for now. I find it rather ironic that after writing in May about “How Many Portals Should a Vendor Offer?” that both Oracle and BEA have two sets of portal products on offer, now Oracle could have four (4!) portal products in its portfolio. I’d love to be a fly on the wall as they try to rationalize that one!

There have been rumors of Oracle (or others) buying BEA for quite a while, but it hasn’t happened yet. For example, in May of 2004, Java.net reported “Faced with a tough, if not losing, battle for PeopleSoft, Oracle executives said Thursday that they were considering other acquisitions… Henley (CFO, Chairman) said Oracle had been ‘looking at a variety of areas’ but didn’t identify any potential takeover targets. It has expressed interest in BEA as well as reserve over the price.” Of course BEA was trading at about $8.00 a share in mid-2004 versus $18.05 at the moment.

Time will tell if this deal shall come to pass. It is not for me to judge the will of Carl Icahn, who has reportedly been pushing for a sale for quite some time now. This simply shows that Oracle is continuing to seek growth through acquisition and that BEA has been undervalued, which should came as no revelation to anyone.

Portals, Collaboration & Content 15% Discount

September 25, 2007 at 3:31 pm | In collaboration, portals | No Comments

If you were planning to go to the Shared Insight (now IIR) conference on Portals, Collaboration & Content I have a discount code that I can give you to get a 15% discount.  You can use my code “SPKRM1991CR”. The conference is November 5-8, 2007 at the PGA National Resort and Spa in West Palm Beach, FL.  I don’t play golf (tennis anyone?) but it seems like a nice place.  And be sure to see my presentation “Picking the Right Collaboration Tools for the Job” while you’re there. To register go to www.iirusa.com/pcc .

A Mashable Web Services API is Sticky, Contagious, and Attention-grabbing

August 3, 2007 at 9:31 am | In Composite Applications, Enterprise 2.0, Mashups, Web 2.0, portals | No Comments

I’m hoping that my recent postings on mashups (see here and here) have served to point out that 1) mashups are easier to define as an attitude and “feel” than a strict technological definition and 2) that mashups are not something new, although the attention to the quick&easy end of the composite application development scale is a good thing

I’d like to now add a #3 to that list: 3) that a killer web services API is sticky, contagious, and gets the creator/hoster a lot of good attention.

See this example from the EMC Documentum 6 enterprise content management platform. I had a few conversations with Documentum about the importance of web services APIs and what kinds of things and level of granularity they should operate at. Those conversations may have had a positive effect because Documentum subsequently released their first set of web services APIs, which I thought fit the mold of what customers were looking for. With version 6 they have pushed this further and added a development tool:

– Documentum Enterprise Content Services: a new, Web Services-based API that simplifies development and integration with ready-to-use enterprise content services for easy integration with other enterprise applications within a Service Oriented Architecture (SOA). EMC’s new services interface was redesigned to eliminate Documentum specific methods and terminology and replace it with a vendor-neutral framework for working with content management functionality. These services enable developers with no Documentum experience to build ECM applications quickly and easily. This open, generic approach eliminates the “knowledge barriers” that get in the way of incorporating ECM functionality in all enterprise applications and business processes that deal with content

– Documentum Composer: provides a standardized environment for development and configuration tools that reduce the need for coding and facilitates composition of applications with reusable elements

I’m hoping that as vendors realize how powerful Google Maps has become in part because of the great API that has encouraged thousands of websites to create mashups that depend on it, they will also want to provide “mashable” APIs. “We want to be the Google Maps API of the xxx industry” is shorthand for saying that a vendor (or enterprise with B2B channels) wants to make available a mashable web service that is:

  • Sticky: Once a website incorporates a web services API it is unlikely to remove it for quite a long time.
  • Contagious: Every website incorporating the API acts as an ambassador to visitors that get ideas about how it could be used in their website. To quote an obnoxious 70’s shampoo commercial “And they’ll tell two friends, and so on, and so on, and so on …”
  • Good attention: When the UI being integrated is branded or the source somehow easily recognizable, it acts as an advertisement for the infrastructure underneath.

Will the Real Mashup Please Stand Up

August 1, 2007 at 3:23 pm | In Composite Applications, Mashups, Web 2.0, portals | 1 Comment

I think I get this whole “mashup” thing, but there’s one part I’m still figuring out: why is a combo made with Google Maps considered a mashup?

To explain my confusion, I’ll start with some history. The term mashup is derived from the music world where it describes a song created by combining (generally overlaying) parts of other songs. I’d describe it as a “frankensong”. The term “mash” has implications of a forceful, less-than-orderly combination of things. If you check the dictionary, you’ll see definitions and synonyms for “mash” that include words like “violence”, “pounding”, “crush”, and (yikes!) “pulpy mass”. The implication is that the musical combination is supposed to be quirky, creative, and charmingly rough. The outcome should be “new” – a different vibe, emotion, genre. It should be an unintentional use of the pieces involved.

I can see how a messy Facebook page, with all sorts of seemingly disconnected content and media crammed next to each other to create a new and charming mosaic of someone’s life, would fit the mashup concept.

But take a look at everyone’s favorite web-based example of mashups: Google Maps. A client recently told me mashups should really be called “mapsups” because Google Maps seems to be the only example anyone can give! In fact, according to ProgrammableWeb, Google Maps accounts for 50% of all mashup API use. John Musser’s Mashup Feed shows 54% of examples leveraging Google Maps.

But are they mashups?

Google provides a mapping API that is used to provide geographic visualization. It’s not unintentional or hijacking something for an unintended use. It’s just an API. This is what it is for. It is no different than calling out to a charting API and, indeed, there have been visualization libraries for a long time for bar charts and geographic mapping (Microsoft MapPoint comes to mind). Maybe it seemed like a clever type of repurposing and combinatorial innovation to the first few people that saw mapsups, but they may have been uninformed about the code-calls-API underpinnings.

So, if the most common example of mashups doesn’t fit the narrative of the mashup and its origins, does that mean mapsups aren’t mashups? Or that the word has evolved and, if so, what does it mean now? I’ll mull that over a bit and publish my thoughts in another blog entry.

Integration With SharePoint and Anything

July 31, 2007 at 3:30 pm | In Microsoft SharePoint, portals | 1 Comment

I thought I’d write a few thoughts on a question a client just asked me. I’ll call it the “SharePoint and anything” question and it’s quite common. The company has standardized on some product(s) for collaboration, content management, and portal but now SharePoint is sprouting up all over the place and they want to know what to do. This issue has many dimensions and possible paths, so I’d recommend a client actually talk to me so we can work through it. But I’ll give the high level outline here.

The first question they tend to ask is “Do other companies have this issue?” Definitely! For lots of reasons, both good and bad, the majority of large organizations winds up with more than one system for doing collaboration, content management, and/or portal. I’ve talked to some that list several full portal products in use. There’s a difference between asking what other companies are doing and what best practice is though. Getting down to one platform may not be possible, but it’s a vector in most cases (there’s some complexity here that I won’t expound on right now).

Next, it’s important to determine if you are in an overlap scenario or a contextual integration scenario. Contextual integration just means you have two non-overlapping, complimentary technologies you want to use together like SharePoint and an ERP system. Great - that’s a whole discussion of it’s own that, you guessed it, I won’t expound on right now. But more often it is overlapping with other technology that does a good portion of what SharePoint does. That’s when I poke around and find out why it’s emerging. Because if SharePoint is growing up from the grass roots among other installed alternatives, it must be meeting some latent need that isn’t being met by your current collaboration, content management, or portal.

There are many different types of integration and sometimes organizations want several of these. The project owner has to determine which integration they will need to deal with.  Types of integration include:

  • Programmatic/API level: Either custom coding or dedicated bridging applications like SAP’s Duet
  • Database/Repository/Metadata level: Sharing or direct access of directories, documents in a document library, etc.
  • Execution: Being able to port across platforms, like Mainsoft for Java EE, Portal Edition
  • Web Services/SOA: Wrappering functionality in one portal for use in another
  • Portlets/Web Parts: Java portlets that can surface SharePoint discussions, libraries, or lists. Or, vice versa, Web Parts that can surface content from other portal, collaboration, or content management products
  • Single sign-on: Passing credentials from one system to another
  • Unified search: Ensuring that a search done from SharePoint can pull up documents and discussions in another product, or vice-versa
  • Screen scraping: Old-fashioned scraping of HTML from one site to display in another
  • Linking: As simple as it can get - just helping users of one portal know when information is available in the other by providing a link (but not actually surfacing any content or helping with single sign-on)

Before getting too techie about it, I need to point out that there are technical and non-technical solutions to overlapping portal solutions. Governance and usage procedures are a critical part of the integration and sometimes the entire answer if there are technical constraints. Letting users know when they should upload a document to SharePoint versus their company intranet or their contract management system increases findability of key information.

This is a really quick summary. There are a lot more possible paths to this discussion, such as “systems integration” (connecting it to your infrastructure services, installing and customizing it, etc.), federation scenarios, vendor-specific information about the “anything” vendor and how easy they are to integrate with SharePoint, and more. But those will have to wait until another day.

Mobile Portals are Just Around the (Long) Corner

July 30, 2007 at 10:30 am | In Mobile and pervasive computing, portals | No Comments

The case for utilizing portals on mobile and pervasive devices is a good one. First, consider the driver of portals on the desktop. In a standard web-based portal that is accessed from a desktop PC, the portal helps pick out and display the several applications, pieces of content, and navigation links that are useful for the user out of the huge number of sources the portal has access to. It’s a great answer to the problem of information overload. And, even if you know where all your content and applications are, it is a big timesaver to have them all in one place with single sign-on in front of them. It keeps the user from having to hunt through a “web” of pages (ah, that’s where that word comes from!), scanning them all and clicking in and out of them to get to the needed pieces of content.

That same set of drivers goes double for mobile devices. With smaller screens on PDAs and smart phones it is even tougher to scan through web pages. Combine that with slower access times and it is even more painful to load large web pages to view bits of content and click through several levels of pages to get to it. And that’s why mobile use of portals is going to take off …

… At least, that’s what I was told in 2002. I saw some impressive technology for it as well, mostly from Sybase but also from IBM and Oracle. The technology went beyond simple transformation of pages into WAP and actually provided design-time selection of deprecated page elements, matrices of style sheets for different devices (many pre-provided), and emulators for testing the pages.

The problem is in practice it just hasn’t caught on. Vendors I spoke to a few years later were a bit peeved that significant development effort was spent on features that wound up not being used very much. Mobile portal features appeared as needs on lots of RFPs, so maybe the vendors won some deals they wouldn’t have otherwise, but this code was supposed to be actually used, not just artwork.

There have certainly been inroads into mobile access to information in certain industries, like utility field service and medical. But those are mobile applications and don’t need to leverage portal infrastructure for personalization, application integration, single sign-on, and page assembly.  There is a lot of room for inroads in mobile computing separate from portals.

I think this is a case where it just takes time to catch on and the vendors were expecting a big bang. The drivers are still valid and while I haven’t seen stats, I’m sure mobile use has increased slowly but steadily, although it’s still at a low percentage of overall usage. Maybe a better browser like in Apple’s iPhone will be the breakthrough. Salesforce.com is designing for it successfully. And once the AT&T network that Apple uses upgrades to a higher speed, the improved web page viewing with better resolution and gesturing may be the catalyst for mobile portals finally taking off.

BEA and Different Portals for Different Folks

July 17, 2007 at 4:17 pm | In BEA, Oracle, portals | No Comments

In my previous posting on How Many Portals Should a Vendor Offer I talked about how both Oracle and BEA have dual portal strategies. Since then I had a conversation with Shane Pearson of BEA on this topic. I still stand by my posting, but Shane did point out that BEA is dedicated to maintaining 2 SKUs. This means they are dedicated to 2 purchasable products to meet different needs. They are moving forward over time to unify the infrastructure underneath them and new add-ons will likely support both.

To clarify my posting, I don’t think BEA has done anything wrong. There’s no magic wand that can be waved when an acquisition occurs to instantly rationalize all the personnel, products, and technologies and integrate everything. My point is twofold:

1. A roadmap should be forthcoming from a vendor within a short time after an acquisition (about 3 to 4 months) to reassure existing and imminent customers that their current path will continue or let them know frankly that a product or technology will no longer be supported so they can plan for migration or another purchase. No one wants to be the last one to buy a product before it is discontinued.

2. It is my opinion that, as a buyer’s advocate, software purchasers should be aware that as much as a vendor tries to make redundant services (caused by dual path strategies) under the covers transpearant, cracks start to form over time. These cracks are caused by fragmentation and take the form of higher costs (more specifically, costs that don’t decrease over time as quickly as market pressures encourage), higher risk that a piece of redundant infrastructure that a user is dependant on will be eliminated, slightly lower support costs (especially as one set of infrastructure becomes more rare in the marketplace), and slightly more difficulty finding consulting and integration services. I don’t know for sure that BEA will encounter this issue, but it is the norm and provides a reason for customers to be pessimistic in the long run.

Portal Roundtable

May 25, 2007 at 3:26 pm | In BEA, BPM/Workflow, IBM, Microsoft SharePoint, Oracle, SOA, portals | No Comments

I ran a breakfast roundtable here at the SharedInsights Portal, Collaboration, and Content conference this morning and found it to be quite enjoyable and enlightening (despite the hotel dragging away the coffee and tea service too quickly…). The table had about a dozen attendees, mostly architects, and was a good cross section of portal implementations. A large food franchise, a few large government agencies, a major retailer, a vendor (not a portal vendor), a real estate firm, and an international utility were represented.

The primary issue they were all faced turned out to be integrating service oriented architecture (SOA) concepts into their portal environments. Point goes to Plumtree a few years ago who dedicated themselves to the “enterprise service bus” concept. Portals were originally created as “Swiss army knives” that could connect and adapt to all sorts of identity management, security, content management, and application products. It seems that need is still prevalent. Unfortunately, the vendors have been slipping into the mode of integrating the portals into their infrastructure stacks and playing favorites by connecting to their own infrastructure first and then allowing a standards based connector to everything else (blaming it on the other vendors if they can’t take advantage of JSR 170, JSR 168, LDAP, etc.).

It was interesting that while the momentum is certainly in favor of Microsoft and IBM right now, none of the people at the table reported using them as their main portal. Instead it was BEA, Vignette, and a few Oracle. One was interested in open source as well. The table felt that the reason is that legacy environments are not going away, particularly for content management and portal. While many vendors can show a nice, unified stack now, that doesn’t help the practical reality that organizations face with the large amount of built up legacy infrastructure. Governance is a key success factor then in getting each part of the organization to agree to corporate standards even if it is a little less useful for them. Optimizing enterprise-wide sometimes means a sub-optimal environment for those that heavily use another app that offers a portal.

Workflow was also important to the attendees. A few had workflow/BPM tools they wanted to hook up to the portal such as TIBCO and Ultimus, while others were interested in the more simple capabilities you get out of a portal itself.

« Previous Page — Next Page »

Blog at WordPress.com. | Theme: Pool by Borja Fernandez.
Entries and comments feeds.