"Don't lower expectations to meet performance. Raise
the level of performance to meet expectations."
Ralph Marston, on what always counts
Transaction Processing
The time has come once again. New landscape is
emerging among the largest deployments of systems these past few years,
where Relationships and Transactions are interweaved as never before.
New systems evolve in ways that are not optimally adapted to the current
circumstances. The circumstances had changed too fast and too much
for the technological infrastructure to follow.
The economics are changing as well. Unreliable products are cheaper than ever. It costs more to replace a product than to put a new one in (another) place. The traditional locations are becoming more expensive as well. More expensive to power and more expensive to manage. Managing a location is manual. Manual causes errors. Errors costs.
But there are errors and there are errors. In the tradeoff between no errors at all and some errors, there is a shift towards the latter. It is becoming more economical in large scale systems to make business mistakes as long as another tradeoff is closely looked after - the tradeoff between the cost of the mistake and the probability for it to happen.
Integrations of services happen more, and more frequently as a
necessity for businesses to focus their investments on core value.
Internally, the same trend applies though the drivers here are
scalability, availability, and security.
This abundance of services inside and outside the system boundaries and
the promise of their imperfection dictates changes in architectures and
traditional design concepts.
In this series of articles we will discuss these new trends and the
impact they have on the industry. It is designed for architects,
programmers, IT Managers, and start-up entrepreneurs who are passionate
about transaction processing systems and wish to expand their knowledge
and expertise in this fascinating field.
"A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable"
Leslie Lamport, the implications of the systems we build
