Fog Creek Software
Discussion Board

Portal Infranet

Did anyone here have any contact with this company/product ? Their site ( ) is not much deep, but they loaded the company where I work with loads of material, which portraits it as the perfect billing solution (of course).

I would like to hear from people who had hands-on experience using it as a billing system for an Internet portal/e-commerce site. Our current billing system is a hand-made application which cannot be supported anymore, and the Portal solution is being seriously considered by management.

They have already implemented it in AOL, Prodigy, Deutsche Telekom (aka T-Online now) and Juno - a good signal, but things such as Vignette StoryServer were also used by most big portals (SS is not a bad product, but it´s cost/benefit ratio is rarely sustainable).

Thank you for any info.

Wednesday, December 4, 2002

My company is an internet portal that uses Infranet for e-commerce.  We've had it in live service for about a year, plus had ~6 months of development leading up to it going live. The engineering experience has not been positive.

I write the ecommerce code that talks to our wrapper code that talks to Infranet. There's a dedicated group of four people who wrote the wrapper code that deals directly with Infranet.  I am one step removed from the pain, but still feel some of it when I implement the code to jump through the flaming hoops to make it behave.

Portal used to be an ISP, and my impression is the product started as their home-grown billing solution. Their business focus shifted, and they switched from being an ISP to a billing software provider.  Their billing software is oriented toward an ISP's view of the world, e.g. metering and charging  for connection time.

The first point I'd make is that this isn't "shrink wrap" software.  We had to do a lot of customization to accomodate what we want it to do, and we don't do anything too exotic.  We've had between one and four Portal consultants here almost continuously since development started,  four during major changes and fewer for normal operation.

I attended the Technical Overview training and part of the developer training. My impression was you have to deal with a lot of low level pieces, like writing C instead of installing some C++ objects. You can do all kinds of customization. (You'll probably have to.) The administrator tool is kind of kludgy. It seems undercooked for the amount of money we're paying; like it will be an ok app in a couple revisions, but it's not there yet.

Second point: get customer references and talk with them about how they actually use the product. Other parts of my company are using Infranet, but they're only using pieces of its functionality. We're using it mostly because the company had already invested a lot of money.

Third point: none of my coworkers who deal with Infranet like it. The coders who are working with it directly have nothing nice to say. They've spent an incredible amount of time making it work, and our needs aren't too exotic. The ops guys get paged regularly by Infranet software errors. My group has written the ecomm app in a way that will allow Infranet to be replaced easily. Even the business guys don't like it.

Fourth point: Talk with real customers about reporting. We did some odd things with naming, and I'm not sure if it was bad design or if it was necessary to make the revenue reports show what it needed to.

For instance, we sell Widgets that you can add when you buy a main product. Instead of having a Widget product, we have a special Widget product for every main product you could buy it with  (e.g.  Foobar_Widget, Frob_Widget, Thingabob_Widget). I am told this is so the reports will show the widget revenue in the Foobar, Frob, and Thingabob categories correctly. If you look in Infranet Administrator, the Widget is grouped with its associated main product. It seems like this association should be available to reports without a different name for every permutation of Product-And-Widget.

Finally, Portal had 50% layoffs in August. What impact will that have on Infranet's lifespan?

In summary, Infranet isn't a worthless product, but it's not an easy one. It's handling our ecomm, and none of the revenue is getting lost in transit. But we're not getting a lot of bang for the buck.

Thursday, December 5, 2002


Thank you very much for your detailed report. I was about to talk to the management people, but there seems to be some political mindset about this product, so I can´t do anything to make them reconsider... :-(

It seems like the "small-company-smashed-the-big-ones-by-not-being-stupid-but-now-acts-just-like-them" scenario is happening here. Sad, very sad.

Monday, December 9, 2002

I recommend you involve  a programmer when the business folks sit down and devise product plan structures and analyze their reporting needs. We're stuck with a lot of inconsistancies and implementation pain due to choices both from in-house staff and Portal consultants. 

Good luck! Hope your company doesn't throw as much money at this product as mine has.

Thursday, December 12, 2002

*  Recent Topics

*  Fog Creek Home