<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>ADA: Embracing technology change acceleration</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Ondrej Dvorak</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Robert Pergl</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Petr Kroha</string-name>
          <email>petr.krohag@fit.cvut.cz</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Czech Technical University in Prague, Faculty of Information Technology</institution>
          ,
          <country country="CZ">Czech Republic</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>The pace of technology change has accelerated in the past decade. Conceptually similar technologies are introduced on nearly a daily basis. On one hand, IT experts call for applying the most modern approaches and technologies to software projects, on the other, companies su er from liabilities to a technology used in their legacy solutions. This seems to result in a disturbing situation when a speci c technology of an ongoing software project becomes legacy almost before the project successfully hits a production. This poses a continual challenge for software development, and e ective ways of technology transition are sought. A ordance-Driven Assembling (ADA) represents such an e ort from the standpoint of enterprise engineering theories. In this paper, we formulate a high-level architecture of a software system based on ADA. We demonstrate the architecture on an example of an object-oriented system. We evaluate the qualities of such architecture from the perspective of evolvability using Normalized Systems Theory, and we formulate conclusions on potential of this approach.</p>
      </abstract>
      <kwd-group>
        <kwd>component-based systems</kwd>
        <kwd>semantic descriptions</kwd>
        <kwd>software architecture</kwd>
        <kwd>EE theories</kwd>
        <kwd>ADA</kwd>
        <kwd>O-ADA</kwd>
        <kwd>design patterns</kwd>
        <kwd>evolvability</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>In the past decades, a range of new software technologies and frameworks have
been developed to provide various solutions to software development challenges.
For instance, we can nd tens of frameworks and libraries for Dependency
Injection, Object-Relational-Mapping, Service-Bus, we can dabble with hundreds of
User Interface (UI) technologies, or rummage thousands of controls in JavaScript.
Although there are considerable di erences among them, many of them address
the same class of problems. At the same time, it feels like the pace at which
these frameworks are introduced is accelerating.</p>
      <p>
        We commonly refer to the famous Moore's Law which observes this
phenomenon in computing. This widely known exponential doubling of transistors is
powering the advances in the past ve decades. However, it seems there is a
similar common force driving information technology forward. In [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ], Ray Kurzweil
introduces the so-called Law of Accelerating Returns which shows that the
technological change is exponential, as well, and every decade the overall rate of
progress is doubling [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]. He demonstrates that: \We wont experience 100 years
of progress in the 21st century it will be more like 20,000 years of progress (at
todays rate)" [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ].
      </p>
      <p>
        If Kurwzeil is right, we can expect that more and more frameworks and
