Performance management work: Difference between revisions

added two internal links to wikipedia articles
Author name was corrected
Line 12: Line 12:
System architectures used to be monolithic consisting of one large single construct. They have progressed to distributed architectures and further to system of systems architectures.<ref name="BrunnertVoegele2014"/><ref name="Jamshidi2009">{{cite book|author=Mohammad Jamshidi|title=System of Systems Engineering: Innovations for the Twenty-First Century|url=http://books.google.com/books?id=1uoeAQAAIAAJ|year=2009|publisher=Wiley|isbn=978-0-470-19590-1}}</ref> An interrelation between system of systems architectures and IT governance is the allocation of several systems to different organizations or organizational units. Similarly to the expansion of system architecture, the former unilateral IT governance becomes a multilateral IT governance with special needs for organizational integration.
System architectures used to be monolithic consisting of one large single construct. They have progressed to distributed architectures and further to system of systems architectures.<ref name="BrunnertVoegele2014"/><ref name="Jamshidi2009">{{cite book|author=Mohammad Jamshidi|title=System of Systems Engineering: Innovations for the Twenty-First Century|url=http://books.google.com/books?id=1uoeAQAAIAAJ|year=2009|publisher=Wiley|isbn=978-0-470-19590-1}}</ref> An interrelation between system of systems architectures and IT governance is the allocation of several systems to different organizations or organizational units. Similarly to the expansion of system architecture, the former unilateral IT governance becomes a multilateral IT governance with special needs for organizational integration.


The subsystem lifecycle is an iterative process from system development to IT operations, whereas both parts involve different goals. The system development (Dev) is responsible for implementing new features and functionalities to cover functional requirements. In contrast, a IT operations (Ops) team monitors AS and ensures its maintenance and stable state. Traditional SPE activities support Dev teams to meet non-functional requirements such as response times or scalability. In doing so, performance goals and metrics can be defined and measured through load testing.<ref name="WoodsideFranks2007">{{cite conference|last1=Woodside|first1=Murraay|last2=Franks|first2=Greg|last3=Petriu|first3=Dorina C.|title=The Future of Software Performance Engineering|year=2007|conference=Proceedings of the Future of Software Engineering Conference (FOSE)|location=IEEE Computer Society, Washington|pages=171–187|doi=10.1109/FOSE.2007.32}}</ref><ref name="BrunnertVoegele2014"/> A method to achieve performance goals at an early stage of development are performance models. They can be created using design models and are applied as input for simulation engines and analytical solvers. Traditional APM activities support Ops teams to ensure performance goals mainly by meeting service level agreements (SLA).<ref name="Menasce2002">{{cite conference|last1=Menascé|first1=Daniel A.|title=Load Testing, Benchmarking, and Application Performance Management for the Web|conference=Proceedings of the Computer Measurement Group Conference (CMG)|location=Reno|year=2002|pages=271–282}}</ref><ref name="BrunnertVoegele2014"/> APM activities have to ensure that sufficient capacity is available to ensure that performance goals can be met. Furthermore, APM activities help to evaluate changes in one or several subsystems. Nowadays, [[DevOps]] concepts try to better integrate activities in both life cycle phases. Communication as well as collaboration between both parts support that performance goals can be met. Similarly, SPE and APM activities must be integrated as well.
The subsystem lifecycle is an iterative process from system development to IT operations, whereas both parts involve different goals. The system development (Dev) is responsible for implementing new features and functionalities to cover functional requirements. In contrast, a IT operations (Ops) team monitors AS and ensures its maintenance and stable state. Traditional SPE activities support Dev teams to meet non-functional requirements such as response times or scalability. In doing so, performance goals and metrics can be defined and measured through load testing.<ref name="WoodsideFranks2007">{{cite conference|last1=Woodside|first1=Murray|last2=Franks|first2=Greg|last3=Petriu|first3=Dorina C.|title=The Future of Software Performance Engineering|year=2007|conference=Proceedings of the Future of Software Engineering Conference (FOSE)|location=IEEE Computer Society, Washington|pages=171–187|doi=10.1109/FOSE.2007.32}}</ref><ref name="BrunnertVoegele2014"/> A method to achieve performance goals at an early stage of development are performance models. They can be created using design models and are applied as input for simulation engines and analytical solvers. Traditional APM activities support Ops teams to ensure performance goals mainly by meeting service level agreements (SLA).<ref name="Menasce2002">{{cite conference|last1=Menascé|first1=Daniel A.|title=Load Testing, Benchmarking, and Application Performance Management for the Web|conference=Proceedings of the Computer Measurement Group Conference (CMG)|location=Reno|year=2002|pages=271–282}}</ref><ref name="BrunnertVoegele2014"/> APM activities have to ensure that sufficient capacity is available to ensure that performance goals can be met. Furthermore, APM activities help to evaluate changes in one or several subsystems. Nowadays, [[DevOps]] concepts try to better integrate activities in both life cycle phases. Communication as well as collaboration between both parts support that performance goals can be met. Similarly, SPE and APM activities must be integrated as well.


PMW combines SPE and APM activities. By exchanging performance metrics and goals, Dev teams are able to receive information about performance from Ops and vice versa. For instance, Dev teams can use performance information from Ops to enhance performance models. Consequently, they are able to simulate and predict metrics as well as detect bottlenecks more precisely. As a result, performance issues can be eliminated more efficiently. These improved capabilities lead to higher quality Dev deliverables and, thus, support Ops as well. PMW also implies an integration of the three perspectives ''System Lifecycle'', ''System Architecture'' and ''IT-Governance''. PMW activities have to be allocated to organizational units. For that purpose, Information exchange and communication principles have to be established in order to support PMW activities.<ref name="BrunnertVoegele2014"/>
PMW combines SPE and APM activities. By exchanging performance metrics and goals, Dev teams are able to receive information about performance from Ops and vice versa. For instance, Dev teams can use performance information from Ops to enhance performance models. Consequently, they are able to simulate and predict metrics as well as detect bottlenecks more precisely. As a result, performance issues can be eliminated more efficiently. These improved capabilities lead to higher quality Dev deliverables and, thus, support Ops as well. PMW also implies an integration of the three perspectives ''System Lifecycle'', ''System Architecture'' and ''IT-Governance''. PMW activities have to be allocated to organizational units. For that purpose, Information exchange and communication principles have to be established in order to support PMW activities.<ref name="BrunnertVoegele2014"/>