Happiest Software Architect . >2/12

In the last Happiest Software Architect #1/12, we saw about what is mind of software architecture, how to to think about software architecture rather than defining it, the 8 core expectations from software architects and laws of architecture.

This week let's talk about detailed around what is architectural thinking and modularity.

Happiest Software Architect .

What is Architectural Thinking ? An architect thinks differently from the developers point of view, much in the same way urban people see the rice differently from the farmer point of view which is called Architectural Thinking where architectures think with an architectural view of eye and more than that.

Four main aspects of thinking:

1. Understanding the difference between design and architecture
2. T-shaped technical knowledge with certain level of technical depth
3. Analyzing and reconciling trade-offs between various solutions and technologies
4. Business drivers and how they translate into architectural concerns

Architecture vs. Design:

Let's understand what is design vs. architecture, where did that begins and ends? There is no start or end, both works together making architecture work through deep collaborations. To have effective solutions to the business and technical problems, both design, architecture and developer team should work bi-directional approach rather than the unidirectional.

So where does architecture end and design begin? Actually it doesn’t; both part of the circle of solution within the software projects and should be always in sync with each other in order to succeed the other. And as an architect , the breadth is more important than the depth.

Trade-offs:

Thinking like an architect is all about trade-offs in every solution, technical and analyzing the trade-offs and find the best solutions.

Architecture is the stuff you can't Google.

By Mark Richards

Everything in architecture is a trade-off hence the "it depends" is the universal answer to all architecture questions.

There are no right or wrong answers in architecture; only trade-offs. By Neal Ford

Hence the point is that everything in software architecture has a trade-off, an advantage and disadvantage. Thinking like an architect is analyzing these trade-offs which is more important like extensibility or security and the decision between different solutions would always depends on the business drivers, environments and with bunch of other factors.

Programmers know the benefits of everything and the trade-offs of nothing, but Architect need to understand both. By Rich Hickey

Modularity :

Modularity is an organizing principle and if an Architect designs a system without thinking how the pieces wire together; then would be difficult and bad system ever. Hence preserving good modularity exemplifies our definition of an implicit architecture characteristic. Example of modularity in Java is package and in .NET it is namespace.

Above we understood the vital of Modularity in the Architectural journey, but let's understand the measuring of the same with three concepts like cohesion, coupling, and connascence. The cohesion refers to what extend the parts of a module should be contained within the same module. And when we use module, it can be components in the most platform.

Happiest Software Architect Blog Series >1/12, 2/12, 3/12, 4/12, 5/12, 6/12, 7/12, 8/12, 9/12, 10/12, 11/12, 12/12.