Head First Architecture Part-2

 This is the second part of covering the book Head First Software-Architecture, in this second chapter the emphasis was on the Architectural characteristics which is the first dimension of the software architecture.

What is it ?

There is no standard term for Architectural characteristics, sometimes these are called non functional requirements which is not accurate as these are indeed functional requirement they are just not related to the domain.Sometimes it is called cross-cutting requirements.

Architects break down structure design for software system into two types:

1- Logical components:
this represents the domain of the application ,the motivation for writing the software system.

2- Architectural characteristics:
these are the important parts of the construction process of the software system independent of the domain.

Further more we can say that Architectural characteristics have 3 main points:

a- They specify a non domain design consideration:
while the requirement decides what should be done by the system , the Architectural characteristics decides operational and design criteria for success.so these are important design decision that do not directly pertain to the domain, but are required for success.

b- They influence some structural aspects on the design.
An example given was in case of having an order processing system we can have a monolithic architecture (one with a single deployable unit and matching database), or we can have each component as a separate service in a micro-services architecture. The consequences for both approaches is that with each change in the promotions rules for example the monolith would need to be redeployed , while in the distributed architecture only the promotions service would be affected and can be redeployed independently.

3- Important/priorities
An architecture can support many architectural characteristics but they would have effects on the structure of the system and would add complexity to its design , so the architects need to choose wisely what characteristics to support, it should be only the characteristics that are critical or important to success.


An important note was made is that architectural characteristics tend to be synergetic or affect each other for example to support high security we would need to do on-fly encryptions  and similar changes that would affect performance negatively. But the same also applies to changes in domain design for example if a decision was made to store the user payment information then the security and data integrity characteristics would also be affected.

The chapter then went on to provide some categorization of the architectural characteristics :

1- Process architectural characteristics :

these are where the software development process intersect with the software architecture.
examples are: Agility , Deployability, Testability.

2-Structural architectural characteristics :
These are the characteristics that affect the internal structure of the software system and the degree of coupling between different components .

3- Operational architectural characteristics :
Represent how architecture decisions influence what operational team members can do.

Sources for architectural characteristics :
1- The problem domain:
architectural characteristics do not come out of thin air instead they derive from the problem we are trying to solve as it is after all the reason we are writing software.
This also means that we need to translate items stated in the requirements to their corresponding architectural characteristics, for example if was stated that the system needs to support hundreds of users this translate to the scalability characteristic.

2-Environmental awareness:
Many implicit architectural characteristics come from the architects knowledge /understanding of his/her organization, for example working for a fast-moving startup might mean we need to prioritize agility whether it is specified or not.Another example is that if we are to make a decision about how to integrate two sub-systems , the decisions are : a-customized solution that is highly suited to these two subsystems. b- an industry standard that will require more effort. In vacuum we might choose the first one , but of we are knowing that the prospect is having a lot of mergers along the way might tip the solution toward the more standard solution.

3-Holistic domain knowledge:

Some characteristics come from our own inherent domain knowledge: information that isn’t explicitly spelled out in the requirements but that we implicitly understand about important aspects of the domain. 
For example say we are to build a system for class registration for a school that has 1000 student and the time window for registration is 10 hours , we should not design the system considering that the students will evenly distribute themselves across the time-window , instead based on real world experience we know that some students are hyper-focused and some would procrastinate. Thus, the actual design must handle an elastic burst of students in the first hour (as everyone signs up early for hard-to-get classes), stay mostly idle for the bulk of the day, and then handle another elastic burst just before the registration window closes to accommodate all the stragglers. 

Final Points:
- Users often come to architects with solutions rather than requirements, an example for that was that in 1970s has a "requirement" for its next fighter jet to reach a certain speed, which was not feasible with that time's technology when they get to the root of that requirement is that the jet needs to be able to feel a fight f necessary , so it was created with a speed that would allow this.
So it is in such cases that the architect’s job to imitate an annoying toddler and keep asking “But why?!?” to uncover the actual requirement hidden within that solution.

- Architects must learn to translate “business speak” into architectural characteristics.

- Architects should limit the number of architectural characteristics they consider to some small number, such as seven.


Comments

Post a Comment

Popular posts from this blog

Head First Architecture

Image
 I have found out that there is a new book that is under early release version on the O'reilly website  called Head First Architecture that is to follow on the great Head First series , as I have read the Head First Design patterns book and really liked it several years ago and the fact that Neal Ford  (One of the authors of Software Architecture An Engineering Approach) is one of the authors, I take a look on it and found that it really is adding a lot of value at least for me, so I am doing a brief summary of it in the next couple of posts hopefully. At first it draws an analogy between building houses and building software systems, in this analogy the building plan or the blueprint of houses is the equivalent of the software architecture, what might be the similar point between both: 1- Both specify the structure of the system, in the house case it defines the rooms, walls, stairs and floors, in the case of the software system it defines the databases, services, user-i...
Read more

Head First Architecture Chapter-3

Image
 This chapter is mainly about the fact that software architecture has a lot of tradeoffs. An Application Scenario: A scenario was given about an application for selling sneakers (this could be anything tbh), that helps people buy, sell, and trade collectible sneakers.  The initial architecture was simple a single service that responds to requests send by mobile app users. So there are 2 options we might get into the tradeoff between them , which are using queues or using topics for messaging : so we can do the tradeoff analysis for each approach of them: 1- Queue approach  Pros:  a- It is more secure as the publishing service is aware of the receivers as each new service would have a new queue and the publishing service would need to know about it to send to it. b- we can have a different format for each receiver. c- we can scale and monitor independently each queue.  2- Queue approach Cons: a- Higher degree of coupling which hurts extensibility. b- Require...
Read more

The Culture Map -Some notes

Image
 I have been reading over the last few days  a book titled the Culture Map, it is extremely amusing and a clear eye opener for me . It is about the different culture contexts and how they can affect us in the work environment , implicitly and unintentionally sometimes. This also does not mean to follow  the different stereotypes as people from same country can different traits for sure, but also the cultural effect can have huge impacts on behaviors for sure. The Book Defines 8 Scales /Measurements that are needed in any business environment and how the cultural differences might affect them. 1- Communication: Low Context vs High Context : There are some cultures that start any communication without suggestion that there is a common context between different parties , that is why they tend to clearly document every step and  leave no space for speculation those are low context style of communication. While there are some other cultures that tend to assume an existing...
Read more