Slightly deviating from semantic web, I would like to talk about application architecture.
To my mind, architecture always resembles structuring the concerns. Whose concerns? Concerns of the stake holders or people who have a vision of what they want. When you build a house you have a idea of what all you need. Your wife has something else. Your kids add something more and so on. The architect has to find a balance of your concerns, create a structure on which your concerns are addressed. This means a building plan where each of your concerns are addressed. Not only that there is a certain elegance when you look at the plan in which the concerns are balanced out with a sense of aesthetics, symmetry etc. All of these are well balanced with the constraints that are there. For example, cost could be a constraint or a need to have a maintainable flooring could be a concern. Based on that the choice of colors or the ventilation and lighting, minimizing wastage, increasing utility and so on.
Balancing out the concerns, constraints, elegance on a structure is the architecture.
If it is software, the concerns are different. It could be like a sponsor saying 'I need to handle 5 million subscribers with a sub-second latency when they access a certain feature'. Or it could be like a 'highly usable interface that talks the native language of the user'. Or it could be even a schedule or cost input that says ' I need this before christmas' when you are in June. That may severely constrain the choices you have.
As you see concerns are something that a stakeholder feels a feature to be important. But further discussions may relax them or you may be able to find the range. In the example above, on discussing you may find out that the sub-second latency can be up to 3 seconds and it is still fine for the stakeholder as you may point out that the hardware cost is higher if it is kept under 1 second.
Structuring the concerns and constraints into software systems, components is a art. As there is no single right way. If you structure your application in a way it allows greater flexibility, for example changes to the data model should be done in a jiffy with configuration without any coding is something desirable. But this will mean the components involved are coded in a data agnostic way. The domain model is super-imposed on the application rather than wired within. Allowing such a flexibility may not often give the greatest performance. Thus at a architecture level, you may allow a hybrid approach wherein based on the type of transaction and the type of client accessing the system, it may be able to use the high performant route which is a more tightly coupled, specific technology stack based implementation, though it may still allow adding on a generic loosely coupled configurable implementation by the side for other types of traffic.
What if we had allowed only the high performant closed model? It may fly for the type of traffic we envisioned, yet it may increase the cost of maintenance when changes happen or some times it may not be possible to even introduce any changes. It may require a rewrite.
Thus when all concerns are brought in, the system moves in different directions. Architecture provides the space for meeting all the concerns in a way it is agreeable to the product visionaries at the same time keeps the future growth or changes in mind.
Architecture brings in malleability to the application when it is hammered with new possibilities. No rewrite or very less rewrite is needed. Only additions at the right places already provided will be needed. A good architecture cannot be there without a futuristic visualization of the requirements of an application. Architecture comes out with a lot of brainstorming rather than a single individual blowing it out. But the single individual who dons the role of the architect needs to be able to see the big picture and be able to steer the direction without getting lost in unwanted concerns. The architect should allow the different possibilities to exist but at the same time not lose track of the end goal. End goals can keep changing and hence the architect should keep the malleability to remain and not get lost during implementation to handle changes.
Similarly architecture cannot be done without understanding the technology, software and code. It is very intimately related to what happens underneath. A large number of products do not take off from the shelf. Very few meet the customer and very few among them are actually used finally. Given this, it is important for the architect to bring focus on the key concerns rather than floating on imaginary aspects. This goes against what I said above about visualizing requirements. It is important to visualize, but it is equally important to make it practical based on the ecosystem. If you have a poorly skilled team, visualizing very broad themes, drawing the architecture and realizing them in a implementation would be a hard problem. Or if you have a sponsor who does not value the architecture and instead who is driving the short-term goals would pose a bigger problem to run a clean architecture based implementation. For architecture to bloom, the sponsor should be a technology person at heart who knows the value of a solid architecture. It is a call taken based on the commitment to make a product and take it to market and expand on it.
To my mind, architecture always resembles structuring the concerns. Whose concerns? Concerns of the stake holders or people who have a vision of what they want. When you build a house you have a idea of what all you need. Your wife has something else. Your kids add something more and so on. The architect has to find a balance of your concerns, create a structure on which your concerns are addressed. This means a building plan where each of your concerns are addressed. Not only that there is a certain elegance when you look at the plan in which the concerns are balanced out with a sense of aesthetics, symmetry etc. All of these are well balanced with the constraints that are there. For example, cost could be a constraint or a need to have a maintainable flooring could be a concern. Based on that the choice of colors or the ventilation and lighting, minimizing wastage, increasing utility and so on.
Balancing out the concerns, constraints, elegance on a structure is the architecture.
If it is software, the concerns are different. It could be like a sponsor saying 'I need to handle 5 million subscribers with a sub-second latency when they access a certain feature'. Or it could be like a 'highly usable interface that talks the native language of the user'. Or it could be even a schedule or cost input that says ' I need this before christmas' when you are in June. That may severely constrain the choices you have.
As you see concerns are something that a stakeholder feels a feature to be important. But further discussions may relax them or you may be able to find the range. In the example above, on discussing you may find out that the sub-second latency can be up to 3 seconds and it is still fine for the stakeholder as you may point out that the hardware cost is higher if it is kept under 1 second.
Structuring the concerns and constraints into software systems, components is a art. As there is no single right way. If you structure your application in a way it allows greater flexibility, for example changes to the data model should be done in a jiffy with configuration without any coding is something desirable. But this will mean the components involved are coded in a data agnostic way. The domain model is super-imposed on the application rather than wired within. Allowing such a flexibility may not often give the greatest performance. Thus at a architecture level, you may allow a hybrid approach wherein based on the type of transaction and the type of client accessing the system, it may be able to use the high performant route which is a more tightly coupled, specific technology stack based implementation, though it may still allow adding on a generic loosely coupled configurable implementation by the side for other types of traffic.
What if we had allowed only the high performant closed model? It may fly for the type of traffic we envisioned, yet it may increase the cost of maintenance when changes happen or some times it may not be possible to even introduce any changes. It may require a rewrite.
Thus when all concerns are brought in, the system moves in different directions. Architecture provides the space for meeting all the concerns in a way it is agreeable to the product visionaries at the same time keeps the future growth or changes in mind.
Architecture brings in malleability to the application when it is hammered with new possibilities. No rewrite or very less rewrite is needed. Only additions at the right places already provided will be needed. A good architecture cannot be there without a futuristic visualization of the requirements of an application. Architecture comes out with a lot of brainstorming rather than a single individual blowing it out. But the single individual who dons the role of the architect needs to be able to see the big picture and be able to steer the direction without getting lost in unwanted concerns. The architect should allow the different possibilities to exist but at the same time not lose track of the end goal. End goals can keep changing and hence the architect should keep the malleability to remain and not get lost during implementation to handle changes.
Similarly architecture cannot be done without understanding the technology, software and code. It is very intimately related to what happens underneath. A large number of products do not take off from the shelf. Very few meet the customer and very few among them are actually used finally. Given this, it is important for the architect to bring focus on the key concerns rather than floating on imaginary aspects. This goes against what I said above about visualizing requirements. It is important to visualize, but it is equally important to make it practical based on the ecosystem. If you have a poorly skilled team, visualizing very broad themes, drawing the architecture and realizing them in a implementation would be a hard problem. Or if you have a sponsor who does not value the architecture and instead who is driving the short-term goals would pose a bigger problem to run a clean architecture based implementation. For architecture to bloom, the sponsor should be a technology person at heart who knows the value of a solid architecture. It is a call taken based on the commitment to make a product and take it to market and expand on it.
