Performance management work: Difference between revisions

Line 12:

== Framework ==

[[File:Performance Management Work.jpg|thumb|Performance Management Work Framework]]

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="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.

@@ Line 12: / Line 12: @@
 == Framework ==
 [[File:Performance Management Work.jpg|thumb|Performance Management Work Framework]]
-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="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.

Performance management work: Difference between revisions

wikipedia>Jokross