Amin SAIGHIThe worst thing you can do is to following technology, and changing it for each project.
Work with the best technology you feel good, and improve your knowledge on it.
Algorithm, data structure, software architecture and all best approach are good for your career.08:25 AM - 11 Oct 2020
Steffan Norberhuis@snorberhuisSoftware Architecture in blogs and university is clean and aesthetics. You can make the best choices with full knowledge. In the real world, your client hires you 6 months in with choices made. Another team only needs 1 API call to finish their epic, but it breaks encapsulation.10:03 AM - 10 Oct 2020
Part Name Description 01 Software Architectural Thinking for Developers From the perspective of a developer, architects see it differently. There's more to design philosophy than simply thinking about architecture. From an architectural mind, this is seeing things. 02 Architecting Modules for Software Modularity Computer architecture modularity has proved slippery to describe. For architects, recognizing modularity in the architecture platform of choice is important. 03 Building An Architectural Character for Modern Software Architect A company aims to address a specific problem, then a list of requirements is collected. For the exercise of requirements gathering, a broad range of techniques exists. 04 Identifying An Architectural Character for Modern Software Architect Up Next: October 31-November 1, 2020
From the perspective of a developer, architects see it differently. There's more to design philosophy than simply thinking about architecture. From an architectural mind, this is seeing things. It's about recognizing the distinction between design and architecture and learning how to work with production teams. It also means understanding the value of company drivers and how they translate to architectural problems.
Thinking as an architect is understanding the contrast between development and architecture. It's knowing how the two work together together to create solutions to organization and technological challenges.
Figure 1-1. Traditional view of architecture versus design
Consider Figure 1-1 (Above), which illustrates the traditional responsibilities an architect has, as compared to those of a developer. As shown in the diagram, to establish design elements, an architect is responsible for evaluating market criteria. Then the objects produced from these operations are handed to the production team. It's the duty of developers to build user interface screens and improve source code.
There are several issues with the traditional responsibility model illustrated in Figure 1-1 (Above). The architecture is isolated from the development teams in this model and, as such, the architecture only provides what it was initially designed to do. Both the concrete and virtual walls that remain between architects and developers must be torn down to make architecture work. Even choices an architect makes never make it to the production team:
Figure 1-2. Making architecture work through collaboration
The architect and developer must be on the same virtual team to make this work, as depicted in Figure 1-2. Architects can provide developers on the team with mentoring and coaching. The architecture of today's applications moves and expands, unlike the old-school waterfall approaches to software architecture. For the success of every software project, a close partnership between the architect and the production team is necessary.
Developers and architects vary in the extent of technical detail. A software architect must have a tremendous degree of technical depth, unlike a developer. The knowledge pyramid below shows this:
Figure 1-3. The pyramid representing all knowledge
methods that a technologist uses every day contain stuff you know. Stuff you know you don't know contains things that a developers knows, but has no experience in them. The early career of a developer focuses on extending the pyramid 's tip, to gain knowledge and experience. The middle segment is expanded by expanding the top; as developers experience more innovations, it adds to their stock of stuff you know.
Figure 1-4. Developers must maintain expertise to retain it
In Figure 1-4, expanding the top of the pyramid is beneficial because expertise is valued. The stuff you know is the stuff you have to maintain, too. It takes time to invest in the stuff at the top of the pyramid to retain knowledge. The scale of the top is, essentially, their professional depth. An architect provides a deep knowledge of technology and how it can be applied to address practical issues. The middle section penetrates into the bottom section represents an architect’s technical breadth, as shown below:
Figure 1-5. What someone knows is technical depth, and how much someone knows is technical breadth
As an architect, the value of width is greater than depth. Architects need to make choices that balance technological constraints with skills. Thus, for an architect, the wise course of action is to sacrifice some hard-won expertise, as shown below:
Figure 1-6. Enhanced breadth and shrinking depth for the architect role
There will be some fields of competence remaining, while others will atrophy (cast away). Developers moving to the role of architect can have to adjust the way they approach the learning of information. In order for them to have a greater quiver, architects should concentrate on technological breadth. It is something any developer should think during their career to align their portfolio of expertise about depth versus breadth. The pyramid of expertise demonstrates how different the function of the architect is compared to the developer. We also see this in major corporations where developers who have moved to leadership positions are already making technology choices using old standards known as Frozen Caveman Anti-Pattern (See on Wikipedia).
Note (📝): By the way, the Frozen Caveman Anti-Pattern describes an architect who always reverts back to their irrational concern for every architecture.
In each approach, architecture is all about seeing trade-offs. The common answer to any question about architecture is that it depends. It depends on the climate of implementation, business drivers, business atmosphere, budgets, timeframes, capability set for developers, and hundreds of other variables. The setting, condition, and dilemma of each is different, hence why architecture is so difficult. Now, consider an
auction system, as illustrated below:
Figure 1-7. Auction system example of a trade-off—queues or topics?
Bid Producer generates a bid and then sends that bid to the
Bid Tracking, and
Bid Analytics. Which solution should the architect use? For each choice, architectural thought allows the architect to evaluate the trade-offs and choose the best. Using queues or using a topic might do this. The two options for the auction system are shown below:
Figure 1-8. Use of a topic for communication between services
Figure 1-9. Use of queues for communication between services
The simple approach to this issue is one of extensibility of architecture. Unlike the queue solution where the
Bid Producer has to connect to three separate queues, the
Bid Producer only requires a single link to a topic. It could simply subscribe to the topic when the new
Bid History is created. However, a new queue would be required in the queue option and the
Bid Producer would need to be changed. When inserting new bids, using queues requires major improvements to the method. No improvements in the current infrastructure are expected for the topic strategy at all.
Architectural thinking is looking at the positives of a given solution, but also analyzing the negatives. An architect of software will evaluate the negatives of the approach to the subject. Bidding data can be obtained by anyone while evaluating a topic. In the queue model, it is just the individual user who can access the data sent to the queue.
Wiretapping (spying) into a topic, but not a queue, is quite easy.
In addition to the safety dilemma, only homogeneous contracts are provided by the subject solution. Both facilities have to accept the same. In this situation, it will be necessary to change the contract, disrupting all other facilities. This will be a different channel in the queue model, thus a distinct contract.
Monitoring of the number of messages in the topic is not supported by the topic model. With the queue alternative, however, it is possible to independently track each queue. The better option, provided a trade-off analysis, which is better?
Topic advantages Topic disadvantages Architectural extensibility Data access and data security concerns Service decoupling No heterogeneous contracts Monitoring and programmatic scalability
It will still rely on the market drivers, the environment, and other variables to determine between different solutions. These trade-offs are examined by thinking like an architect, then questioning which is more relevant.
Thinking like an architect is identifying the market drivers that are needed for a system's success. Architects need to have a degree of understanding of the company domain and safe, constructive stakeholder partnerships.
Architects of software must combine software architecture with hands-on coding. Stop the bottleneck trap by avoiding the possession of code in a project's vital path. The code in the context of a project will become a bottleneck for the team. This is because the architect is not a full-time developer, so the role of the developer and the role of the architect must be balanced.
Delegating the vital path and application code to the production team is one means of escaping the bottleneck trap. But not being a drain on the team, Architect gains hands-on experience writing production code. The architect writes the same source code as the production teams and is thus best able to recognize the discomfort they can face.
Architects of software ought to be hands-on but ensure technological depth. How does a software engineer also retain a certain degree of?
The first approach is to do periodic proof-of-concepts (POCs). Not only does this method enable the architect to write source code, but it also tends to justify an architecture judgment. POCs are a helpful way to compare the specifics of implementation and the amount of effort needed for the complete solution to be created. The architect can write the best production-quality code they can, whenever feasible, wherever feasible. The code goes into the archive of source code and becomes the leading template to be pursued by others.
Tackling some of the technological debt stories is another way an architect can stay hands-on. These stories are typically low priority, because if the architect does not have the ability within a given iteration to complete a technological debt stories, it does not affect the iteration 's progress.
Automation will support the production team with its everyday activities. In order to ensure that the architecture complies, automation may take the form of architectural analysis. Look for repeated tasks that are carried out by the team and simplify the process. The production team would be grateful, say experts, for the automation. By doing regular code reviews, the architect can stay hands-on as an architect.
We spoke about architectural thinkin in Part 01, which requires a broad understanding. We have looked at the two-solution trade-off, choosing one solution, and leaving the rest. And then, we're looking at ways to reconcile being an architect with hands-on coding.
- Software design and modeling languages: https://www.lynda.com/Developer-tutorials/Software-Design-Modeling-UML/2812131-2.html
- Speak the Language of Application Architecture: https://www.freecodecamp.org/news/speak-the-language-of-application-architecture/
- 10 Common Software Architectural Patterns in a nutshell: https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013