Adrian Anacleto’s review published on Cronista Comercial 14/06/2011 printed edition
Software Architecture: the business of IT quality
Architecture in practice. Think, quickly, of a business in which applications crash, are slow or data is stolen. You sure found several examples. This happens often and is more common than it seems.
Users of systems usually find in everyday use, some quality issues in systems, programs or applications. Behind the most common expressions or complaints made, we may find references to “quality attributes” of a software application.
By saying: “the application is slow”, one is speaking of performance; if we hear of: “the application drops” the quality attribute referred to is availability and if someone says “I don’t get this application, it’s very complex”, it’s speaking of usability. And we could keep on naming more examples, because applications have hundreds of quality attributes, among the more famous are: security, ease of maintenance, modification, testing and many others. These are defined by standards and global quality standards such as ISO, IEEE and Mitre.
On the other hand, more than 65% of the total cost of ownership of an application is spent on the maintenance phase of the system, ie, once the software is already built. It means that, if the product development costs u$s 700.000, the maintenance will take at least u$s 1,3 million. Therefore, if a software architect could reduce this cost by 15%, it would mean savings of u$s 195.000.
However, it is possible to have a software product that is economic and easy to maintain; everything has to do with quality. It’s worth analyzing the business of IT quality and the role architecture takes in this process.
The role of the architect
Many times, by wanting to optimize an application to reach many of these quality attributes at once, the cost soars and, in many cases it does exponentially. It can be said that, for an application to work properly, not only it has to meet the functionality for which it was designed, but it must be done in an agile and secure way and keeping low maintenance costs.
Let’s analyze Twitter: Why is it so simple? Mainly, because it’s usable (in this case friendly and simple) and it has a short response time (performance) in general, which leads us to believe that there are things left out. What about availability? Does Twitter work 24/7? The answer is no. When we want to do something that risks Twitter performance, a message appears explaining that “Twitter is over capacity”, which indicates that the site didn’t fall, but, at that moment, cannot be operated. However, there is no doubt that when doing well, it’s fast and usable.
What would happen if Twitter allowed 50.000 characters instead of 140? What impact would it have on the performance? On the availability? And on ease of use? Besides the quality attributes of an application is a responsible being for them, who “balances the equations”: the architect. In order to visualize him, you could think of the character in the movie Matrix, that man with a beard, in a room full of screens, who told Neo (the main character) that he was responsible for maintaining the balance of all the equations for the matrix to function.
This architect was the matrix designer, the person behind the system. A software architect must not only deal with the application itself, but must be able to design and build the inherent business constraints (money, current staff, available equipment, technology, etc.). He is responsible for the platform, technology and defined architecture, so that it can scaleand be able to meet future business challenges.
The root of many failures in software projects is usually poor architecture. The numbers speak for themselves: 70% of applications have availability or performance problems. The architect has to deal with all these factors and, also, has to know how to explain them. For this, there are formal methods for evaluating an architecture, and work groups where learning and training.
Everything, simpler
In order to carry out the task of defining and maintain a software architecture, there are formal methods for evaluating architectures. While most methods work on a definition and requirements, there are innovative applications to work on undocumented applications (or poorly documented) and even do so over the same productive application.
Everything is easier when it becomes natural to identify what is behind the poor quality applications and those with a lot of functionality and poor performance or poor security, which are very expensive to maintain. The role of the software architect and software architecture as a practice in that company is in the back. The question then should be: Is there a software architect at said company? Does he have the necessary skills? Are his definitions respected and followed throughout the product life cycle?
Is there an architecture process?
Although the answers to many of these questions are likely to be negative, it is never too late to start working on the software architecture and address the most important quality attributes, so that the application complies with the functionality for which it was designed.
