analyzing architectural mismatches based on the 2 papers: Architectural Mismatch: Why Reuse Is Still So Hard By David and his colleagues

1. Faculty of Engineeeing and Technology
Master in Software Engineering Program
Software Design and Architecutre
First Quiz
Architectural Mismatches
Prepared by
Mohammad Shawahneh
1155294
Instructor
Dr. Yousef Hassouneh

2. How are the Architectural Mismatches being solved? and what are the new challenges.
According to David and his colleagues, all the architectural mismatches they described in the original paper in 1995
are still persist, and none is solved completely, but they described three basic techniques which are being used for
dealing with mismatches nowadays, and they think that these techniques contributed somehow to addressing
some parts or kinds of mismatches but did not solve it:
1. Preventing Architectural mismatches: this technique arise as a result of some other development areas
and benefited from different areas:
a. Architectural specialization: dealing with “narrower design context” and building a specialized
architectural design, like specializing pipe and filter, and specializing components and
connectors such as data flow, call returns and implicit invocation, the era of specialization can
be seen as an increasing of those items from left to right: generic styles, generic styles
specializations, generic component integration standards, domain-specific component
integration standards, and product lines.
b. Open source: Open source software product and components that are developed by
communities can help preventing mismatches in two ways: providing and building standards for
specialized frameworks and architectural styles and producing experiences and example usages
which provide concrete samples about architectural assumptions and how to deal with it and
address it directly and easily.
c. Visualization and common user interfaces: “High level communication protocols and data
standards, common languages and browser environment”, all that made the situation easier for
providing software of little need to dependencies on infrastructure and platforms.
This development techniques did not eliminate the mismatches according to David and his
colleagues even it contributed to that in some area or views, but it added some other complexities
of browser compatibility, languages and implementations
2. Detecting Architectural mismatch: this techniques appears and benefited from different developments
and improved areas in software development:
a. Documentation standards: documentation standards introduced common languages and
protocols which almost all world developers and software engineers are familiar with that and
can easily understand it quickly, now world has guidelines and standards for documenting
architectures, designs assumptions..etc, UML is a common widely known example which is used
for modeling, WSDL (Web Services Definition Language) is another example for Service-Oriented
architectures documentation. The problem of this technique that it is not widely used and many
frameworks and components and services don’t provide it will or in right way expressing the
right architectures, that leads to other mismatches.
b. Process guidelines: the modern software development processes are almost all depend on
iterative programing, that going spiral, and using kinds of prototyping techniques or cumulative
punches of features that being accepted and inserted successively to the main product, this
enables architects and software engineers to detect mismatches and address them early in the

3. software lifecycle, but this still not of high value due to inexistence of early diagnostic or
corrective automations, and it depends on skills of architects and software engineers.
3. Repairing Architectural Mismatches: if all techniques did not prevent failing in mismatches then no way
but to address them and repair them, modern techniques for that included different mechanisms like:
wrappers , adapters, mediators, and bridges. Also some frameworks provide mechanisms for integrating
legacy and old systems and components. Those techniques decreases the mismatches but did not
contribute much to eliminating mismatches and always according to authors.
New Challenges arise:
1. Trust: the security is a big challenge that arise, in the era of internet, security or trust is another big
challenge that every software need to worry about and exert much effort, and budget for considering it in
all software lifecycle, and this will contradict with other quality attributes, like performance, cost,
development time..etc.
2. Dynamism: modern software need to be dynamic as it needs to be easily reconfigurable or adaptive for
changing user needs, variable resources and environment like appearing of cloud, that can lead to more
complexity and more mismatches, thus need new ways to address those mismatches and then solve
them.
3. Architectural evolution: modern software evolve over its lifecycle, some studies shows that more than
60% of software life cycle goes for evolution, evolution leads to new architectural mismatches and
challenges, that means new components, connectors, dependencies are need to be introduced on an
existing software and the software should still functioning well, but the reality that this process can lead
to architectural mismatches and complexities.
4. Architecture Lock-In: this issue appears when the software change or update is of high cost or in need of
rebuild from scratch so as to do some updates or changes, that appeared when some software tried to go
for cloud for example, resulted in a high cost architectural mismatches, or when need for changing
provider.