libraries will be introduced even quicker. This brings a serious problem to deal
with legacy software, i.e., software which has been developed using already
outdated technology. Due to the technology pace, the software systems can thus
become legacy almost before hitting a production { as the pace of
development technology increases, so too does the pace of technology obsolescence [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ].
Therefore, the software industry must address this problem of adopting to new
technologies quickly. Otherwise, it will be much earlier facing the painful issues
when maintaining legacy software, e.g., lack of IT resources, lack of skilled man
power, lack of up-to-date documentation, costly to support and maintain [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ].
This problem is even worsen with the evidence showing that companies already
spend most of their available budgets on maintenance [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
      </p>
      <p>
        In this paper, we focus on technologies used for UI development where the
problem of a technology transition is arguably the most observable in the
proliferation and dynamics of UI frameworks. For instance, the JavaScript community
coined a term the \JavaScript fatigue". Regardless the progress and popularity
of JavaScript, developers report that they are dealing with a fatigue which refers
to an inability to keep up with the latest libraries, there is a fear of becoming
obsolete and outdated due to a constant change of the ecosystem and an
overwhelming number of choices [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ].
      </p>
      <p>
        We argue that by following certain architectural patterns in a software
system, we can adapt software artefacts to the latest technologies more e ciently.
In this paper, we elaborate on the ADA (A ordance-Driven Assembling)
approach that is founded in formal EE (enterprise engineering) theories. In [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], we
introduced the way of thinking about software systems aligned with EE theories
lens, in this paper we elaborate on this and show how a way of working looks in
ADA to demonstrate the desired bene ts of easing the technology transition.
2
      </p>
    </sec>
    <sec id="sec-2">
      <title>Evolvability and Formal Foundations</title>
      <p>
        To measure an improvement in helping technology transition, we work with
the term \evolvability". We understand \evolvability" in terms of Normalized
Systems Theory (NST) [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ] that explains it as the \ability for software to be
easily changed" [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. In our research, the \technology change" is a so-called NST
change driver. We measure it from a perspective of combinatorial e ects. Thus,
the main criterion used to evaluate the quality of a certain software architecture
is a bounded impact of the technology transition.
      </p>
      <p>
        When migrating a software from one technology to another, we su er from
incompatibilities between them. In practice, we usually tackle the problem of
moving to another framework, or library based on the same platform or language,
e.g., .NET, Java, C++, JavaScript. Thus, we typically identify parts which can
be left untouched while the rest is adopted to the new technology. This rises a
question of what are the concepts that can be easily reused, and which make it
harder to move. Additionally, in which way we have to capture these concepts
in a software system in order to optimize it for future upgrades. In [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], it was
shown that such concepts can be found in Enterprise Engineering (EE) -theory
and -theory [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ].
3
      </p>
    </sec>
    <sec id="sec-3">
      <title>A ordance-Driven Assembling</title>
      <p>
        In [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], it was clari ed that the concept of EE theories can be observed in
Software Engineering (SE) as well. It was shown that software systems founded in
these theories must be composed of components that suit the needs of a given
user with a speci c purpose. This relationship between users with purposes and
components with properties can be captured by the term a ordance:
De nition 1. A ordance is a user-component relationship, which can be
represented by the following formula:
a ordance: (user * purpose) * (component * properties).
      </p>
      <p>
        When building software systems based on this de nition, we must be able
to identify so-called ADA-users, describe their ADA-purposes, and based on
that build the nal solution composed of ADA-components. All of these ADA
artifacts are formally de ned in [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. Fig. 1 depicts basic high-level components
and their relations in an ADA component-based system.
      </p>
    </sec>
    <sec id="sec-4">
      <title>Case Study: Evaluating ADA in Practice { corima</title>
      <p>The COPS company has implemented an application framework corima. It is
an example of ADA in practice. The system corima is capable of hosting
applications in various business domains1. By now, the biggest application suite is
focused on banking and corporate treasury management. It encompasses around 50
1 Under the business domain, we understand the area of a business, e.g., nance,
health-care, etc.
data-centric web and desktop applications used across tens of customers mainly
in Europe.</p>
      <p>The system corima implements ADA concepts captured in Fig. 1. We
evaluated its code-base in order to measure the impact of a technology or domain
transition.</p>
      <p>Our preliminary calculations show that if the change-driver is a technology
(e.g., a move to another UI framework), the impact of such a change is bounded.
We only need to change a code which corresponds to the Mapper and Component
Repository in Fig. 1. This only makes 2.2% of the entire code-base.</p>
      <p>On the other hand, if the change driver is in the domain. The adjustment of
Purpose and User repository is bounded to 1.7% of the whole code-base and
it won't change with the amount of new applications.
5</p>
    </sec>
    <sec id="sec-5">
      <title>Conclusion and Future Work</title>
      <p>In this paper, we started by observing that the pace of introducing new
technologies is exponentially accelerating, posing a serious challenge for the software
industry with systems becoming quickly legacy ones much sooner. We addressed
this challenge by showing how ADA can ease technology transitions.</p>
      <p>We formulated a possible high-level architecture for software systems
following ADA and demonstrated it on a case study of a real system. Using NST,
we evaluated that ADA improves the evolvability of software in situations of
technological transitions by putting clear boundaries of change impact.</p>
      <p>Although our measurements indicated the potential of ADA, further
statistical evaluation on a large number of cases is as subject of a future work.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Alija</surname>
          </string-name>
          , N.:
          <source>Justi cation of software maintenance costs 7</source>
          , 15{
          <volume>23</volume>
          (03
          <year>2017</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Clemmons</surname>
          </string-name>
          , E.:
          <article-title>Javascript fatigue</article-title>
          . https://medium.com/@ericclemmons/javascriptfatigue-48d4011b6fc4 (
          <year>2018</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Dietz</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hoogervorst</surname>
          </string-name>
          , J.: Theories in Enterprise Engineering Memorandum - TAO, BETA
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Dvorak</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pergl</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kroha</surname>
            ,
            <given-names>P.:</given-names>
          </string-name>
          <article-title>A ordance-driven software assembling</article-title>
          . In: Enterprise Engineering Working Conference. pp.
          <volume>39</volume>
          {
          <fpage>54</fpage>
          . Springer (
          <year>2018</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Kurzweil</surname>
            ,
            <given-names>R.:</given-names>
          </string-name>
          <article-title>The law of accelerating returns</article-title>
          . In: Alan Turing:
          <article-title>Life and legacy of a great thinker</article-title>
          , pp.
          <volume>381</volume>
          {
          <fpage>416</fpage>
          . Springer (
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Mannaert</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Verelst</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          , De Bruyn,
          <string-name>
            <surname>P.</surname>
          </string-name>
          :
          <article-title>Normalized Systems Theory, From Foundations for Evolvable Software Towards a General Theory for Evolvable Design. Normalized Systems Institute (</article-title>
          <year>2016</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Oorts</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Huysmans</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>De Bruyn</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mannaert</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Verelst</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Oost</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Building evolvable software using normalized systems theory: A case study</article-title>
          .
          <source>In: 2014 47th Hawaii International Conference on System Sciences</source>
          . pp.
          <volume>4760</volume>
          {
          <fpage>4769</fpage>
          .
          <string-name>
            <surname>IEEE</surname>
          </string-name>
          (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Seacord</surname>
            ,
            <given-names>R.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Plakosh</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lewis</surname>
            ,
            <given-names>G.A.</given-names>
          </string-name>
          :
          <article-title>Modernizing legacy systems: software technologies, engineering processes, and business practices</article-title>
          . Addison-Wesley
          <string-name>
            <surname>Professional</surname>
          </string-name>
          (
          <year>2003</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Srinivas</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ramakrishna</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rao</surname>
            ,
            <given-names>K.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Babu</surname>
            ,
            <given-names>E.S.:</given-names>
          </string-name>
          <article-title>Analysis of legacy system in software application development: A comparative survey</article-title>
          .
          <source>International Journal of Electrical &amp; Computer Engineering (2088-8708) 6</source>
          (
          <issue>1</issue>
          ) (
          <year>2016</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>