Architecture decisions form the constraints of the system and direct the development teams on
what is and what isn’t allowed.
An exception to a particular architecture decision is analyzed by the ARB (or chief architect if no ARB exists) and is either approved or denied based on justifications and trade-offs.
🚨 ถ้าวิเคราะห์แล้วพบว่ามีจุดที่ทำให้ต้องไม่ปฏิบัติตามข้อกำหนด (Variance) ก็ต้องมองหาสิ่งอื่นที่เหมาะสม (Design Principles)
The first key to effectiveness and success in the software architect role depends on understanding and practicing each of these expectations.
-
An architect should
guide rather than specify technology choicesor might need to make specific technology decisions in order to preserve a particular architectural characteristic. -
An architect is expected to continually analyze the architecture and current technology environment and
then recommend solutions for improvement.An architect must holistically analyze changes in technology and problem domains to
determine the soundness of the architecture. -
The decisions an architect makes tend to be long-lasting and difficult to change. Understanding and following key trends helps the architect
prepare for the future and make the correct decision. -
Continually verifying that development teams are following the architecture decisions and design principles defined, documented, and communicated by the architect.
By not ensuring compliance with architecture decisions, the architecturewill not meet the required architectural characteristics(“-ilities”), and the application or systemwill not work as expected. -
An architect must at least be familiar with a variety of technologies. Focusing on
technical breadth rather than technical depth. -
Without business domain knowledge, it is difficult to understand the business problem, goals, and requirements, making itdifficult to design an effective architecture to meet the requirements of the business.Without this knowledge, an architect cannot communicate with stakeholders and business users and willquickly lose credibility.Using the domain knowledge and
language that these stakeholders know and understand. -
Including teamwork, facilitation, and leadership.
Leading the development teams through the implementation of the architecture. -
The main point is that
almost every decision an architect makes will be challengedby developers who feel their approach is better or due toincreased costsorincreased effort (time)involved.The architect must navigate the politics of the company and
apply basic negotiation skills to get most decisions approved.
- The architect and developer must be on the same virtual team to make this work.
An architect is responsible for things like analyzing business requirements to extract and define the architectural characteristics (“-ilities”), selecting which architecture patterns and styles would fit the problem domain, and creating components (the building blocks of the system). The artifacts created from these activities are then handed off to the development team, which is responsible for creating class diagrams for each component, creating user interface screens, and developing and testing source code.
-
A software architect must
have a significant amount of technical breadthto think like an architect and see things with an architecture point of view.
Architects also need to balance their knowledge. They shouldn't spread themselves too thin trying to learn everything, but they also shouldn't focus too narrowly on just one thing. Finding the right balance between knowing a lot about a few things (depth) and knowing a little about many things (breadth) is important for their career growth.
-
Thinking like an architect is all about seeing trade-offs in every solution, technical or otherwise, and analyzing those trade-offs to determine what is the best solution.
There are no right or wrong answersin architecture—only trade-offs.
Thinking like an architect is analyzing these trade-offs, then asking “which is more important: extensibility or security?” The decision between different solutions will always depend on the business drivers, environment, and a host of other factors.
-
This is a challenging task that requires the architect to have
some level of business domain knowledgeandhealthy collaborative relationships with key business stakeholders. -
-
Avoid the Bottleneck Trap:delegate writing critical code to developers, and focus on software architecture.
-
Proof-of-Concepts (POCs):try out different solutions to see which one is the best
-
Tackling Technical Debt:fix small issues (technical debt) in the codebase, keeping things running smoothly.
-
Bug Fixes:fixing bugs makes understanding where the weaknesses are in the codebase and how to improve them.
-
Automation:creating command-line tools and analyzers for day-to-day tasks, or using fitness functions.
-
Each of a set of standardized parts or independent units that can be used to construct a more complex structure.
-
It is a measure of how related the parts are to one another.
-
Every part of the module is related to the other, and the module contains everything essential to function.
-
Two modules interact, where one outputs data that becomes the input for the other.
-
Two modules form a communication chain, where each operates on information and/or contributes to some output.
the sum of the sets of
methods not shared via sharing fields
-
-
-
number of
incoming connectionsto a code artifact (component, class, function, etc.) -
number of
outgoing connectionsto other code artifacts
-
the ratio of abstract to concrete artifacts
-
the ratio of outgoing to all coupling
-
relationship between abstractedness and instability
-
-
Two components are connascent if a change in one would require the other to be modified in order to maintain the overall correctness of the system.
-
-
Connascence of Name (CoN): เปลี่ยนชื่อ
-
Connascence of Type (CoT): เปลี่ยนเดต้าไทป์
-
Connascence of Meaning/Convention (CoM/C): เปลี่ยนกฎที่คนส่วนใหญ่ยึดตาม
-
Connascence of Position (CoP): เปลี่ยนลำดับพารามิเตอร์
-
Connascence of Algorithm (CoA): เปลี่ยนขั้นตอนวิธีการทำงานของโค้ด
-
-
-
Connascence of Execution (CoE): เปลี่ยนลำดับคำสั่ง
-
Connascence of Timing (CoT): เปลี่ยนเวลาในการทำงาน เช่น race condition, asynchronus
-
Connascence of Values (CoV): เปลี่ยนค่าไม่ครบทุกส่วนที่ระบบต้องการ
-
Connascence of Identity (CoI): เปลี่ยนการอ้างถึงออบเจ็กต์ไม่ครบทุกส่วนที่ระบบต้องการ
-
-
-
- Strength: ทำให้ง่ายต่อการ refactor code
- Locality: ระยะห่างของ connascence ที่เกิดขึ้นระหว่าง component มีผลต่อความเสียหายของระบบ
- Degree: ยิ่งมี connascence ที่มากหรือสูง โอกาสเกิดความเสียหายก็เพิ่มตาม