PortalworkX (the "k" is silent) is a configurable product that supports
collaborative relationships. Since both "collaboration" and "relationship"
are part of coffee-break conversation these days, let's start by asking
what we want them to mean.
relationship is a defined and understood arrangement between two
or more parties. A relationship involves some kind of communication. However,
sometimes communication does not give a useful relationship. If you haven't
heard from your college roommate in ten years but keep sending birthday
cards to her last known address, that's not much of a relationship. If
you each send birthday cards to each other, but they don't ever include
notes - not even acknowledgements of the last card - that's also a relationship
in name only. A practical relationship involves some knowledge of the
state of the other party, at least as far as it involves the communications
that have been sent. This is, of course, why e-mail is frequently such
a frustrating tool. While you can sometimes find out whether a message
has been delivered, if you don't get a reply, you don't know whether your
message is being acted on.
can be looked at as a relationship formed to achieve a specific goal.
The goal might be precise and short-lived, such as solving a particular
problem by a particular date. Or, it might be less contained: the geographically
dispersed members of a supply chain are in a long-term collaborative relationship
to maintain production of a product in a way that is profitable to all
concerned. One thing that is generally important about collaboration is
that it be driven by business rules, which may change from one collaborative
relationship to another.
PortalworkX is designed specifically to enable collaborative relationships
of all kinds within a company and between a company and its partners.
Figure 1 shows a simple situation. ABC Widgets has two distributors. It
wants to share certain kinds of information with its distributors. Some
of this information - product specifications, for example - would be shared
with both distributors. Other things - price lists, leads, and internal
planning documents - might not be shared equally. Furthermore, because
ABC Widgets has had a longstanding relationship with one of the distributors,
DC Distribution, ABC is willing to let DC bring some of its customers
into the relationship. With PortalworkX, DC can do this on its own, without
any need for ABC to perform administrative tasks. Even though DC's customer,
CustCo, will now have access to some of the same documents as EZ Distributors,
neither will have any way to find out about the existence of the other,
since neither has a relationship to the other within the system. We'll
look at other kinds of collaborative relationships and how they can be
created with PortalworkX later in this document.
is difficult to precisely categorize PortalworkX. It has characteristics
of a corporate portal, of a groupware product, and of a workflow tool.
In particular, it does indeed build portals, whose look-and feel can be
highly customized - both to the company and to the individual. Even Radnet
hasn't fixed on a name for the category of which PortalworkX is the first
entrant. Terms like "B2B Portal," "Relationship Portal" and "content-centric
collaboration" have been used, and none is yet completely satisfactory.
The company's biggest fear is being lumped as just another corporate portal;
while PortalworkX indeed has many of the features of a corporate portal
product it was designed to solve a different set of problems, and having
customers recognize the importance of those problems will be crucial to
the product's success.
The first well-known commercial tool built with collaboration in mind
was Lotus Notes, so it's not surprising that the founders of Radnet have
their roots in Lotus Development Corporation. They split from Lotus in
1995, when it seemed that Lotus was ignoring the Internet, and created
a product called WebShare to enable collaboration over the Web. However,
when Lotus later developed Domino, they found themselves in a David and
Goliath situation, except without the necessary slingshot.
then made the decision to focus on solutions, instead of on enabling technology.
In particular, they saw the need for collaboration in business-to-business
environments. Such environments, in their vision, range from extranets
to B2B marketplaces. The example above is illustrative of the application
of PortalworkX to an extranet. For a marketplace application, Radnet's
VP for Product Marketing George Eberstadt likes to paint this picture:
"Two companies that are members of a B2B marketplace come to an agreement
to engage in a trade of some kind. Then, they leave the marketplace and
hammer out the details of pricing and delivery by fax, phone and e-mail.
Radnet is not the only one to recognize the need for private spaces within
an electronic marketplace (see Antidisintermediation).
However, in Radnet's case, the feature is more flexible than one that
might be built into a particular marketplace.
company sees as very important finding the right balance between out-of-box
functionality and fluid configurability. The first product after WebShare
was a highly configurable customer service product. From this, as well
as from the extensive experience of their CEO David R. Scult, who previously
managed Lotus' consulting operation, they came to some significant conclusions
about this balance.
want a product that is highly functional out of the box
- No out-of-the-box
product will meet the needs of any customer, so configurability is required
- A proprietary
development environment is not cost-effective for customers (unless
thousands of consultants and unemployed software engineers have experience
want the bulk of customization to occur when the product is installed,
rather than having to constantly fiddle with it
In the next
section we'll see how these constraints have been woven into the product's
PortalworkX provides a number of services for sharing and managing content
and processes, and for personalizing each user's portal in significant
ways. Beneath all of them is what Radnet calls a Business-to-Business
Permission Engine. To understand the other features we must first look
briefly at this engine, and at the Java implementation of the product
as a whole.
Permission Engine provides and enforces a model known as Cascading Permissions.
Every action that can be performed on an item has its own permissions.
For example, a document will probably have a read permission and a modify
permission. Associated with each permission are two rights: perform and
grant. Having the perform right for an action allows one to apply that
action to the item in question; if you have the perform right for read
then you can read the document. The grant right does something different
- it allows you to give someone else the right to read the document. This
does not require an administrator or a programmer. One of its obvious
applications is in the situation shown in Figure 1. If ABC Widgets gives
DC Distribution the grant right for certain documents then DC can grant
to its customer CustCo the right to read those documents. Among the things
that can be granted are the perform and grant rights themselves. Therefore
access to documents and other items can cascade down a sales or supply
chain, with each company or individual managing its own local partners.
Engine also manages the many-to-many relationship features. An individual
cannot see items or individuals unless some sort of relationship exists.
This is of course much stronger protection than seeing an item in a list
of documents or a person in a pulldown list of addresses and being told
that you don't have the appropriate rights to read the document or send
mail to the user.
product is entirely built in server-side Java; no applets are ever uploaded
to a user's browser. The extensive Java library is available to companies
that want to make custom enhancements - and Radnet expects that most of
its customers will do this - but the base capabilities are quite rich.
And, because the fundamental constructs are part of the root object from
which all others inherit, those base capabilities are also quite powerful.
out-of-the-box capabilities group into three sections: The Portal Engine,
Content Management and Process Management.
Portal Engine manages each user's interface with the system. The basic
look and feel - company logo and so on - are typically set during installation,
but the user has a great deal of control over the entry page. Radnet
calls this the "Briefing Page," because their notion is that it will
be limited to notices of new or changed items. So, if the user chooses
to display a news feed on the Briefing Page, what will be displayed
will typically be the new news items. The user of course, has access
to others, and has the freedom to configure the page differently, but
the intention is to provide a summary of items that merit attention.
Figure 2 shows a Briefing Page. The Briefing Page also provides access
to a powerful search capability. A user can specify searches over internal
documents and across the Internet.
items - documents, messages, and postings on discussion lists - are
treated uniformly by the system. Even though they may be used differently
and have different characteristics, they all share a common base of
capabilities. For example, any item can be subscribed to; that means
that the subscribing user will be notified when the item changes. This
includes searches; a user can subscribe to a search string, and be notified
when any document in the internal repository or on the Internet changes
so as to satisfy the search. (Internet searching is done via a spider;
searching to see whether documents satisfy subscribed searches happens
when the documents are encountered by the spider, an approach that provides
much better response times than searching the Internet when the search
request is made.) Any item can be associated with any other. This makes
it easy for documents, chat sessions, and tasks to be tied together
in an ad hoc network, ensuring that appropriate supporting information
is known and available at all times.
provides tools to support business needs as they evolve, whether or
not they follow the formal corporate hierarchy. Thus a newly formed
team can set up its own discussion groups and workspace areas, as well
as calendars and project tracking tools. Once these are created, team
members can subscribe to documents or to threads in the discussion.
Additional applications can be added, either for a work group or across
the organization. These also follow the permission model; they automatically
have certain permissions associated with themselves, but can declare
others as appropriate.
box is only the beginning, however. PortalworkX provides extensive capabilities
for customizing both the look and the functionality of the product. An
organization can use the product's native capabilities to craft a collaboration
environment that reflects formal workflow requirements and still leaves
room for individual teams to form, work, and disband in a way that is
optimal for their individual needs. When more is called for, such as providing
access to back-end systems or developing specialized applications, the
PortalworkX object library is available for custom programming work, so
that any additions will be indistinguishable from native PortalworkX capabilities.
is natural to wonder how PortalworkX differs from a tool like Lotus Notes
or Microsoft Exchange. The folk at Radnet, with their past-life involvement
at Lotus, are among the first to sing the praises of Notes. While admitting
that they do not intend to be a substitute for Notes, they suggest that
the crucial differences are the support for relationships that do not
follow the company hierarchy, such as ad hoc work teams; cascading permissions;
and, the ease with which individuals can create and customize their own
environments, including the ability to involve business partners from
outside the company.
An example of the way that PortalworkX finds its own place within a company
is a recent experience of a major computer manufacturer. The company's
North American Marketing division recognized that they had no corporate
marketing calendar. Thus, one division might be holding a product briefing
in St. Paul at the same time that another group was doing something similar
in Minneapolis. Without coordination, the company was unable to take advantage
of economies of scale in renting facilities, catering, and assigning support
staff to cover the events.
the only interest was in a vehicle for coordinating these events, and
the company quickly implemented a PortalworkX solution. However, once
the sales force heard about the new system, they realized that it solved
one of their problems: they had never been completely informed about marketing
activities in their regions. Although the system was initially built for
the Marketing department, it was easy to provide salespeople with access
and the appropriate rights.
the Marketing folk realized that there would be advantages to collaborating
with their outside partners, such as system integrators and retail outlets.
Such partners could steer their own customers to these events. Again,
it was easy to provide these partners with access to the information of
interest to them, and only that.
this point, the Marketing group saw the possibility of using PortalworkX
for full tracking of these events. So they added, again using native capabilities,
workflow that allows for proposing, creating and approving events, including
budget tracking. The workflow ensures that every step - from sending out
invitations and press releases through providing the right mix of regular
and diet soda - is taken. Along with the workflow, the company defined
a new object, a program. A program is a collection of activities,
and each activity can have an associated ad campaign, event
or other marketing component. Even though a program is not a native
PortalworkX item, it has all the capabilities of other items. It has permissions,
which can be assigned to groups or individuals; it can be subscribed to;
and, it can be added to a calendar; it can be associated with other items.
this way the PortalworkX system evolved from a point solution to an enterprise-
(and partner-) wide system that provided significant enablements and efficiencies
to an important business function.
The problem for Radnet is educating the customer. As the example of the
computer manufacturer shows, it may not be obvious how PortalworkX can
help a company until the company has had the opportunity to learn to think
in a new way. There are significant advantages for a company willing to
make the effort, but that first step outside the box is a huge one.
while there are substantial out-of-the-box capabilities, including extensive
customization features, many sales will require extensive professional
services support. Radnet is fully capable of building an effective support
organization, but this requirement has the potential of limiting the growth
of the company.
think the most important thing for Radnet to do is develop channels. The
company has taken an important step by developing a relationship with
Andersen Consulting. Andersen will serve as an important marketing and
implementation channel for Radnet, and is also providing management consulting
through its Boston Dot-Com Launch Center. More partnerships of this nature
will be incredibly valuable in helping the company achieve a critical
company might also try to develop packaged products that contain additional
industry-specific enhancements - complete solutions instead of starter
sets, in other words. This would make it easier to focus on mid-range
companies. A third option would be to partner with a major ASP. Under
the right kind of partnership, the ASP would take the lead in providing
integrations to back-office systems, and would offer an attractive and
painless path for smaller and mid-sized companies to begin using PortalworkX.
we think that Radnet would be well served by a corp of evangelists. When
Apple was first marketing the Macintosh it had a staff whose job was to
create buzz by showing how powerful and useful the platform could be.
Most of Radnet's customers don't know that they have a problem that PortalworkX
can solve. Teaching people to think about collaboration is the first step
to selling collaboration.
Collaboration has been a goal for the use of computers at least since
the early days of the Internet (whose original goal was to be a platform
for collaborative development of software). As TCP/IP connectivity becomes
omnipresent, collaboration is coming within reach of everyone. But our
notion of what collaboration can mean is limited to the kinds of collaboration
that have been available in the recent past. For most of us, the features
offered by PortalworkX break that mold, and provide new and more effective
ways to work together. In fact, PortalworkX is as close as anything we've
seen to the Holy Grail of empowering groups (and individuals) to work
in their own way without upsetting corporate structures.
company that has problems involving the sharing of information across
groups - especially when the groups can be fluid, can form and dissolve
on short notice, and may have open-ended charters that might involve them
with partners or customers, should give Radnet a chance to show them a
PortalworkX solution. PortalworkX is an excellent platform for rapid prototyping,
and so Radnet can quickly demonstrate how their deep understanding of
collaboration applies to your requirements.