Architectural Mismatch

This is a paper review/reading log that I did for one of my specialization courses, SWARM(Software architecture recovery and modelling ).
The paper is about architectural erosion, and Its authored by Dave garlan,Robert Allen, and John Ockerbloom all of whom are from the Computer Science Dept of Carnegie mellon university, a school I respect.

The paper is just about how the assumptions we make about software components, affect the way they connect/fit to each other when we are trying to use them in building a large software system.
So below are the contents of my reading log, enjoy.......oh strange user.

Note: In every paper we read, we are meant to look into the feasibility of applying the technique to a "real-life" case study, in this case the migration of a monolithic blob of software for a television , to a linux platform....

Reading log for "Architectural mismatch" paper
----------------------------------------------

The authors main points:
-----------------------

The author points out that in software engineering, most people expect that in order to build a software system,
we should do so from building blocks. But the error in that is that most components are built based on assumptions about
the environement in which they will operate. These cause issues in the way the components fit together, and is known as
architectural mismatch.
The author goes on to highlight the main causes of architectural mismatch as follows:

1.Assumptions about the nature of the components

2.Assumptions about the nature of the connectors


3.Assumptions about the global architectural structure

4.Assumptions about the construction process.


The author suggests that careful consideration should go into building components that are intended to be used for
larger systems, but in my opinion, that is difficult to predict.

The author states four necessary aspects neccessary for a long-term solution

1. Make architectural assumptions explicit

2. Construct large pieces of software using orthogonal sub-components

3. Provide techniques for bridling mismatches

4. Developing sources of design guidance



Points I agree with
-------------------

1. I agree with the authors statement of causes of architectural erosion

2. I agree that ideally, when building components, they should be built with a view to being integrated
into a larger system

3 I also agree with the authors aspects for long term solutions to architectural mismatch.


Points I disagree with
----------------------

It isnt possible to predict which component would be used as a building block for a larger system.
I would imagine that building them the way the author suggests might lead to making the component very generic,
and as a result, eroding some of the functionality of the component.


Application to TV case
----------------------
Since the paper deals with systems built from components, and the tv case is simply one of migration to a new system and
doing some stripping down of the monolithic blob to the bare essentials, I have my doubts as to the
applicability of this to our case. The only thing i can think of is that maybe when we might decide to add extra functionality to the
ported system (in terms of new functional requirements), that we take the warning (about architectural erosion) into consideration.