DEV Community

Cover image for Software Architectural Thinking for Developers [Part 1]

Software Architectural Thinking for Developers [Part 1]

workpebojot profile image Edison Pebojot(πŸ‘¨β€πŸ’») ・Updated on ・9 min read

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

Introduction (☝️)

Alt Text

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.

Architecture versus Design (πŸ’€πŸ˜ƒ)

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.

Alt Text

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:

Alt Text

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.

Technical Breadth (πŸ’­πŸ”)

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:

Alt Text

Figure 1-3. The pyramid representing all knowledge

Technologies, systems, cultures, and 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.

Alt Text

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:

Alt Text

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:

Alt Text

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.

Analyzing Trade-Offs (βœ…βŒ)

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:

Alt Text

Figure 1-7. Auction system example of a trade-offβ€”queues or topics?

The Bid Producer generates a bid and then sends that bid to the Bid Capture, 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:

Alt Text

Figure 1-8. Use of a topic for communication between services

Alt Text

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.

Understanding Business Drivers (πŸ”₯πŸ”₯)

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.

Balancing Architecture and Hands-On Coding (πŸ‘ŒπŸ’»)

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.

Summary (πŸ“šπŸ“š)

Alt text

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.

Learn More (πŸ“•πŸ“™)

Up NextπŸ‘‰ Part 02: Architecting Modules for Software Modularity πŸ”₯ πŸ”₯ (October 18-19, 2020)

Alt text

Discussion (0)

Editor guide