Changes

         </th>

         </th>

       </tr>

       </tr>

       <tr><td colspan="2" class="logo">[[File:Low_Code_Application_Development_logo.png|200px]]</td></tr>

       <tr><td colspan="2" class="logo">[[File:Technology_Trends_-_Low_Code_Application_Development_logo.png|200px]]</td></tr>

       <tr>

       <tr>

         <th>Status</th>

         <th>Status</th>

   </ol>

   </ol>

   <p>Websites of the low-code tool leaders typically provide reference customers, and these include numerous prominent banks, insurance companies, airlines, government departments, and the US Army – though in most cases no details are given about the precise application domain. Most of the analysts’ reports, as well as self-reporting by OutSystems and Mendix, indicate that 88% of companies are adopting low-code, while 74% of those companies are integrating the business side into low-code development, thereby directly involving the clients who dictate the requirements .</p>

   <p class="inline">Websites of the low-code tool leaders typically provide reference customers, and these include numerous prominent banks, insurance companies, airlines, government departments, and the US Army – though in most cases no details are given about the precise application domain. Most of the analysts’ reports, as well as self-reporting by OutSystems and Mendix, indicate that 88% of companies are adopting low-code, while 74% of those companies are integrating the business side into low-code development, thereby directly involving the clients who dictate the requirements.</p><p class="highlighted inline mw-collapsible-content"> ([https://www.mendix.com/why-developers-should-embrace-low-code/ Example])</p>

   <div class="container">

   <div class="container">

     <li>Most organizations experience some pushback from traditional developers, partly due to skepticism, though often due to defensiveness as more (and cheaper) people become “developers.”</li>

     <li>Most organizations experience some pushback from traditional developers, partly due to skepticism, though often due to defensiveness as more (and cheaper) people become “developers.”</li>

     <li>Most traditional development environments involve a one-off purchase of the IDE, however, low-code licenses are considerably more complex, often involving per-deployed-app costs. Those costs are sometimes opaque and need to be fully worked through for the ROI analysis.</li>

     <li>Most traditional development environments involve a one-off purchase of the IDE, however, low-code licenses are considerably more complex, often involving per-deployed-app costs. Those costs are sometimes opaque and need to be fully worked through for the ROI analysis.</li>

     <li>There are several low-code systems to choose from, though the current leaders (which include Mendix, Microsoft and OutSystems) have consistently been ahead of the pack . Which platforms to choose is a challenge that depends heavily on legacy software to be supported, existing deployment platforms, etc. Supporting more than one low-code platform will bring its own challenges.</li>

     <li>There are several low-code systems to choose from, though the current leaders (which include Mendix, Microsoft and OutSystems) have consistently been ahead of the pack</p><p class="highlighted inline mw-collapsible-content"> (That is not quite true for Microsoft, which is relatively new to low-code, though their development environments and general platforms are very mature and strategic.)</p><p class="inline">. Which platforms to choose is a challenge that depends heavily on legacy software to be supported, existing deployment platforms, etc. Supporting more than one low-code platform will bring its own challenges.</li>

     <li>The proprietary nature of low-code gives a certain level of “lock-in,” preventing SSC from changing vendor or leaving low-code altogether. Vendors usually portray low-code as having no lock-in because C# or Java code is generated, which may be maintained further without low-code. In practice, this is not true for large apps.</li>

     <li>The proprietary nature of low-code gives a certain level of “lock-in,” preventing SSC from changing vendor or leaving low-code altogether. Vendors usually portray low-code as having no lock-in because C# or Java code is generated, which may be maintained further without low-code. In practice, this is not true for large apps.</li>

     <li>Low-code’s ease (“democratization”) of app development can cause problems for SSC: clients will be tempted to develop on their own if SSC is not fast enough, thereby creating a shadow IT (hidden/skunk works) mentality. If allowed to grow, this will create maintenance issues as well as an existential problem for SSC.</li>

     <li>Low-code’s ease (“democratization”) of app development can cause problems for SSC: clients will be tempted to develop on their own if SSC is not fast enough, thereby creating a shadow IT (hidden/skunk works) mentality. If allowed to grow, this will create maintenance issues as well as an existential problem for SSC.</li>

   <p>SSC should consider a low-code trial for several reasons: gaining exposure, evaluating low-code tools, and quantifying the ROI (at least for one project). Ideally, all of the leading low-code systems should be evaluated – though the field may be thinned (e.g. to Microsoft PowerApps or OutSystems) based on breadth of the system as well as the match to existing technologies in-use by SSC. During the trial, several aspects should be measured: training cost (which is then translated to amortized training costs as they would be across several projects), amortized licensing costs, elapsed time, client satisfaction, and amortized maintenance costs.</p>

   <p>SSC should consider a low-code trial for several reasons: gaining exposure, evaluating low-code tools, and quantifying the ROI (at least for one project). Ideally, all of the leading low-code systems should be evaluated – though the field may be thinned (e.g. to Microsoft PowerApps or OutSystems) based on breadth of the system as well as the match to existing technologies in-use by SSC. During the trial, several aspects should be measured: training cost (which is then translated to amortized training costs as they would be across several projects), amortized licensing costs, elapsed time, client satisfaction, and amortized maintenance costs.</p>

</div>

</div>