Case Study: Custom Portal Development
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.
Security and Access: Because the client company has stringent security policies, access to sites and applications needed to be strictly controlled. Because of the size of the user population, a per-user approach to content access was infeasible. The customer was enthusiastic about our rules-based Role and Location approach to access control.
This approach ensured that every user would get single-sign on access to precisely the information they needed, when they needed it, in an efficient and maintainable way. For example, policies and procedures needed by an Office Manager are different from those needed by a Customer Service Representative. Further, an Office Manager in Nevada has different policies and procedures than one in Ohio.
People who traveled from office to office needed to be able to get both the information they received at their home office and specific variants that would apply to the office they were visiting, such as specific state policies.
To build this portal, we needed to pose and answer a number of key questions that are common to all portal design.
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 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.
How did it all come out? The portal rolled out company-wide in August 1999, to over 1600 outlets, in time for the corporate Y2K "software lockdown" deadline, and under budget. It has been in continuous use since the rollout, extended by non-programmers to include many more applications, and rolled out to many additional states. We have provided telephone support to the Outlet Communications group but no software changes have been required in that time. Given that quality was a strong driver in the development, we are pleased that the portal has had no bugs reported against it.
Most of our effort on this project dealt with clarifying the requirements and design. The actual software development time for the portal was three person-months.
Find out more about Stokely Consulting's Web Project Management Services to get your Web and Internet technology projects on track. Our Software Architecture and R&D Services can provide Perl and Web programming, data analysis, and system architecture help. We are here to help you succeed!
Stokely Consulting, http://www.stokely.com
Email: Celeste Stokely | Peter Stokely
163 14th Trail, Unit B, Cotopaxi CO 81223, (719) 792-0135
Copyright © 2011 Stokely Consulting. All rights reserved.