DTJ Number 3 September 1987 - Digital Technical Journals

The Evolution of Network Management Pr,oductsbasic functions of the early product into thericher VAX architecture. We then added aninvoicing capability and built a common userinterface to yield the final product.Besides tracking telecommunications information,P jFM can track charges for nontelecommunicationsitems, such as monthly parkingfees, office cleaning, and equipment rentals in afacility environment. These capabilities allow alandlord of a building to present tenants with singleinvoices that charge not only for telephoneusage, but also for virtually . anything he hasdefined as a billable entity.Unlike the early product, used primarilyby telecommunications managers experiencedwith computers, the P jFM product is aimed at amore business-oriented market. Therefore, itneeded an extra degree of friendliness to besuccessful. End users can choose a wide varietyof processors from the VAX family, which providesdevelopers with an excellent base operatingsystem on which to add future functionality.Not only do users have access to bigger databases,but developers have all the VAX layeredproducts with which to construct their applications.One such product is the ALL-IN- I system.Although presented primarily as an officeautomation product, this system provides avery user-friendly environment for entering dataand paging through forms. When building P jFM,we took the office automation forms software..from the ALL-IN-I system and borrowed theremainder fo r the base software. The resultingproduct has the ease of use associated with officeautomation, although it is dearly not officeautomation in the electronic mail or calendarsense.To get the P jFM product into the marketplacequickly, we designed and wrote the first versionof the software in a fairly short time. This versionconsisted of two separate and distinct subsystems(expense tracking and invoicing) , even thoughthe user saw only one system interface. Unfortunately,in some cases information had to beentered twice to produce different reports usingthat information. Furthermore, the TELEPROalgorithms were based on a limited program sizeimposed by the original 16-bit PDP-1 1 architecture.Those parts of PjFM based on this architecturewere already at their limits. It was clear theexpanding market for this product wo uldquickly supersede P jFM's ability to go beyond itsoriginal goals.Evolution of the P jFM SoftwareTo meet these expanding needs, we redesignedP jFM with a new architecture that allowed certainareas to be easily modified in the developmentprocess, as well as in the field. In essence,th,is new architecture would provide P jFM'sbasic set of fu nctions. As needs arose for additionalfunctions, experienced customers orDigital's Software Services personnel could writethe necessary code. The resulting product wouldhave more functionality and be better integratedand therefore easier to use. Furthermore, bybeing tailored to fit the VAXjVMS environment,the product's performance would improve aswell.As companies throughout the country expandedtheir telecommunications needs, we sawa continual flow of new product requirements. Itbecame obvious that a more formal strategy forchanges was needed to keep up with the constantlychanging market. To satisfy this need, wedecided to have frequent PjFM releases (e .g., thenext two releases came out about a year apart) .This schedule would allow us to add new functionalityto the base product, such as supportingchanges in FCC regulations or implementing specialrequirements from customers. Most importantly,it allowed us to offer in the base productsome of the custom programs written by SoftwareServices. These programs expanded thebasic P jFM functionality while removing theburden on external groups to support customcode.·Although customers could then get the functionalitythey really needed, the overall cost ofoperation was still a problem. A customer couldeither run PjFM on a stand-alone VAX-1 1/730system or share a larger VAX CPU (1 1/750 or11 j780) with other applications. This latterchoice could reduce the capability of the customer'sprimary processor . In essence, PjFM'sprocessing needs for large organizations requiredmore hardware than many users werewilling to pay for.This problem was quite effectively solved byDigital's new low- and high-end VA X processors.The MicroVAX II system provides a cheaper andmore powerful low-end processor, while theVAX 8000 series can, when clustered, provideconfigurations with mainframe capabilities .P jFM can run efficiently on a Micro VAX II systembut now at a considerably reduced cost from theformer arrangement. If a customer wants to run126Digital TecbnicalJournalNo. 3 September 1986