Choosing the language and architecture models

The goal of this section is to provide a graphic tool for project managers/technical leaders aimed at deciding the appropriate technologies or architectures depending on the specific needs and features of the software to be developed. The following picture depicts the technical decision tree for software development.

Decision Tree 1

  • 1. What type of application do we want to implement?

  • 2.a. Library: this group includes applications that do not have the capability of self-execution. They are resources needed by another applications.

  • 2.b. Static Web: this group includes web developments but they do not require an application server to run. For example, a web form returns a value depending on a logic that is fully executed in the web browser.

  • 2.c. Dynamic Web: it represents web sites that need an application server to manage requests sent by the front layer.

  • 2.d. Stand-alone Application: they are hosted by the local computer operating system and no server is needed.

  • 2.e. Scripts: utilities developed to automate certain tasks.

  • 2.f. Mobile App: application that will be executed in a SmartPhone or tablet.

  • 2.g. Big Data Algorithm: similar to Script (2.e) and Libraries (2.a) but they are developed to be executed in distributed environments (Hadoop, Spark, Flint, etc.).

  • 2.a.1. One criteria used to select technologies related to libraries is the reusability/interoperability need. In order to maximize library reusability, it is recommended to use JAVA programming language and its WORA (Write Once, Run Anywhere) approach so that the library can executed in different operating systems.

  • 2.a.2. This criteria is showed in different parts of the decision tree. It is used when there is not a clear reason to select one option. In this case it is important to assess the experience of the development team that will implement the component. That’s why C# or JAVA are good options as common programming languages widely used.

  • 2.a.3. Performance is usually linked with C programming language. This language is closer to machine level and that’s the reason its performance is higher than other languages described in the decision tree. C language is a good candidate as long as we talk about pure algorithms. If our library requires access to databases or communication with REST layers, C language can provide good execution time but poor development and maintenance time.

  • 2.a.1.a. Libraries always follow a monolithic architecture. But it is important to take into account that monolithic architectures require special attention to group components and classes with the aim of improving code coherence and design.

  • 2.b.1. Static Webs include two basic components: HTML for web contents and form controls and CSS for content style. “Static” does not mean that the web application cannot have some logic or event management. Static Webs are executed by the web browser and no server is needed to run the logic. This logic is managed by Javascript and related libraries (e.g.: jQuery).

  • 2.b.1.a. Static Webs only use monolithic architecture.

  • 2.c.1. Dynamic Webs can be classified into two groups depending on the type of dynamic content they have. If this content includes private/public sites, workflows, security roles, etc., then we are talking about CMS (Content Management System). If, on the other hand, we have an application that follows a client-server model but with a web frontend, this is a Web App.

  • 2.c.1.a.1. There are many CMS options in the market so the selection of one specific CMS depends on the experience of the development team and the specific features our application requires. For example, if the team has experience with JAVA, some good options could be Liferay, Enonic or Nuxeo.

  • 2.c.1.a.2. If the team has PHP experience, some of the best CMS options are Wordpress, Drupal or Joomla.

  • 2.c.1.b. Web Apps comprise two main components: front and back-end. These components may use different technologies for their implementation.

  • 2.c.1.b.1. If we want to maximize user experience and web responsiveness, the best option is to use the Angular framework to implement the web application. This technology provides automatic synchronization between the model and view components (data-binding) so that users receive a better perception of changes in the web site. PHP does not provide this advance user experience capabilities.

  • 2.c.1.b.2. Another important criteria is the level of scalability we need, that affects the backend layer. One of the easiest mechanism to guarantee scalability is avoiding user sessions. This way user requests always work regardless of the server that attended each request. For example, with two balanced servers, a user login request is received by only one server. If the next request is received by the other server, a token is used on each request to identify the logged user and avoid the creation of a session.

  • 2.c.1.b.3. The backend layer is a set of services that can be invoked remotely. The technologies used to implement these services are JAVA, C# or PHP. Any of these technologies can be used to implement service oriented backend. Therefore, the selection of one particular technology can be made depending on the experience of the development team.

  • 2.c.1.b.1.a. If we are using a communication layer based on XML or JASON where the frontend invokes methods such as getUser(), getInvoice() or sendMail(), we are referring to a SOS-XML architecture. This is a valid architecture but with a heavy communication load because it is based on XML. If we use JSON as the communication element and the type of methods used by client and server are like GET /BOOKS/1, we have SOA-REST architecture. This is the recommended architecture when we do not need to manage peak of users.

  • 2.c.1.b.1.b. Microservices are stateless services, independent and focused on doing small things. These services can be grouped by domains in order to provide complex functionality. Scalability of each domain is defined depending on the expected traffic.

  • 2.c.1.b.1.c. PHP applications are usually designed as monolithic implementations.

  • 2.d.1. The main criteria to select the appropriate technology for stand-alone applications is to know the operating system that will execute the software. Depending on the operating system we have several options.

  • 2.d.1.a. For Windows stand-alone applications the recommendation is to use C# or other .NET technology. In particular, the WPF framework is the best option to implement the presentation layer.

  • 2.d.1.b. For Linux operating system it is recommended to implement stand-alone applications using JAVA programming language. As described in 2.a.1, JAVA is the recommended option when we need interoperability between different operating systems.

  • 2.d.1.b.1. For JAVA based applications, we can use Java FX as GUI toolkit to implement reach interfaces or Eclipse SDK as an IDE to develop other type of applications.

  • 2.d.1.c. For macOS operating system the recommended programming language is Objective-C that provides native apps look&feel.

  • 2.d.1.a.1. The recommended architecture for stand-alone application is 3-tier SOA (presentation, logic and data access).

  • 2.e.1. There are multiple scripting languages depending on the scope of the script. For operating system management tasks the recommendation is Vimscript and BASH. If the tasks require complex logic not provided by the operating system, the best option is Python or Perl (Python is the recommendation due to its wide adoption). If the script is aimed at managing statistical information, then the recommendation is R programming language. Scripts are not complex enough to define an architecture.

  • 2.f.1. There is a key question to decide whether we want a native app or not: if we want to use hardware resources such as GPF, Bluetooth, mic or camera, then the option is to develop a native app using SDKs that allow access to terminal features. Moreover, native apps ensure a better integration with the operating system, look&feel and UX.

  • 2.f.2. If we want to use the application with multiple configurations (several SOs), the development of native apps is more complex because different implementations are needed. The solution is to develop Web apps or Hybrid apps. Web apps are dynamic web apps adapted to terminal’s screen size. New versions of web apps do not require updates by the user. Hybrid apps encapsulate business logic in Webview components and provide enhanced user experience. Both types use HTML, CSS, Javascript, Angular, etc..

  • 2.f.1.a. For native apps, the selection of the development framework is based on the type of the terminal where the app will be deployed: Android SDK (JAVA) for Android apps and Objective-C for iOS apps.

  • 2.f.1.b. HTML5, CSS and Javascript are comon technologies used in Hybrid apps.

  • 2.f.1.c. For Web apps we will use the same technologies as in Dynamic Web (2.c).

  • 2.f.1.a.1. The recommended architecture for mobile apps is SOA. If we need to manage a large number of users, it is recommended to use an architecture based on microservices in order to ensure scalability.

  • 2.g.1. These types of algorithms are coded in Java (or Scala which is 100% Java compatible) and are bundled as libraries.