Application performance management in complex integration architectures

In the beginning, we had low-level system programming. Programs consisted of instructions directly accessing computing resources. Then, performance became a major concern to the program and system designers, especially because of the limited computing capacity available. Later, when the first business-relevant systems appeared, IT performance concerns continued to be strongly related to the resource usage in terms of CPU, memory and I/O. However, performance and tuning specialists became involved in design decisions as well as in development, with more structured and procedural programming languages. The rapid evolution of computing hardware gave IT professionals huge opportunities in terms of resources and performance, while the business relevance of IT systems increased. A kind of an informal “convention” took place: developers were to concentrate on functional requirements, while system engineers were to tune the system and allocate resources later in production. However, universities kept teaching complexity theory, data structures and algorithm optimization methods, which were used by only a minority of IT professionals and in rare situations. The first Software Engineering models, such as waterfall or even the iterative models, concentrated mainly on functional requirements, to optimize the productivity of developers. The age of the client-server architecture added new challenges to the scope of IT performance. Understanding, evaluating and managing concurrency on the server and the network became tedious tasks for network and system engineers. Network sniffers and probes, server and database agents, log and trace files emerged as performance management techniques. However, the performance of production environments remained a concern: software test engineers (not architects or developers) started using load testing tools to evaluate the stability and resource usage of applications with a large number of users (especially with the emergence of the web). System and network engineers were also involved, since they owned the access to agents, probes and log files.