Software application architecture - An overview of major software aspects

Software application architecture (I will deliberately use architecture from now on)  is an aspect that should involve the whole team, from the business owners to the developers and the final users -at least a prototype of them-. I will use the MSDN definition because I find it complete and easy to understand: Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.

Now that we know it's definition and the usage it has, let's talk about key factors related to architecture:

• Communication. I'm not just talking about "being available" for answering questions, the business owners must communicate new features required as well as bugs found in the business logic. They must provide detailed and specific descriptions of the process that the developers are going to work. This also apply from the developer to the business side, if the developers find a feature very hard to develop, they must suggest something and make it clear to the business owners, doing so may provide a different way to tackle the problem
• Documentation. The software system must be documented and described in detail. This documents are the contract that will prevent misunderstands and will help new members of the team understand the system.
• Keeping a list of concerns, assumptions and expectations. This can help when reviewing the project in the future and understanding the architecture decisions. It's a good idea to keep it organized by subject. For example, divide it in infrastructure considerations, software concerns, business analysis, etc.
• Create more than one architecture. It would be very hard to have one architecture, ideally you will create more than one with enough detail to start testing and see how things are looking. It's better to do it iteratively and in an incremental way to refine the architecture.
• Have a due date for completing the architecture. Because architecture involves the whole team, it could take forever to have a "perfect" and approved architecture, but the reality is that we will need to make adaptations because we cannot know everything up front, but we can create an architecture that is ready to handle future changes. So it's a good idea to decide on how much time is the team taking for defining architecture, and start working right away to find issues in an early stage of the project and address them as soon as possible. 
• Take an active part in the decision making and then follow through!. It would be very important that everybody gets involved according to their role in the project. Once that the decisions are made, they should be followed. For example, if you need a web service for some sort of operation and the team decided that X web service is the right one, then it should be used whenever that operation is required. Also if the architecture requires to do some code files in order to create a process, they should be created whenever a new process is requested. On the administrative side, there is also an effect, if the team decided to use an excel spreadsheet for uploading information, the business side must accept this responsibility and create the required files.
• Hide details of implementation. When you're working with a software system, it is important to have a good service layer to reveal only what is necessary. Revealing architecture to other systems can be dangerous for security and in the "best case" it can make other developers think a lot on things like: "why have they do that?". Well... that's not the concern of people connecting to your system, they should only know how to obtain exposed data required for other systems.  

Important factors affected by the architecture:

• Time for adding features. If we got a good architecture, then the new features are pretty much "expected" and they can be delivered on time. This is because we would probably leave the "skeleton" ready for the upcoming features of the system. Besides, when you have a bad architecture, it's really hard to obtain time for re factoring,because it's the most technical aspect of software development, so the other areas involved will not clearly understand the importance of the architecture, so they will not allow much time for re factors.
• Performance of the system. If we do the right choices, the performance will be the expected. This is related to the entries of performance: Back end and Front end.
• New people in the team. If there are new business owners or new developers, a good architecture will make the learning path very straight forward, and this will save time and money to the company.
• Integration with other systems. Most systems nowadays interact with other systems. Having a good architecture (for example, creating a web service layer) will make it easier to interact with other systems, and it's important to see this on the beginning of the project. Doing so will save a lot of time, when this kind of interaction is needed.
• Bugs. Good architecture leads to less bugs, bad architecture leads to a lot of bugs. That's something easy to understand, because if the architecture is not ready to show good messages whenever you're having a new issue, it's very unlikely that you'll find the reason of the bug, also if the architecture has bar practices like not having a good structure of the project and then creating a lot of methods for the same thing, you'll probably find the same bug repeated in different areas of the system.
• Value. The architecture plays a very important role in the value of the project. In the end, the expected times for adding features, the performance, the usability, the results and everything related to the system is directly derived from the architecture decisions, and the users will take advantage of the system, if and only if our decisions are appropriate.

It's complicated to give and estimate on how the architecture affects software systems, it depends on a lot of factors and the context of the systems, but I will use a piece of an interesting article to give you an idea:

"It can be hard to measure the cost of software erosion and convey this cost to non-technical people who often have to sanction work to stop software erosion. Even though software erosion causes reduced productivity, reduced quality and increased time-to-market, no one specific point of erosion causes these effects in isolation, rather it is the effect of multiple points of erosion that combine and reinforce each other to cause them.

However, a study by the US Air Force Software Technology Support Centre (STSC) attempted to put some rough measure on the costs of software erosion. The researchers took two versions of a mature software system (50k LOC) and asked two different teams to perform the same maintenance task (adding approx. 3k of code) on their respective version. Version 1 was an existing system suffering software erosion. Version 2 was the same system but with the architecture restructured to remove erosion.

The results were staggeringly different. Team 1, working on Version 1, needed over twice as long as team 2 to complete this relatively short task. Furthermore, Team 1’s results contained more than eight times the number of errors than the work submitted by team 2, working on version2. Erosion in a small system such as this still had the potential to lead to significant problems when the software was maintained."

This is the link to the original article:

http://www.methodsandtools.com/archive/archive.php?id=85

Ok, this is just the tip of the iceberg, but I wanted to share with you, how important is to have a good architecture. My best advice is to do early planning and to have great communication channels between teams, this are the very key factors to success. I hope you're enjoying the series! if you want me to talk about a particular software topic, let me know in the comments.