I watched recently a LinkedIn Learning video about software architecture foundation (https://www.linkedin.com/learning/software-architecture-foundations), Author is Allen Holub. Below are my notes from the presentation.
Software Architecture is design of the complete system. The architects figure out what will suit the customer and tailor it to the business domain. The closer the business is to the architecture, the better. It’s similar to what an architect of building does, they think of where to place the wall, which side of the building will face the sun, but they don’t think about what kind of wall to use or what materials because that is implementation.
There are two types of Software Architect:
- Traditional Architect
Similar to the movie Matrix, the traditional architect will draw the diagram and how all the components are working together.
Drawbacks of Traditional Architect:
- Big and complex design - Code is written after the design. Doesn’t capture the true user’s needs and doesn’t allow for learning.
- Lack of flexibility - Painful bureaucratic processes. Not following the design. Random improvisation.
- Slow development process — Centralized architect decision making. Wasted time and money.
2. Modern Architect
Agile world has no place for big upfront design. Write an experiment. If it succeeds, continue, else, throw it out.
Cost of building the wrong thing is much higher than the cost of rebuilding.
In Agile, everyone is an architect. Nobody asks permission to experiment. In traditional, single architect. Architect controls permissions.
Agile Architect (Servant Leader) works on support role — Teaching, Coaching and Coordinating. Main design responsibility:
- Assures coherence across the system
- Reviews work
- Makes suggestions and helps refine processes.
An agile architect doesn’t give solution, rather, he/she gives them alternatives and what to choose from. An architect’s job is for team to make good decisions, not make decisions for them.
Tool: Inspect and Adapt Loop
- Ideally a two-day maximum cycle
What makes a good agile architect?
- Helps the team evaluate the design and implementation. Goal is to make a useful software. Watch actual customers use the software.
- Teach architecture to the team. (eg: Reactive Systems)
- He/she is not sitting on an ivory tower. He/she works collaboratively on the whole organization and work on an evolving architecture.
- Spread the architecture around so everyone can make the best architecture possible.
What skills do you need?
- Get solid at programming. Sometimes you just need to get your hands dirty and do it. You learn about good architecture from exposure to other systems — simplicity, maintainability, testability.
- Design patterns provide set of optimal solutions. Architecture is the interaction of design patterns. The more system you work with, the more you understand tradeoffs.
- Communication and presentation skills
How to improve Technical Understanding
- Read code
- Study open-source projects
- Form a study group — reading code, how would you improve it? what if there is new requirement, what will be the change?
- Go to vendor-focused conferences
- Speak to other architects
- Join meet ups and solve problems
- Create your own project and implement the system. Learn from it. Mantra is to build one to throw away.
Thinking Architecturally
Silos is a way of control inside your code. N-Tier System are layered same way as the organization.
Talking between silos is inefficient. Take for instance requesting for a change:
Working -> Waiting -> Working -> Waiting ->Working
Waiting for the changes in database to complete, wait for the business logic, wait for the UI. The wait time builds up and so is the time to complete.
Agile is work that involves in the business domain. Find a very narrow piece of work and find everything you need to deploy that.
Story — A description of the user’s work — A story touches every piece of the system.
Conway’s Law — Change the structure of the organization to match agile methods. Build a team that can work on that story. The architecture must map the domain of the problem you’re solving.
Design Incrementally
Big Up-front designs (BUFD)
- Database | Business Logic | User Interface
Agile Incremental Designs
- Technology | Stories | Customer
- As system upgrades, technology decision is done upgrade (last responsible moment) approach is driven by the needs of the user not by technology.
Incremental Design — Domain Driven Design
Structure of the story reflects structure of the business. Modules reflect the business.
Context differs depends on the business. Bounded Context limits the change to the submodule (eg: Storefront). Isolate the agent (eg: object). Think about how your agent communicate.
Agent Technologies
- Messaging — simplify communication across the network
- Caching — store data locally in memory instead of in a slower and harder to access database
- Logging — track what your program does as it works
- Monitoring — observe how your program uses system resources as it works
Architect knows how to ask the right questions or research about it. Talks to programmers, vendors, conferences, operations. Research is part of the job; Should I go for big vendor or open source? Explore open source and free software solutions. Avoid being forced into a specific ecosystem.
A design process: brief introduction
Requirements gathering:
- Defining and writing the Problem statement
- Describes the end user’s problem
- Describes the solution to the problem in terms of problem domain
“My problem is that I’m not influential enough in my field. To become more influential, I need to write articles that people will actually read and I need to get people to read them. I also need to make sure that those articles actually build influence.”
“My problem is that the meetings I attend are often a waste of time. Before I commit to going to a meeting, I want to make sure that there’s a reasonable agenda, and I won’t go if the right people aren’t in the room. I don’t really care when or where the meeting is, provided that it happens in the next couple weeks”
2. Developing the user stories
User Story do not describe a computer program. User story describe the users work (not yours).
User Story describes an end user going through a domain-level process to achieve some valuable outcome. User doing some role in a domain level work.
“To make sure that authors can get the feedback they need, readers need a way to submit comments about their articles and authors need a way to respond.”
“To make sure that the discussion stays civil and relevant, editors need to be able to approve or reject comments on specific articles.”
3. Defining the structure / Refine story
Horizontal Slicing Story
- UI | Logic | Database
- You need to wait for the UI to finish before development starts
Vertical Slicing Story by narrowing the scope:
- Every path thru workflow isolation
- Event Storming
Design Pattern
If you understand design patterns, name and the context on how it is used, you won’t be flailing around trying to think of what to do. With patterns, You need to understand the purpose not it’s structure
Your implementation will be unique yet the underlying architecture is well understood.
Monoliths
- Everything works efficiently because it works in a single instance. Challenges are long test and deploy process. Functionalities are like a big ball of mud.
- Cost of maintaining monolith is higher after certain point. Your competitors won’t wait for you to do your changes. When you rebuild, make the system better. Fix those long standing issues.
Microkernel (plugin) architecture
- Small standalone plugins. May be used to monitor small kernel applications.
- Some challenges plugins are indirectly coupled through the kernel and APIs to the kernel are delicate.
- Example: Health Monitoring, Self-Healing, Rolling Upgrades
Message-based architectures
- controls the flow of communication by using a shared messaging infrastructure
- Pub/Sub Model — Publisher publish a topic. A broker receives the messages and distribute to their subscribers.
- Example: Legacy applications -> Adapters -> Messaging infrastructure
Microservices and miniservices
- Small services that collaborate with each other as peers to make the job done
- Few hundred of codes and independently deployable.
- Fully autonomous and hide all the implementation details (Logic, Web server, Database). Distributed — can work in unreliable network. It can fail anytime. Highly observable so logs are important. Modeled around business concepts.
- Microservices and messaging pattern are usually intermingled.
- The challenges are design and runtime complexity. Speed hit, networks are just slow compared to alternatives.
- Recommended book: Building Microservices: Designing Fine-Grained Systems by Sam Newman
Reactive and choreographed systems
Declarative System
- Synchronous services — You expect all calls to be successful. One of which might fail and your service call will thereby fail too.
- Asynchronous service — you have to wait for all the services to complete. Latency or wait time issue.
Reactive System
- Reactive system does not know any implementation details of the downstream. It broadcast to the world that something has to be done.
- Decoupled approach. Add additional down stream clients as needed. You don’t need to know how the subscribers implementation is.
- Works in a monolith
Further Reading:
- Holub on Patterns: Learning Design Patterns by Looking at Code by Allen Holub
- Attend conferences like https://www.oreilly.com/conferences/
