[ecoop-info] IEEE Software Call for Articles: Special Issue on Architecture Sustainability

[Paris Avgeriou]

IEEE Software Call for Articles: Special Issue on Architecture Sustainability
-----------------------------------------------------------------------------

Submission deadline: April 1, 2013
Publication: November/December 2013

Change is the norm in software, forcing architects to address and
embrace it for the sake of architecture sustainability: the capacity of
the architecture to endure different types of change, through efficient
maintenance and evolution over its entire lifecycle. Sustainability in
this context refers to software systems in their environment, where
environment according to ISO/IEEE 42010 is “context determining the
setting and circumstances of all influences upon a system including
developmental, technological, business, operational, organizational,
political, economic, legal, regulatory, ecological and social
influences.” Architecture sustainability is particularly challenging as
it requires to persistently balance the following factors: evolving
requirements and emergence of new requirements; the intertwining between
requirements and architecture and their mutual refinement; wrong or
sub-optimal architectural design decisions; architectural erosion or
drift; changes in technologies and in the environment where systems
live; changes in business strategies and goals.

Changes in the architecture often do not belong to one or a few phases
of the product or solution lifecycle but to the entire lifecycle. In
addition, some of these changes might only affect local parts of a
system, while others have more systemic impact. Systemic changes might
involve various stakeholders and disciplines. In general, we distinguish
three types of approaches for handling change systematically, listed in
an order of increasing severity:
1. Refactoring. The architecture follows a piecemeal growth, but after
each refinement step, it is subject to architecture analysis, both
qualitative and quantitative. In case of “smells” like dependency cycles
or over-generic design, possible architectural improvements are
identified. These improvements typically happen in a tactical setting.
They change certain components and connectors but not the offered
functionality of the system. Architecture refactoring may also be
applied for opening the architecture for extension or change.
2. Renovating. Sometimes, every several iterations, parts of the
architecture are in such a bad condition that refactoring cannot work
anymore. In such contexts, renovating the architecture – by restoring
its fundamental principles or refreshing essential components – may be
the better choice. Renovating is complementary to refactoring as it also
deals with only parts of the system: refactoring changes these parts
while renovating restores or replaces them.
3. Re-architecting. When an architecture is subject to significant
changes, refactoring or renovating may not suffice. This might be the
case if for example the technology platform is to be replaced by a new
one, if there is a large change in business scope, or if the
architecture is in such a bad shape that errors keep emerging. In such
cases, re-architecting is required. The re-architecting process usually
analyzes the existing architecture (e.g., using a SWOT analysis) and
results in a new architecture by: a) reusing those components worthwhile
to keep, b) modifying some of the existing components (refactoring) and
c) re-building the rest of the components (renovating).

Possible topics include but are not limited to:
• Approaches to achieve architecture sustainability efficiently and
effectively
• State of the art and practice in architecture sustainability
• Concepts, metaphors and models for thinking and reasoning about
architecture sustainability
• Recognizing architectural sustainability problems early by
architecture introspection (performed by the architects themselves) and
assessment (performed by a third party)
• Architecture analysis in support of sustainability
• Fundamental elements of architecture refactoring, re-architecting and
renovating: how they complement each other and when they should (not) be
used
• Ensuring architecture sustainability through architecture governance
• Tools and technologies to support refactoring, renovating,
re-architecting and their governance
• Coping with sustainability concerns through development processes and
roles
• Supporting stakeholders to reason about in which cases they can
refactor, renovate and re-architect
• Architecture sustainability approaches that support reducing or
repaying technical debt
• Existing best practices and patterns for architecture sustainability
• Sustainability through managing traceability between requirements and
architecture decisions
• The effect of architectural drift or erosion on sustainability and
potential counter-measures
• Achieving architecture sustainability in an agile or lean environment
• Architecture sustainability through migration to modern computing
environments (e.g. clouds)
• Measuring architecture sustainability
• Managing the sustainability of product lines comprised of multiple
products that have common and individual changes
• Empirical studies that provide evidence on dealing with architecture
sustainability in practice

Questions?
----------
For more information about the focus, contact the Guest Editors:
• Paris Avgeriou, University of Groningen, The Netherlands: paris at cs.rug.nl
• Michael Stal, Siemens Corporate Technology, Germany:
michael.stal at siemens.com
• Rich Hilliard, software systems architect, USA: r.hilliard at computer.org

Submission Guidelines
---------------------
Manuscripts must not exceed 4,700 words including figures and tables,
which count for 200 words each. Submissions in excess of these limits
may be rejected without refereeing. The articles we deem within the
theme and scope will be peer-reviewed and are subject to editing for
magazine style, clarity, organization, and space. We reserve the right
to edit the title of all submissions. Be sure to include the name of the
theme or special issue you are submitting for.
Articles should have a practical orientation and be written in a style
accessible to practitioners. Overly complex, purely research-oriented or
theoretical treatments are not appropriate. Articles should be novel.
IEEE Software does not republish material published previously in other
venues, including other periodicals and formal conference/workshop
proceedings, whether previous publication was in print or in electronic
form.

For general author guidelines: www.computer.org/software/author.htm
For submission details: software at computer.org
To submit an article: https://mc.manuscriptcentral.com/sw-cs