Can you build anything of value without a strong foundation? The loftiest building stands because of its deep and solid foundation. The house of cards crumbles because of the lack of it. The world of software products is no different. A great software product stands on the strength of its architecture. It also falls, because of it.
Why talk about product architecture?
At a high level, software product architecture is the plan that defines the set of aspects and designs essential to the software. The architecture takes into consideration aspects such as performance, security, scalability, functionality…pretty much everything that makes that software tick.
It is the software architecture that decides how and how well the system parts communicate with each other, what the external dependencies are, what will be the guidelines of the technical implementations, the risks to factor in and so on.
As we said, software architecture includes decisions. How easily can you change an aspect of the software, add or deduct from it, update it or upgrade it? Would there be a huge impact when you decide to implement any change? Would it be hard to manipulate this change?
A great software architecture contributes the following to development:
- It serves as a basis for communication between all stakeholders (users, customer, product management, etc.)
- All relevant and important software-related, technical and user-related decisions are considered at this stage
- It defines the model of the software and how it will function. It will also define the problems you might encounter during implementation.
Software architecture and the black hole of Technical Debt
‘Technical Debt’ is almost like a curse of the Agile way. The quest for building fast and releasing often places a burden on the software architect. The architect is called upon to begrudgingly design the bare minimum…the minimum viable architecture. The thing is, agile teams, recognize the need for a strong architecture but often ‘go-to-market’ is the enemy.
Design artifacts for the best, the most-perfect software architecture can be a drag when all the development team wants to do is get the working software out of the door. So, what do they do? They get a ‘good enough’ architecture in place. But it is this ‘good enough’ architecture that paves the way for ‘technical debt’.
We suggest that when it comes to software development, technical debt comes in two types. Let’s call them Type 1 and Type 2.
Type 1 is when the code is just bad. This has to be avoided under all circumstances (well, obviously). The second type, Type 2, refers to the intentional shortcuts designed to help the code to work. This code will require refactoring in the future iterations. Such code usually has an intentional lack of functionality or intentional design simplification to reach a short-term goal in a manner that it can also facilitate future iterations easily.
Well planned technical debt (type-2) is an essential part of agile software design and is, in fact, necessary.
This of this like how borrowing money when you want to buy a house can be a good thing. However, you have to ensure that your future monthly payments are manageable and that the interest does not cripple you and later, your house increases in value. This is well-planned debt. And the same applies with software architecture and technical debt.
Software architecture and the evolving expectations conundrum
Change has now become the norm in the world of software product development. It’s not just new technologies or stellar new languages influencing these changes. Even data is making a big impact in the development landscape. Users want elevated, intuitive, frictionless experiences. The forces of globalization are expanding markets and consequently also increasing competition.
You need to cater to the needs of the user even before the user identifies the need. That’s how great software products are built today. That’s how they stay successful.
Unless you focus on continuously enhancing your products’ features, unless you drive exception customer experiences, your product will easily be replaced. Do you remember Orkut? Probably not, because Facebook replaced it.
Now, to stay in step with this climate of constant change, we have to focus on software architecture. The business goals of a product determine the features and quality attributes of the product and the feature and quality attributes of the product determine the architecture.
An analysis of the architecture helps in identifying and reducing risk. It also serves as a foundation to develop a product that is ‘built to change’ rather than ‘built to last’. It takes into consideration:
- The Functionality of the software and its performance against the intended purpose
- Reliability of the software to offer the desired functionality under given conditions
- Usability and extent to which the software product can be used with ease
- Performance considerations such as speed, response time, resource utilization, throughput, and productivity
- Supportability and the ease with which the programmers can transfer the software from one platform to another, without any or with minimal change and effort.
Having a well-defined and clear software architecture defines the solution clearly – what it expects to do, achieve, its concerns, who will interface with it, etc. It takes into account all considerations, of the end uses, the system administrator, the marketer, the client, the concerns of the developer and project requirements, and the concerns of the maintenance folks.
The need for flexible and adaptable software architecture designs, interoperability with other programming frameworks and a focus on user empowerment is growing. Great software product architecture helps build a great product but also keeps a check on your technical debt.
Clearly, the software architecture of the 21st century has to understand that for quick results you also need to think of enhanced software design adaptability. It must realize that today, the user is the fundamental driver of business success. And that good architecture aids good software development. Period.