Software Architecture - A Summary Sheet

What are the key activities of a Software Architecture?

Philosophically, Architecture is an art. An architect thinks of something which doesn’t exist.

As a practice, a Software Architect is responsible for converting the business requirements into system blueprint, which can then acts as reference for design, implementation and other phases. Some of the key activities of an Architect, to list, are:

• What is it - Describe & Define the system from a broader perspective, based on essential functional and non-functional requirements. Draw the blue print of the system.
• Where it fits - Detailing on how the new solution would fit into and interface/communicate with other parts/systems of the whole eco-system.
• What it contains - Visualize system as combination of sub-systems, parts/modules/functions and how these sub-systems will communicate/interface with each other. Define the system boundary, interface points/protocols and sub-system interactions.
• How it is Structured – Choose appropriate Architectural pattern or combination of one or more and outline, how different sub-systems, modules, layers would be structured and interface with each other. For e.g. if chosen n-tier + SOA, then define different tiers and services exposed by them each and the way these tiers are connected.
• How to build it - Define Technology Stake. Identify suitable frameworks/tools etc. Do a technical feasibility and evaluation exercise, if required.
• What are Non-Functional Requirements – One of the important tasks of an Architect is to consider non-functional requirements applicable at Architecture phase for e.g. Scalability, Performance, Availability, Security etc.
• How it is deployed - Consider Hardware architecture and infrastructure support required for this solution.

What are the key considerations while architecture an IT solution?

Apart from implicit consideration that system should do what it is supposed to do, these are the important considerations from architecture perspective:

•  Money matters: The far most consideration is the overall cost involved in the solution. The solution should be cost effective, but still maintaining its value proposition.
• Know Your Users (KYU): The solution should be easy to adopt and use. Many well architectured solutions have failed just because they are difficult to use and not adopted by user community. Know your users and make something which they can use.
• Hear the unsaid: Along with key business functional requirements (which are mostly documented), the architect should consider the critical non-functional requirement to be addressed (which are, ironically, not always well documented and mentioned).
• Anticipate Changes: The solution should be extensible and ready to accept (realistic) changes with minimal cost and efforts.
• KISS: Solution should be less complex and maintainable.
• Make it Testable: Keep the testability in your mind. Something which can’t be tested, can’t be used.

What are key principles of software architecture?

1. Separation of Concerns – Ensure that the system is divided into logical units, each performing its designated task(s) and there is no or least overlapping between these units. Don’t cross concerns. This helps in achieving loose coupling and logical partitioning of the system.
2. Single Responsibility Principal – It is highly recommended to divide the system into units so that each has a single (logical) responsibility to handle and avoid multiple unrelated tasks.
3. Principal of Least Knowledge (Low of Demeter) – This means each unit, component or object should know only about itself and has no knowledge about the internal details of others.
4. Avoid Replication – Another key principle is to avoid repetition and maximize reusability of component, logic, code etc.

What are key non-functional requirements?

Non-functional requirements are one of the critical aspects of an IT solution. Ironically, those are not always well documented or candidly mentioned, but those are inevitable. Some of the important NFRs are

• Runtime – Security, Performance, Scalability, Availability, Data Integrity
• Implementation-time – Configurability, Auditing, logging, i18n, localization, extensibility, maintainability, adoptability, testability.

What are key points to be considered for scalability of an IT solution?

Scalability is becoming an inevitable aspect for any IT solution, especially those involved customers interactions. Here are key points to be considered to address scalability:

1. Functional Partitioning: It’s a very valid statement –you can’t scale if you can’t split. In other words, to achieve scalability you have to slice your application into logical modules or functions. This could be combination of functional or non-functional modules. With this, the modules or functions should be loose coupled, independent and, possibly, distributed. This allows these modules to scale independently. 
2. 3 Key Attributes of interaction/Communication
1. State-less: One of the key needs of a scalable architecture is the provision of stateless interaction between different layers, components and modules. With no overhead of state management, 2 components or layers can scale independently with optimum utilization of each.
2. Asynchronous: Another inevitable aspect is the asynchronous communication, using queues, messaging, batch processing etc. This would allow one layer to communicate with other, without holding the call. For e.g. if A wants to call B, A needn’t to wait till B finishes the job and vice versa. This also helps to ensure that A doesn’t stop even if B goes down or not available. Asynchronous is also the key for ‘Availability’ aspect of the solution.
3. Service Oriented: One more important aspect is to have logical, atomic and granular level of communication, instead of multiple- fine grained calls. For e.g. if A wants to call B, B should expose services which are logical and granular enough to perform an operations. This would avoid A calling multiple times to B for the same functionality.
3. For Database, 6 Key points
Vertical Partitioning: Logically and physically divide the DB. Have relevant tables at one place and more disconnected in distributed manner.
Horizontal Partitioning: Horizontally divide the DB (Shrad or Table partitioning).
No referential integrities: Avoid maintaining referential integrities in distributed environment. It’s a killer for scalable system.
No Data integrity: (Read about CAP theory) Forget about data integrity in fast, distributed and scalable environment.
No cross-domain joins – Avoid cross-domain joins. Those are expensive and time consuming.
No distributed transactions

And in the last, What are the key recommendations for a software Architect?

• Visualize the System – If you can’t visualize or imagine the system while taking shower, go back and clarify your doubts. An artist has to have the image in mind.
• Always Keep 3 things in your mind – Business value, cost and time. Missing anyone will nullify all your efforts.
• Make NFRs SMART – NFRs are critical, but unless those are Specific, Measurable, Attainable, Realizable and Traceable, those can’t be achieved. 
• Don’t Sketch Your Own Lines. Choose architecture patterns and practices which are established and accepted by Industry. 
• You may refer from your previous assignments and implement learning, but don’t biased from it. Technology is dynamic and improving everyday. Don’t hesitate exploring new paths.
• It is important to document all Key decisions and learning.
• Architecture is not just an inception phase. Lead your team till the end. Don’t just define architecture, deliver it as well…