A lot many times I end up seeing designers / architects drawing technology stacks when showing the architecture.
Architecture to me is always independent of technologies. Architecture is a sort of blue print addressing the concerns. It has many views and a technology stack that fits the blue print is one of the views.
Mainly the blue print should be able to have blocks which addresses the different functional requirements - sort of a broad sweep. For example, if the functional need is "Integration with one or more southbound systems" then a block which maps to it having inner blocks representing "Adapters, Transforms, Endpoints, Routes" as some of the labels of it would give an idea that the southbound integration is addressed by this block.
Now there can be many blocks representing different functional needs. It is important to be able to specify the interconnections between these blocks and specify the type of protocol.
The entire system comprising of the different functional blocks should be given a view in terms of the ecosystem where it resides. The systems and applications that connect to this system whose architecture is being defined. The ingress, egress points have to be specified along with the protocol.
As another view, the physical view or deployment view can show these blocks as processes, libraries, clusters, physical interconnect etc. This gives an idea of how the above functional blocks are realized and represented in the real world. The deployment view can also label the exact technologies like Hibernate or Drools or J2EE or others to give a better idea of the physical view. The physical view typically shows the single node and cluster deployments.
As another view, the most significant call flows through the architecture can be highlighted by way of a sequence diagram across the architectural blocks.
Essentially what we are showing is the way the overall system under question is viewed from different angles like the way a house is seen from the front or top or dissected to see the internal arrangement of the rooms or the passages connecting them and a even high altitude view to see how the other houses and street are where the house under question is situated. It is quite similar.
This way of representing in different views or dimensions help answer different aspects of the architecture early on allowing others to comment and refine the picture. It gives the broad guideline for design and shows the way all through implementation. If the original blocks have not been violated over course of time in spite of the varying requirements through a project, its a sign of good abstraction of the problem in hand.
The key here is the blocks should not be overtly high level and general that it is useless to relate the problem to it. It should have sufficient detail to give a clear understanding of how the underlying design will work at a high level. At the same time, it should stay away from too many details which if you think will be better served to be handled during the elaboration of a block during design.
Architecture should not be seen as mere pictures. They are the outcome of a experienced person solving the entire complex problem with its multitude of requirements in one go at a broad level. It should address all the key requirements and should not leave anything. It is one broad stroke with a paint brush covering the final outcome. Details are missing but can be filled in during the course of design.
Architecture to me is always independent of technologies. Architecture is a sort of blue print addressing the concerns. It has many views and a technology stack that fits the blue print is one of the views.
Mainly the blue print should be able to have blocks which addresses the different functional requirements - sort of a broad sweep. For example, if the functional need is "Integration with one or more southbound systems" then a block which maps to it having inner blocks representing "Adapters, Transforms, Endpoints, Routes" as some of the labels of it would give an idea that the southbound integration is addressed by this block.
Now there can be many blocks representing different functional needs. It is important to be able to specify the interconnections between these blocks and specify the type of protocol.
The entire system comprising of the different functional blocks should be given a view in terms of the ecosystem where it resides. The systems and applications that connect to this system whose architecture is being defined. The ingress, egress points have to be specified along with the protocol.
As another view, the physical view or deployment view can show these blocks as processes, libraries, clusters, physical interconnect etc. This gives an idea of how the above functional blocks are realized and represented in the real world. The deployment view can also label the exact technologies like Hibernate or Drools or J2EE or others to give a better idea of the physical view. The physical view typically shows the single node and cluster deployments.
As another view, the most significant call flows through the architecture can be highlighted by way of a sequence diagram across the architectural blocks.
Essentially what we are showing is the way the overall system under question is viewed from different angles like the way a house is seen from the front or top or dissected to see the internal arrangement of the rooms or the passages connecting them and a even high altitude view to see how the other houses and street are where the house under question is situated. It is quite similar.
This way of representing in different views or dimensions help answer different aspects of the architecture early on allowing others to comment and refine the picture. It gives the broad guideline for design and shows the way all through implementation. If the original blocks have not been violated over course of time in spite of the varying requirements through a project, its a sign of good abstraction of the problem in hand.
The key here is the blocks should not be overtly high level and general that it is useless to relate the problem to it. It should have sufficient detail to give a clear understanding of how the underlying design will work at a high level. At the same time, it should stay away from too many details which if you think will be better served to be handled during the elaboration of a block during design.
Architecture should not be seen as mere pictures. They are the outcome of a experienced person solving the entire complex problem with its multitude of requirements in one go at a broad level. It should address all the key requirements and should not leave anything. It is one broad stroke with a paint brush covering the final outcome. Details are missing but can be filled in during the course of design.
