Since the network was run by technical people it was very easy for each team to setup a database for their own work on a PC. In many ways this worked very well new requirements could be added very quickly and each team had exactly the information they needed.
Of course everyone knows the downside of this type of setup: there is a lot of duplication, different databases can get out of step, there is no clear top level view and no common standards for backup and so on.
So its inevitable that an IT (IS&D) department is setup but once you try to merge all these small databases into one big database it never seems to work well, everything is just too slow, nothing gets done on time and not many people are happy with the compromise that eventually gets built.
Of course this dilemma is not just a PSS/NMS issue, I suspect most big companies have this issue and certainly government databases like NHS!
Relational Databases
Relational databases store information as a set of linked tables.
One of the main advantages of relational databases is that there is a lot of experience and theory in there use over the years, in particular that they are designed to scale up to very big databases with lots of concurrent accesses. There are efficient and cheap off-the-shelf databases available for every type of computer.
This type of database has tables which are fixed when the database is designed and so you can't quickly add new services or new options or new parameters. Any changes require the database to be redesigned followed by a risky cutover of the live system which took months or years.
Wouldn't it be wonderful if there were a database with the advantages of relational databases but where the information fields could be changed dynamically when required.
Customer Databases
As an example the customer databases were a real problem. One option might have been to use the BT-wide customer database but this had its own problems (see this page)
To: M.J.BAKER (TJT106)
Cc: BTG202 (10080:BTG202)
Cc: BTG311 (10080:BTG311)
Cc: L.WAKEFIELD (10092:BTX3053)
Cc: A.BANNISTER (TJT002)
Cc: K.JOSEPH (TJT040)
Cc: C.SMITH (TJT048)
Cc: N.MURTAGH (TJT099)
Cc: M.KELLY (TJT349)
From: C.MILLER (TJT089) Delivered: Thu 26-Aug-93 10:42 BST Sys 10085 ()
Subject: Reply to: Newnet Database - workshop idea
Mail Id: IPM-10085-930826-096310242
In Reply To: IPM-10085-930824-154110465
I think Martin's suggestions form a sound basis for moving forward, but
like him am nervous that we have a jolly nice workshop but few concrete
results.
Any comments?
Chris
From: M.J.BAKER (TJT106) Delivered: Tue 24-Aug-93 17:07 BST Sys 10085
To: C.MILLER (TJT089)
Subject: Newnet Database - workshop idea
Mail Id: IPM-10085-930824-154110465
Database support for Newnet
---------------------------
It is my opinion (and the opinion of those who know the scale
of the problem such as Alan Bannister) that database development
for Newnet needs to be scaled up, and if its not Newnet could
be in jeopardy.
Paul Nolan has done a good job in implementing a S400 inventory
but at this stage thats all it is (no auto port allocation etc.)
We were told that this is a temporary stopgap development. I
think it could be the best basis for a long term solution.
Its a massive job, replacing large parts of the NAD to support
completely new systems, it cannot continue to be done on a
shoestring and without a proper strategy.
We urgently need the following:
* Multiuser support
* Port configuration (including Automatic port and NUA allocation)
* Configuration interfaces
IS&D haven't even proposed a strategy on the following:
* S400s as HSN nodes
* ACP support
* Interworking with FRS/Colour Monitor
* Interworking with CSP
* Interface with other support systems.
One of the reasons that I feel progress is too slow is that developers
need requirements (essential functionality, realistic timescales, user
contacts, etc.) We don't have a project manager who is able to give
timescales for HSN cutover for example. Also users cannot precisely
define the requirements or even say who the users are because the
requirements are still evolving and new systems cut across existing
processes (for example what is the role of the configurators on
Newnet?).
One suggestion for a way forward would be to get the developers and
the users together in a workshop, I do have some reservations about
this as we have already had some wasted 'requirement gathering'
exercises that only produce a vague 'wish list'.
I think the workshop idea could be the best way forward, but only
if:
* The Workshops have high level commitment from senior Management,
ie mandatory attendance by key people, support from project office.
* That, at the workshop, IS&D are able to give detailed proposals of
the scope of the systems and how functionality will be divided
between it and other systems such as CSP and FRS, not just vague
ideas about client-server models.
* That the workshop(s) are focused on specific areas.
and are aimed at developments required by December 1993 or earlier.
I suggest the following workshops:
Workshop 1 - Database Strategy
------------------------------
* Database architecture.
* Timescales
* Scope of the system.
* Interface to other support systems and other databases,
* System administration.
* remote access to system
Suggested Attendees:
Database developers: Paul Nolan, Dave Hanna, Craig Stevens.
Support system developers: Rolf Tietema, Keith Garad, Marc Whiffen
Technical Support: Roger Bellows, Alan Magrath
Project planning: Colin Smith
Workshop 2 - Network Design and Project Plan
--------------------------------------------
* Support for HSN (including HSN S400s)
* Support for ACPs
* Support for Modems, ISDN DBU and NTUs.
* Other requirements not yet covered.
Suggested Attendees:
Network design: Mel Kelly, Steve Best
Project planning: Colin Smith
Database developers: Paul Nolan, Dave Hanna
Standards: Paul Sully
Workshop 3 - Order Entry and Configuration
------------------------------------------
* Order entry, Automatic Resource Allocation
* PSS interlinks
* Special configurations/fine tuning (buffers, manual routes, etc)
* New processes and procedures required
* Work tracking
* Maintaining the system, the config process, maintaining service
definitions, NUAs, serial numbers etc.
* direct data entry by Zone teams:
Suggested Attendees:
* Configuration: Peter Townsend,Brian Evans.
* Order Entry: Eddy Wallace, Richard Billingham.
* IWAN: Alan Bannister.
* FE: Les Case, Ian Richards.
* Technical support: Roger Bellows
* Network design: Mel Kelly
* Database developers: Paul Nolan, Dave Hanna
Workshop 4 - Operations
-----------------------
* Fault Reporting/Tracking
* Commissioning
* Colour Monitor/Insight
Suggested Attendees:
* FO/ Netcon John Smith,Bob Fell,D Bettinson,Peter Fidget
* Database developers: Paul Nolan, Dave Hanna
Regards,
Martin Baker
To: M.J.BAKER (TJT106)
From: C.MILLER (TJT089) Delivered: Thu 26-Aug-93 10:51 BST Sys 10085 ()
Subject: Reply to: re: PSS2 database messages
Mail Id: IPM-10085-930826-097660659
In Reply To: IPM-10085-930826-088630647
Thanks - I think!
I will try to bring this into focus when I return properly on Tuesday.
Regards,
Chris
|
Customer Databases
NAD
MEL
CSP
This was IS&D s great plan for solving the customer database issue. The idea was to build it on top of a relational database (on a Prime computer) but some of the fields would not be hard coded in tables instead there would be some indirection so that the fields could be changed dynamically.
Some people described this to me as a fusion of relational and object-oriented databases. I don't know if this is an accurate description but I never really got a convincing explanation of how it was supposed to work.
Anyway millions of pounds was paid to some company in Chertsey? or Ascot? or somewhere round there.
The software produced was very slow and unreliable. The customer facing teams in MNS were under enough pressure anyway without taking many minutes to access customer data.
This went on for years. A number of people, who knew the details, contractors working in IS&D told me (off the record) that the project was not technically sound and would not work. They were not in a position to rock the boat and they don't seem to have been listened to. My bosses did not want to rock the boat either. What my contacts told me was certain people in IS&D saw this as a chance to pioneer a new database technology and they thought we would be able to sell this as a product.
Equipment Databases
NESS
Further Information
Other PSS related pages
