The engagement: The Communications group of a large, nationwide company with thousands of outlet offices wanted a single point of access that enabled all outlet personnel to get specifically targeted information needed to do their jobs. Any intranet site within the corporation was a potential destination.

Stokely Consulting developed a custom Intranet portal for a client. (Portal technology has come a long way since we developed this software in 1998-1999, but the concepts remain the same. At the time of our project, there was little major commercial portal software available.)

Underlying principles: We believe that a technical architecture must mirror the business' architecture. Our technology and process choices in this project stemmed from business requirements. We also believe that the maintainability issues of web site designs are as important as the user-visible issues.

Policy Question: How can we gather and analyze the business requirements? As is common in such projects, fundamental business requirements and the nature of the user experience were fuzzy at the outset. We used a multi-pronged approach to solve this. We employed business scenarios and use cases to refine the underlying business requirements. We used rapid, incremental development of real systems to refine the GUI requirements. We iterated around real GUI implementations as early as possible, to help the customer fine-tune the user experience. We used the results of both the formal business analysis and the living system experience to refine technical scenarios and use cases to drive the development project.

Policy Question: Who will maintain the system? We determined that the Outlet Communications group itself should maintain the system. This group could not rely on the availability of programmers. The group had excellent writers, graphic artists, and project managers. We designed the portal maintenance facilities around these strengths, using a table-driven approach for all data the group needed to manipulate. The outlet communications team maintained the business rules for deciding which Roles and Locations could access each piece of content or application. All layouts were described in terms of Cascading Style Sheets, which the group maintained. Because the maintainers were comfortable with text editors, we did not need to create a GUI for maintenance.

Policy Question: What is the IS support for this project? In the context of the pre-Y2K priorities of IS, we had IS support for hardware and operating system maintenance, but not for application or database maintenance or monitoring. The client's corporate policy did not allow us to use a commercial relational database without IS support, although an LDAP server was available for our use. Accordingly, all data manipulation for the portal, other than authentication, was file-based, using a Unix-style pipe and filter approach. Feeds, updates, builds and content promotion were completely automated and run from the Unix scheduler, cron. All actions and errors were logged, to use in troubleshooting.

Policy Question: How are system users authorized? We settled on the business requirement that self-registration or unregistered use cannot be permitted. We set up a system of Security Officers who could grant varying degrees of access to individual users, mirroring the client's existing security policy. The portal provided a Security Officer application to administer this.

Policy Question: How will the system's demographic data survive reorganization? Over the multi-state extent of outlet operations, outlet openings, closings, and reassignments to different regions is a daily occurrence. Our system needed to be able to gracefully handle the reorganization with no surprises to the users. Fortunately, accurate, daily data feeds were available from the General Ledger. We needed a feed-processing capability in the portal that could incorporate this data into a nightly build so that each morning, our system reflected the current organization from the General Ledger.

Design Question: What are the performance constraints? Outlet personnel should be serving customers, not waiting for page fetches. Therefore, we adopted a strategy of pre-computing the dynamic content of the portal pages based on the Roles, Locations and business rules in effect each day. The necessary pages were produced during the nightly build, and were served statically to users. The combination of Roles, Locations and business rules required only around 100 static portal menu pages and the entire build process took under five minutes. The only situations requiring dynamically generated content using CGI were the Security Officer and Logon applications, both of which were fast LDAP applications and invoked relatively infrequently.

Design Question: How should function be allocated between clients and servers? The target client environment was severely limited, specifically in network bandwidth and the outlet computing facilities. This ruled out client-side Java and required us to tightly constrain graphics file size and use, but permitted portal animation using platform-independent JavaScript. We had powerful and dedicated central servers available, so all significant processing occurred on central servers.

Design Question: How are testing and QA performed? All of the code was designed to be exercised by automated drivers without going through the GUI. No code was promoted until it had run through a battery of automated tests. We set up a four-stage rollout track that ran through well-specified Development, QA, Pilot and Production hardware and software environments. We ran Pilot tests of promoted software to a limited subset of users and outlets, monitoring their use and getting extensive feedback. By the time we promoted the software to Production, there were no surprises.