Green IT Amsterdam Region and the Software Improvement Group (SIG) organized the first workshop of the Green Software Community, with as theme 'Green Software Architecture'. For more information, please visit www.greenitamsterdam.nl/greensoftwarecommunity/ This is a presentation by Joost Visser / SIG on what can be green about software

1. What could be green about software?
Software Architecture & Optimisation of IT Energy-Efficiency
Joost Visser
June 2011 T +31 20 314 0950
info@sig.eu
www.sig.eu

2. This presentation
2 I 10
Software Improvement Group
• Background, activities
Greenness and Software
• Does software consume energy?
• Green aspects of software – a taxonomy
Greenness and Software Architecture
• Is greenness of concern to the Software Architect?
• Some directions
© 2011 Software Improvement Group

3. Software Improvement Group
Background 3 I 10
• Spin-off from CWI in 2000, self-owned, independent
• Strong academic background, innovative, award-winning, profitable
• Member of the consortium Green IT Amsterdam region
Activity
• Management advisory, fact-based
• Accredited software analysis lab employs analysis tools and models
• Experienced staff transforms analysis data into advice
Track record
• Finance, government, logistics, telecom, manufacturing, energy, …
• We analyze over 100 systems annually
© 2011 Software Improvement Group

4. Selected services
4 I 10
Software Risk Assessment
• In-depth investigation of software quality and risks
• Answers specific research questions
Software Monitoring
• Continuous measurement, feedback, and decision support
• Guard quality from start to finish
Software Product Certification
• Five levels of technical quality
• Evaluation by SIG, certification by TÜV Informationstechnik
Sustainability Scans
• Energy-efficiency at the application level
• Identify opportunities for optimisation
© 2011 Software Improvement Group

5. Taxonomy
5 I 10
Data retention
Greening by IT Responsiveness
Graphical presentation
Green Grid
Green Data Center Algorithmic
Green IT Green Hardware Data structures
Protocols
Functional necessity
Greening of IT
Computational efficiency
Green Software
Environment
Green Software
Rework
Development
Maintainability
Testability
© 2011 Software Improvement Group

6. Power Loss Chain
Extended version …
6 I 10
Image source:
Performing the right work?
British Computer Society
Data Centre Specialist Group
Performing the work right?
Algorithmic inefficiency
Computational 25% 75% Optimal cycles and storage
efficiency
Functional Frivolous features
65% 35% Useful work
necessity
Percentages are indicative only
© 2011 Software Improvement Group

7. Application-level energy-efficiency
7 I 10
Why?
• On the level of hardware, network, and data centre progress has been made.
• Window for optimisation is shrinking.
• Focussed on reducing energy loss in the power supply chain.
• HW, NW, DC consume energy on behalf of application software.
• Software design and construction are currently mostly energy-oblivious.
• Focus on reducing energy demand at the source.
But how?
• Role for the software architect?
© 2011 Software Improvement Group

8. Software Architecture
8 I 10
Definition
“The architecture is the primary carrier of system qualities, such as performance,
modifiability, and security, none of which can be achieved without a unifying architectural
vision”, Software Engineering Institute (SEI)
Responsibilities of the Software Architect
• Define structure: components, relationships, constraints, style
• Make technology choices
• Balance stakeholder needs
• Take, record, communicate high-level design decisions
• Provide guidance throughout the software process
Software Architecture & energy efficiency
• Energy-efficient software is enabled or precluded by architectural choices
© 2010 Software Improvement Group

9. Architectural trade-offs
9 I 10
Energy efficiency versus functionality
• Non-essential features may lead to energy waste
• E.g.: continuous client-side reporting of server status
• E.g.: check spelling as you type, wizards (remember Clippy?)
Energy efficiency versus performance
• Optimising for performance is not necessarily energy-efficient
• E.g.: guaranteed response times may require over-dimensioned hardware
Energy efficiency versus reuse and adaptability
• E.g.: Packaged solution may not allow application-specific optimisation
• E.g.: Loose coupling via web services may increase communication overhead
© 2011 Software Improvement Group

10. Questions and challenges
10 I 10
How to integrate sustainability requirements?
• How to elicit?
• How to determine their impact?
• How to trade them off against functionality, maintainability, etc
How to prepare for future developments in hardware, data center, grid?
• Optimize for current infrastructure?
• Optimize for adaptability to future infrastructure?
How to ensure that sustainability decisions survive into implementation?
• How to enable developers, operators to judge whether the systems (still) fulfils
sustainability constraints?
© 2011 Software Improvement Group

11. 11 I 10
Dr. ir. Joost Visser
j.visser@sig.eu
http://twitter.com/jstvssr
www.sig.eu
+31 20 314 0950
© 2011 Software Improvement Group