SOFTWARE ARCHITECTURE
Concept & Fundamental
Software architecture definitions vary widely. Let's look at two of them.
“Group of principles and constraints about how software solutions have to be built within a given boundary”
"Truth can be found only in one place: the code." This quote was spoken by Robert C. Martin
As a Software Architecture /Engineer you will need to combine art & science to deliver system solution in satisfactory manner.
“Code serves as bricks in software architect”
Concept and Fundamental
Software Architecture focus more on “Structure” instead of implementation details.
Identify the anticipated expensive choice after the system implantation.
Making core decision for high quality software.
Functional Requirements
Functional requirements means what system should do. To comprehend the functional requirements, we'll use "Resturant Website" as an example here. The following can be the functional requirements in our example Resturant website.
Search Inventory
Manage Product
Place Order
Order Fulfilment
These functional requirements are mostly align with the product features.
Non-Functional Requirements
Non-Functional Requirements describe how the system should behave. Here are the few of them.
Reliability : System is available 24/7.
Efficiency: Latency short response time.
Maintainability: Developed and maintainable for several years.
Scalability: Able to serve millions of users.
As a software architect you will have to consider the non functional requirements as well. You implemented the perfect product feature but due to latency issue, your customer may abandon your website.
Restrictions
Apart from functional and non-functional requirements you will have the system restrictions.
“RESTRICTIONS will limit your choices for software architecture design”
e.g. Legal compliance, standard, time to market, cost etc.
As a software architect you must determine how to handle these restriction.
Prioritize
After you know what we need (functional requirements) and how system behave the non-functional requirements and what are the restriction we need to consider. Now you need to prioritize them.
So, there may be a conflict between the requirement and restriction. For example, if we have a strict time to market (time to market vs features) we need to drop some features. It could be a non-functional requirement, e.g. portability. If we do not need to deploy on multiple platforms, then we can drop the portability in favor of scalability etc. You need to design the priority list and tradeoff for approval.
Designing the Architecture
Now you prioritize the requirements start with things one by one instead of taking care of all things (avoid over engineered) . What are more obvious start working on it, may be something is not obvious now make more context at later stage.
Now start designing the software architecture. There are several architectural patterns like layered, event driven, microservices pattern etc.
The layered architecture is my favorite one. The layered architecture composed of several separate layers that function together as a single unit of software.
UI layer
Business Logic layer
Data Access Layer
Database Layer Store
The frontend is comprised of the UI (User Interface) layer, whereas the system backend is comprised of the business logic layer, data access layer, and database layer.