Big systems

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 16:26
Joined
Sep 12, 2006
Messages
15,990
A thread in the database theory section was going off topic. I thought I would start one here.

Its really about - is there much of a difference between software/databases for BIG systems, and for normal systems.

eg

--- in the UK we have local councils that collect rates/council tax (is there a local us property tax) with which to administer local services (which includes schools, police, libraries, sports centres, refuse removal etc etc)

now (for example) a receivables ledger is a receivables ledger -so the council have to maintain a ledger to cover taxes due from maybe a million dwellings in their area - payment by instalments, direct debit etc.

Now, clearly there are some differences between big and small systems - eg big systems will probably NEVER print out a full debtors list - everything will be managed by exception - it will take them days to print out all their bills, which they will probably do in sections.

They will need to support many more users, and presumably the system architecture will be much more complex as a result

but in principle, are big systems that much different from (well designed!) smaller systems.

I know BIG businesses do become convinced they have to pay BIG sums for BIG solutions - but is this always necessary?
 
Good post Dave...

I personally feel that the difference is reducing. I also suspect that software manufacturers have been guilty of trying to maintain the divide in order to justify the premium for more expensive software. (although I have no real evidence for this).

The design principles should be exactly the same... especially when you consider that if your small system becomes popular it may start to be used by multiple users.

Big business do not have to pay big sums but they often feel comforted by the fact that they have. Too many project managers with no technical skills / not enough gumption are being charged with implementation - especially in government.

I'm just trying developing a system with access and Google Maps. Ordinarily if I went to a big company they would charge us a lot if we bought an off the shelf product. I reckon I can implement a corporate GIS for the price of an ArcVIew to KML polygon converter on one machine (about £30) and that's a one off cost... Some of these software companies must be scared.

Going forward its difficult to see how some software developers can maintain the justification between pricing levels. You might even find in the long term people like Microsoft may only have one product for databases. If for instance you could make stability completly bullet proof, unlimited user access over wide are networks with no restrictions and no speed problems for access why would you need to move to something like SQL server.

The abilities of most software completly outperforms their user requirents as it is so I suspect stability / access / security and ease of use are the main selling points.
 
Last edited:
Hi Dave. At one level I agree with you but it's a bit like saying that a Ford Fiesta is fundamentally the same as a Formula 1 Ferrari.

I work in a local authority and we do have big systems. As you suggest, there's a lot of functionality tied up in the architecture. Security of data and restriction of access are pretty high up the essential list as well as the ability to cope with lots of users. In our financials we have literally thousands of cost centres each with hundreds of expenditure and income types. These costs centres are then tied into multiple structures that allow data to be consolidated in different ways, in real time. User permissions are also tied to the structures and differ for multiple types of data entry with different permissions for each type.

Our receivables ledger, on the face of it is just that, but is has all the security aspects mentioned above, plus it holds contracts against customers that allow for automated billing or adhoc billing with different pricing matrices.

None of this is rocket science, but the requirements of a complex organisation with lots of users do impose a significant overhead on all the applications. With a reltively small customer base, software companies don't have many sales to recover their R&D and other overheads.

Picking up on lightwave's point, we're still capable of using innovative, cost effective solustions, too. We have a full suite of Esri products, including ArcView, but in connection with our Traffic Signals service, we have used a layer on Google Earth to map all of our signal installations. This allows us to see the physical context of the installation including roads, footpaths, adjoining buildings and vegitation without leaving the office.
 
In general, if you develop cheap solution to something where only big, expensive solutions exist, I expect one or more of the following to happen:

-You'll find it hard to sell, because you don't have the support infrastructure of a large company.
-You'll find the costs of rolling it out to a lot of customers will by necessity drive up your licence fees
- You may just decide that it's your turn to be able to charge a higher price, having done the work and joined the big boys.

- You may be approached by the vendor of an established system, wanting to buy you (either to incorporate your product, or to be able to shelve it)
- You may find yourself on the receiving end of hostile/anticompetitive tactics from the vendors of established products (notionally illegal, but there are ways and means).
 
The problem is that it's extremely hard to keep things simple and advanced the same time.

While most users need simple solutions, they can't use complex ones - its too hard to understand and use em at once.

Most big companies need extra-complex solutions and they can't use simple ones.

Nice example of this process MySQL is. Once it was the most simple SQL database, it got popular among internet users - because of it simplicity, not because of it innovative design or features. Now some time passed and MySQL became much more complex because of thousands feature implementations users vined all the time about. New simple database engine will take his place soon and the storyline will start over.
 

Users who are viewing this thread

Back
Top Bottom