 implement a feature was to read the source code of all blocks that could be concerned. Now, having come that far, it did not take long to find out how to implement the feature, and I wrote the few lines of code that were needed in a couple of days. By then, a month had passed since I started my analysis. The difference between the time (3-4 weeks) it took me to understand enough of the system to really attack the solution and the time to affect a solution (less than a week) was a real eye-opener. I was also dismayed by the low return in investment regarding the system documentation, due to lack of knowledge management. The company had spent many millions of dollars to develop the system library over a number of years, and the only part of it that was of real value for system develop- ment was the source code. At that point, I also realized that if Ericsson's competi- tors had a solution to the problem, they would have put Ericsson out of business by now. Thus, this must be a common problem in the telecom industry. My conclusion was hardly far-fetched: If we can design, produce, deliver, operate and modify these complex networks of systems, there must also be a way to describe them exactly, and to manage the knowledge that is continu- ously created during the evolution of the system. At that point, what my friend planted as a challenge in my mind five years earlier became a professional goal. According to my own experience, it was obvious that the solution to the problem was to focus not on improvements in software and hardware design methodologies, but on the early phases of design where the system architecture, its structure and functions were specified. This was because that was where I spent most of my time and the companies research money, as would other new engineers for many years to come. The only question was: How do you create an exact model of a system of the complexity at hand, a model that must also be easy to manage over years of evolution? My experience in computer-aided design had already told me 