Abstract

Maintainability is the highest cost component of computer software. This article will be of interest to those IT professionals responsible for software development budgets.

An enterprise can deploy a 2nd Generation Maintainable architecture into their app development projects to avoid the need to set up a separate app development team, significantly reducing the lifetime costs of their app(s) and reducing demands to engage specialist app development resources.

What is 1st Generation Maintainability?

To address these issues it is important to architect your app(s) for resource segregation so that you can utilise existing resources to enhance and maintain your system rather than rely on specialist resources. This is called 2nd Generation Maintainability.

What 2nd Generation is not

Your organisation will have done its investigation into the tools and techniques for developing apps, coming up with recommendations of what is going to work within the culture and skills of your organisation.

As a minimum you will choose the MVVM design pattern for your user interface layer[1] and most probably you will be using Visual Studio as your development platform, but apart from that everything else will be organisational specific. There are components that are common choices like using a REST interface [2], a local SQLite database [3], Newtonsoft Json [4], Forms for cross platform user interface [5], Unity for your IoC container [6], and a third party MVVM framework [7], and building to a Portable Class Library [8].

These are site specific and are independent of being 2nd generation maintainable.

Secondly, you don’t want to over-engineer your app. It needs to be kept simple so that it is easy to understand, easy to change and hence easy to maintain. Note that many of the concepts that are used regularly within your server systems may not be appropriate for an app.

2nd Generation Maintainability

Object Oriented Analysis and Design (OOAD) is a concept developed by Grady Booch, Ivar Rumbaugh and James Jacobson around 1995 [10]. Whereas we use Object Oriented Programming to build our systems, we most often do so without OOAD. The distinction is subtle but critical.

By analysing your application in terms of the real world object (invoice, quotes, credit cards) as distinct from using inheritance, polymorphism and encapsulation to manage the technical complexities within our applications, the technical app specific issues naturally get pushed lower in your architecture.

For example, an Invoice “knows” about itself, so not only does it know about its properties (it knows that its total amount is the sum of its invoice line amounts) and about its business behaviour (it knows how to create itself from a quote), it also knows how to persist itself, and a part of persistence is whether it is in sync with the server.

A simple example and a simple concept, but when coupled with three-tier and MVVM you will find that it frees your application developers from having to understand many of the core technical issues that any app should deal with, significantly simplifying maintenance.

Model-View-ViewModel (MVVM) is a more recent concept developed by Microsoft in 2005 as part of their WPF and Silverlight projects [11]. The key benefit of the MVVM for mobile app development is solving the problem of decoupling the user interface for the plethora of physical devices and their varying screen sizes and resolutions, from the business logic that they will be populated from.

It is not just the ‘binding’ technology that comes with MVVM that is important, it is also important to separate out as much as possible which business logic is important for front end resources, and which business logic is important for your application developers.

Resource Separation

The frontend developers will only be concerned with the business logic related to the user interface. The application developer will work with the frontend developers to ensure the right data is captured in the right sequence and that the process for updating the invoice is correct. Neither will have changed or have any concern with how the data is transferred to the server, and hence they should not need to see the technical code or understand it.

This is just one example of why ensuring app specific technical complexities are removed from the business layer is important.

Technical developers
From time to time new device specific technology becomes available. Some may be new features such as a 3D camera or new industry specific image recognition software, and some may be changes to existing technologies like replacing our incredibly slow http technology or the introduction of a new NonSQL database replacing SQLite.

Implementing new technologies is a specialist skill. You may have these skills within your organisation, but equally you may choose not to and contract them in when required. If your architecture has an appropriate level of technical separation then it will be easier to introduce otherwise drastic technical changes at a much lower risk.

Conclusion

References