Performance management work: Difference between revisions
m APerson moved page Draft:Performance Management Work to Performance Management Work: Publishing accepted Articles for creation submission (afch-rewrite 0.8) |
Cleaning up accepted Articles for creation submission (afch-rewrite 0.8) |
||
| Line 1: | Line 1: | ||
'''Performance Management Work''' ('''PMW''') describes all activities that are necessary to ensure that [[IT performance management|performance]] requirements of application systems (AS) can be met. Therefore, PMW integrates software performance engineering (SPE)<ref name="WoodsideFranks2007"/> and application performance management (APM)<ref name="Menasce2002"/> activities. SPE and APM are part of different lifecycle phases of an AS namely [[system development]] and [[IT operations]]. PMW supports a comprehensive coordination of all SPE and APM activities, which is inevitable due to an increased complexity of AS [[Systems architecture|architectures]]<ref name="BrunnertVoegele2014">{{cite journal|last1=Brunnert|first1=Andreas|last2=Vögele|first2=Christian|last3=Danciu|first3=Alexandru|last4=Pfaff|first4=Matthias|last5=Mayer|first5=Manuel|last6=Krcmar|first6=Helmut|title=Performance Management Work|journal=Business & Information Systems Engineering|volume=6|issue=3|pages=177|year=2014|issn=1867-0202|doi=10.1007/s12599-014-0323-7}}</ref>. | '''Performance Management Work''' ('''PMW''') describes all activities that are necessary to ensure that [[IT performance management|performance]] requirements of application systems (AS) can be met. Therefore, PMW integrates software performance engineering (SPE)<ref name="WoodsideFranks2007"/> and application performance management (APM)<ref name="Menasce2002"/> activities. SPE and APM are part of different lifecycle phases of an AS namely [[system development]] and [[IT operations]]. PMW supports a comprehensive coordination of all SPE and APM activities, which is inevitable due to an increased complexity of AS [[Systems architecture|architectures]].<ref name="BrunnertVoegele2014">{{cite journal|last1=Brunnert|first1=Andreas|last2=Vögele|first2=Christian|last3=Danciu|first3=Alexandru|last4=Pfaff|first4=Matthias|last5=Mayer|first5=Manuel|last6=Krcmar|first6=Helmut|title=Performance Management Work|journal=Business & Information Systems Engineering|volume=6|issue=3|pages=177|year=2014|issn=1867-0202|doi=10.1007/s12599-014-0323-7}}</ref>. | ||
The term Performance Management Work was first introduced by Brunnert et al. (2014) in ''Business & Information Systems Engineering''<ref name="BrunnertVoegele2014"/> as well as in the German ''WIRTSCHAFTSINFORMATIK'' <ref name="BrunnertVoegele20142">{{cite journal|last1=Brunnert|first1=Andreas|last2=Vögele|first2=Christian|last3=Danciu|first3=Alexandru|last4=Pfaff|first4=Matthias|last5=Mayer|first5=Manuel|last6=Krcmar|first6=Helmut|title=Performance Management Work|journal=Wirtschaftsinformatik|volume=56|issue=3|pages=197|year=2014|issn=0937-6429|doi=10.1007/s11576-014-0414-6}}</ref> | The term Performance Management Work was first introduced by Brunnert et al. (2014) in ''Business & Information Systems Engineering''<ref name="BrunnertVoegele2014"/> as well as in the German ''WIRTSCHAFTSINFORMATIK'' <ref name="BrunnertVoegele20142">{{cite journal|last1=Brunnert|first1=Andreas|last2=Vögele|first2=Christian|last3=Danciu|first3=Alexandru|last4=Pfaff|first4=Matthias|last5=Mayer|first5=Manuel|last6=Krcmar|first6=Helmut|title=Performance Management Work|journal=Wirtschaftsinformatik|volume=56|issue=3|pages=197|year=2014|issn=0937-6429|doi=10.1007/s11576-014-0414-6}}</ref> | ||
== Context == | == Context == | ||
| Line 14: | Line 14: | ||
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="BrunnertVoegele2014"/><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>. 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="BrunnertVoegele2014"/><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>. 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="BrunnertVoegele2014"/><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>. 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="BrunnertVoegele2014"/><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>. 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"/> | ||
== Capabilities == | == Capabilities == | ||
| Line 24: | Line 24: | ||
{{Reflist}} | {{Reflist}} | ||
<!--- Categories ---> | |||
[[Category:Performance_management]] | [[Category:Performance_management]] | ||