Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Steve Adolph holds a master's degree in computing science and has 20 years' experience in software development. He and Fariba Matin, a seasoned operations manager, are consultants with WSAConsulting in Vancouver, B.C., Canada. Write them at steve@wsaconsulting.com.

Our story takes place at "Epsilon" (not the company's real name), a highly successful vendor of telecom billing systems. Fresh from a dot-com CTO experience, my partner Fariba and I arrive as consultants. Our task? To evaluate Epsilon's software development team, analyze deficiencies with the legacy products and set goals for their replacement.

My agilist friends would be horrified if they saw how I was engaged in this big up-front design, closeted in a conference room, arming myself with a whiteboard marker, trying to somehow divine out of thin air an architecture for the evolution of a multimillion subscriber billing system.

In a few weeks, Epsilon's management is expecting our proposal for the evolution of T's billing system. We need to tell them what, how long and how much. If our answers are to have a shred of credibility, we must create a thumbnail sketch of the system representing our understanding of what we're getting ourselves into.

After weeks of working with Gary and Fred, the analysts in Epsilon's T field support office, we already have a high-level use-case model or a brief for the T billing system. We're armed with a short document describing some of T's technical requirements, most of which distill down to one word: Oracle. We have a process diagram of the existing system and one unwritten piece of information in the back of our minds—a distributed team that's just making the first tentative steps to trusting one another and is fiercely defensive of its territories.

We first set out to answer the question: "What are the major functional components?" by developing a logical block architecture for the system. Looking at our use-case model and the existing system architecture, we can identify blocks for subscriber administration, rating and charging, network management, event reporting and the often-forgotten system management. (I'm surprised at how many developers forget about the poor admins who have to babysit the apps from start-up, shut-down, back-up and upgrade.) In a nod towards my mandate to derive a product from this project, we place adaptor modules at the external interfaces. One reason Epsilon's legacy product proliferated into so many different variants was the need for integration with networks from different telecom equipment vendors, such as Lucent, Ericsson and Siemens. Finally, we add a standalone configuration tool and verify that this logical architecture has some connection to reality by walking a few use cases over it.

Now we need to figure out how to actually deploy this lovely logical architecture. It's one thing to dream of castles in the sky, and it's quite another to build them. We begin by dividing the functional blocks into two categories: those that are real-time dependent and those that are not. The billing engine, network manager and event reporter are true real-time elements. If their results are late, then they're wrong. In Epsilon's legacy system, these components are built around the in-memory data manager. T's requirements for subscriber administration require that large volumes of data be retained for each subscriber and that T's users have numerous tools for analyzing and manipulating that data. The in-memory data manager is designed for speed, not functionality, and certainly not for the manipulation of large volumes of data—but that's what Oracle is all about.

This real-time/nonreal-time division starts leading us to thinking in terms of an Oracle-based front end with a rich collection of data-manipulation tools and a real-time back end, a high performance rating, charging and network management. What cinches this architecture for us is how it cleanly divides responsibilities and relationships between the development center and the field support office. The front end can be designed and built by the field support office and tailored specifically to the needs of T, while the back end is generic, designed and built by the development center, and becomes the basis of Epsilon's new product. This division should enable each development team to pursue what might otherwise be conflicting goals. This division may not be technically optimal, but it will certainly save us many political headaches.

Moral: Good fences make good neighbors: Well-defined interfaces and good divisions of labor make for good relationships in a distributed project.

RELATED ARTICLES No Related Articles		TOP 5 ARTICLES No Top Articles.