Software Development – good software architecture

by Jack E. Software Development Company

Software architecture like building a house requires a wide range of technical resources to work in a coordinated manner to deliver a fully functioning and fit for purpose end product. Forgetting the scope, the budget and of course the timeline for a minute this blog will focus on a method of ensuring each resource has a clear technical responsibility, the project manager has an understanding of the technical components to deliver the project and more importantly the architect (*) can communicate the vision (after all the software development process depends on a thorough architecture). These software architecture patterns have a variety of names which can be referenced including:

Client-Server
Three-Tier Architecture
N-Tier Architecture

(*) by architect here we refer to an enterprise architect however depending on the project this might be a technical architect (a professional who is technical in their capability and usual focusses on the technical solution layers – more on this later!), a solution architect (a professional who is more functional in nature and understands the product/tools available to deliver the required solution) or an network architect (a professional who designs solutions to ensure communications between devices/machines/components can efficiently take place without limits).

To breakdown a solution into technical components we can often focus on the logical breakdown of the solution and group the technical components into layers. One logical grouping is based on the user being on one side and the lowest level on the other side – depending on how complex and how many layers you wish to create this typically is the data layer (or database). In the next sections we will consider the different layers that may or may not form part of the abstraction of technical and/or functional design. Remember good software development is about understanding the requirements both functional and non-functional along with the business landscape and not just creating the software we as developers like to create (business adaptability to change, availability of budget/resource/time etc).

Presentation Layer

This is the layer that is closest to the user and converts the data from the layer below into information which can be displayed on the required device(s). Understanding the target devices, clients to display / present information (think Chrome, Edge, Alexa using Voice etc) and the required format of the information is critical in defining the presentation layer. Within this layer we again try to abstract the layer even further – after all we don’t want to have to define a different structure for every client/device. As experienced software developers we isolate the views based on the device type and technology – although there are different methods than can be employed. As an example this would mean that we would use HTML and CSS to define a layout for clients that support HTML/CSS such as Chrome, Edge and Firefox or Swift for an IOS mobile app. Often forgotten the presentation layer consists of all methods of display to a user which extends to emails, downloads and of course everything in between.

Business Layer

Often this layer is abstracted further but typically this layer holds the business logic / functional logic to determine what the presentation layer should display, and what data is required from the database. This middle layer can be considered the facilitator to implement the core of the software and ensure the business functional requirements (and non-functional requirements to some degree) can be met. Everything from determining whether a user can login through to interacting with 3rd parties to exchange data is handled in this layer. Within this layer we will often further group functions based on their functional role – so finance functions would be grouped, CRM functions grouped and interface functions grouped. Of course what the layers don’t tell you is what the layer will actually be made up of – the functionality can be split across one or more components – these could be an off-the shelf package to deliver some functionality, bespoke software development or an online software as a service. As a qualified enterprise architect and certified IT Professional this is one of the greater challenges when choosing the right overall solution – examining what is currently available versus what is actually required. Each integration point between systems will need to be carefully considered whether the benefits (cost, speed of delivery, reduced testing etc) outweigh the costs (duplicated data, failure processing, additional testing of interfaces etc). In a later blog we will explore the method of balancing the scales when choosing whether to incorporate into custom software architecture standard packaged components.

Data Layer

Perhaps the easiest for everyone to conceptualise is the data layer which as the name suggests controls the storage and access of the data for the solution. The data maybe distributed across one of more datastores/databases and the methods of accessing data might be different depending on the source. For example where a third party accounting solution is being used and data is required to be exchanged – having an integration in this layer will ensure the business layer doesn’t care (or need to know) where the data comes from. In terms of writing data to multiple sources this layer is responsible for ensuring the consistency is maintained and for the multiple updates/inserts – without the layers above perhaps being aware of the action. Typical databases used are based on the standard SQL format (which is a relational database meaning we store the relation between data) however this could easily extend to reading/writing files, making webservice calls (using SOAP perhaps) and/or Amazon DynamoDB which is a non-relational database.

Layer communication

The whole purposes of layers is to cleanly segregate functions and define a clean method of communication between the layers – this speeds up the development process, reduces the implementation risk (as changes can be isolated often to a single layer) and also defines key responsibilities for each of the technical resources. For example in web development we would have a number of our team working on the presentation layer (designers and front end developers), our business layer (technical architect, back end developers and integration specialists) and the data layer (database architect and back end developers). We must therefore for all software solutions define the mechanism to share data between the different layers including supplying transactional data (success, failure, auditing information, permission date etc).

Jack Enterprises is an experienced software development company supporting clients across the UK & Europe. Our in-house professionals support clients through the complete process of development and we pride ourselves on our business process focus. Our software development methodology uses our own BPATH (Business Process At The Heart) to ensure we focus on delivering a solution that fits your business like a glove.