Session:Software Architecture: The Next Generation--Discussions

From WICSA Conference Wiki

Please use this page to capture ideas, thoughts, reactions, opinions and so on about the content of this working session.

Attendees

Please add yourself to this list. Tell us something about your background. Add to the Discussions questions section below a few sentences about the working session topic such as your position and questions you would like to see discussed.

1. Paul Clements, SEI - moderator.
2. Rod Nord, SEI.
3. Dan Paulish, Siemens Corporate Research (USA)
4. N. Swaminathan, Business Systems and Cybernetics Centre, Tata Consultancy Services
5. Bhudeb Chakravarti, National Institute of Smart Government & IIIT, Hyderabad.
6. Patricia Lago, Vrije Universiteit Amsterdam (NL)

Key ideas

(key ideas, how papers relate to each other and support the session theme)

Organized by members of the IFIP Working Group 2.10 on Software Architecture

Software architecture is the principled understanding of the large-scale structures of software systems. As a field of study, software architecture overlaps and interacts with the study of software families, domain-specific design, component based reuse, software design, specific classes of components, and program analysis [1].

Since the beginning of the field we now know (roughly the mid-1980s, although its roots can be traced to earlier concepts), software architecture has largely been concerned with engineering and understanding the interaction of well-defined components over well-defined communication paths via well-defined interfaces. However, a much different world seems to be dawning. Systems are built from components designed and produced by organizations completely independent of each other. The components may or may not have well defined interfaces. The functionality and quality attributes of the total system may be derived from (rather than engineered into) the federation of components. The components and their interrelationships may change dynamically, arriving and departing either bidden or unbidden, and connecting to the part of the system where they will do the most good. “Time to market” will become replaced by “time to useful functionality” and will be measured in seconds rather than months.

What will be the role of architecture in that brave new world? What will be the role of the architect? It seems clear that the current architectural paradigm, focusing on the components and connections that make up a large-scale software system, will not suffice, and will need to be replaced with something quite different. Nevertheless, even, perhaps especially, highly dynamic systems need to be based on architectural principles that facilitate or guarantee system properties, thus the need for software architectural thinking remains.

We propose a working session that seeks two goals:

• First, to lay out certain dimensions of the problem space that we assume now, but which may well vanish in the next ten years.
• Second, to define a broad picture of the practice of software architecture in the most demanding part of that new problem space.

Reference

1. Shaw, Clements, “The Golden Age of Software Architecture,” IEEE Software, Mar/Apr 2006.

Discussion questions

1. Can we lay out "dimensions" of the architecture world that have scales that go from very "now" to very "future"? For example, one dimension might be "how sure are you what components will populate your system?" For the "now," we're very sure. For the "future," we might have no idea.

2. What will the role of the architect be in the future world we're envisioning?

Discussions

SESSION SUMMARY

Our session was devoted to trying to "lay out the space" of the practice of software architecture. The purpose was to try to define a "We are here" point in that space, and to try to define a point in the same space where the field might be in x years. We went about this by a brainstorming session in which participants suggested a dimension of the space, and what it means to be at the most primitive point along that dimension (which we arbitrariy labelled "0") and what it means to be at the advance point possible in that dimension (which we arbitrarily labelled "10").

Later, we went back and postulated where the state of the practice is now in each of the dimensions, and what it would take to move it to the "10" state. We did this for the first few, before time expired.

Here are the dimensions of the space of architecture that our group (some 22 participants) created:

1. Codification and Socialization – Processes by which an Architect communicates architectural ideas to the stakeholder community. Codification refers to specification of the architecture, while socialization refers to the less formal processes by which the architecture is internalized. Socialization can happen through conversation, training, etc. Socialization and codification are complementary processes; they should enforce each other. a. 0 – No codification and Socialization b. 10 – Soc. And Cod. are in balance with each other; Soc. = A process for Cod.; Soc and Cod – enforce each other and work in a global environment

Where are we now – Not explicitly integrated. Sometimes Soc. is not consciously done. Archi tools do not focus on solving these probs. Soc tools do not focus on Archi Where do we like to be and what do we have to do for that? – We like to be in state 10. More research on the integration. More integration tools reqd. Cost – benefit analysis – empirical studies available

2. Handling Quality attributes a. 0 – No consensus about quality attributes b. 10 – Quality attributes linked to Business and Eng needs and quantitatively specified and there is a consensus c. Traceability – Req by reference Where are we now – It is emerging. All ‘lities’ are not yet quantitatively available Where do we like to be and what do we have to do for that? a. Design for ‘lities’ rather than ‘plugin’ in them later. b. Independent certification of quality standards/attributes for 3rd party platforms. c. Better understanding of domain quality attributes and ways to achieve them - tradeoffs d. Popularize analysis for quality attributes. e. Frame the Architect job as demonstrating achievement of quality attributes. f. Define and tune quality attribute profiles g. Traceability for quality attribute h. Make specification/analysis quality attributes mandatory i. Better way to specify QA/bounds

3. Architectural Automation a. 0 – Human language on paper b. 10 – Language for architecture is the base language for automation

Where are we now – 0.5 UMLs, diagrams and words Where do we like to be and what do we have to do for that? Building blocks with defined quality attributes Domain specific architecture – there are close to 50 diff archi specification languages.

4. architectural specificity a. 0 – Reasoning about specific elements(h/w, network, s/w..) and the relationships are known by the architect b. 10 – Reason about guidelines, constraints, quality attributes – self adaptive systems

5. Architectural responsibility – Degree to which an architect is responsible a. 0 – No explicit recognition, b. 10 – A clear definition of responsibility and authority of an Architect’s role. Responsibility – Sufficient to deliver function and Quality attributes of the system to its stakeholders over time c. Worst – Having responsibility and no authority

6. Accidental Vs intentional architects a. 0 – No explicit training, No career path, No formal explicit recognition, No experience (relating problems to domain, Development, implementation, failed, organization, ..) threshold b. 10 – Architect is chosen intentionally for his/her ability

7. Domain versatility and adaptability a. 0 – One track mind b. 10 – Pragmatic and inquiring – Ability to organize information 8. Architecting process – Maturity of Architectural choices 0 – Diversity of soln and techniques – Arbitrary choice 10 – Clear linkage b/n architecture goals – choice of process and techniques

9. Technology dependency – (Technology is a tool) 0- Architecture is constrained by the existing technology 10 – Fearless architecture ; Specify the abstract solution without necessarily any bindings to existing Technology – Architecture not constrained by existing tech. Fearless is one which might influence future technology

9. Creating Vs Choosing an Architecture a. 0 – No previous solns reused b. 10 – modulo details that soln already exists – Looking previous solns and reusing them

10. – Complexity a. 0 – Low complexity b. 10 – Producing architecture for Complicated and Complex systems with emergent behavior.

11. Inter-disciplinary Architecture a. 0 – Single discipline fully understood. (Information architecture, Enterprise archi some of the e.gs of disciplines) b. 10 – Multiple disciplines fully integrated. Stakeholders’ perspectives are met.