search

anitsh / til

Today I Learn (til) - Github `Issues` used as daily learning management system for taking notes and storing resource links.
https://anitshrestha.com.np
MIT License
78 stars 11 forks source link

Software Architecture #176

Open anitsh opened 4 years ago

anitsh commented 4 years ago

image

Business goals are the foundation on which software systems are justified, analyzed, and built. Software systems are constructed to realize business or mission goals. Software architecture is the bridge between the business goals and the realized system. Those claims about business goals underlie many methods for designing and analyzing software architectures. However, precisely eliciting and characterizing business goals has always been problematic. Business goals come in many forms and at many levels of abstraction, and the stakeholders of the system are usually not accustomed to making goals explicit.

The quality and longevity of a software-reliant system is largely determined by its architecture.

What Is an Architecture?
Informally, an architecture is the blueprint describing the structure of a system.
Formal Definition - “The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software components, relations among them and properties of both.”

image

"Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." - Grady Booch

"Every software-intensive system has an architecture. In some cases that architecture is intentional, while in others it is accidental. Most of the time it is both, born of the consequences of a myriad of design decisions made by its architects and its developers over the lifetime of a system" - Grady Booch

"Check capabilities, not ingredients." - Gregor Hophe

“Architecture is selling options.”- Gregor Hophe

"An architecture picture without lines or an architecture defined by a bill of material, raise your hand and proclaim that this isn't an architecture discussion at all" - Gregor Hophe

Good Architecture Starts With Modularity It is generally a good architectural practice to make the code base more modular, more manageable. Start with the data and pay close attention to how they’re being accessed. Make sure each module/service owns and controls access to its own data, and that data access only happens through clearly defined API contracts.

Start #344 #192 #439 #462

Remember YAGNI!

image image image image image

The pattern-analysis scoring for some of the architecture patterns. This summary will help you determine which pattern might be best for your situation. For example, if your primary architectural concern is scalability, you can look across this chart and see that the event-driven pattern, microservices pattern, and space-based pattern are probably good architecture pattern choices. Similarly, if you choose the layered architecture pattern for your application, you can refer to the chart to see that deployment, performance, and scalability might be risk areas in your architecture.

image

While this chart will help guide you in choosing the right pattern, there is much more to consider when choosing an architecture pattern. You must analyze all aspects of your environment, including infrastructure support, developer skill set, project budget, project deadlines, and application size (to name a few). Choosing the right architecture pattern is critical, because once an architecture is in place, it is very hard (and expensive) to change. - Mark Richards, Software Architecture Patterns

Architecture Decision Template image

Look for code and data that are often changed and deployed together to determine features or functionalities that are more tightly coupled. Use these as natural groupings for what can be iterated on and deployed independently from other areas.

Resource

Architectural Paradigms

Architecture Decision Records

anitsh commented 3 years ago

Back to basics: For wanna be architects, when building system and services, always start with a system context diagram. Don't fall into trendy stuff like micro-services, kubernetes, big data, AI or cloud-native at onset. A system context diagram looks basic, simple and obvious. Context diagrams should be non-technical so that everyone in the team can understand it. In my experience I found SCD to be very helpful in uncovering user personas, roles, information flow and system boundaries.

systemsdesign #architecture #microservices #enterprisearchitecture

As per wikipedia : A system context diagram (SCD) in engineering is a diagram that defines the boundary between the system, or part of a system, and its environment, showing the entities that interact with it.[2] This diagram is a high level view of a system. It is similar to a block diagram.

https://www.linkedin.com/posts/ajaykhandelwal_systemsdesign-architecture-microservices-activity-6742943530420887552-wura

anitsh commented 3 years ago

4 principles to guide successful architects and architecture

1. Contextual Understanding Over Siloed Decision Making

It is rare that a decision can be made without consideration of any trade-offs. Often, the quality of a decision is directly impacted by the experience and knowledge of the person that made it. The caution here is to avoid being an aloof architect. An aloof architect is someone who makes decisions based solely on one’s own experiences and siloed considerations. An aloof architect typically has good intentions but will miss important considerations and that inevitably leads to flawed decision making. Rather, be an aware architect. An aware architect provides context from many different perspectives, ranging from business to technical, across different disciplines and subject matter domains. An aware architect is always learning and able to bring in their context to inform the decision making process. An aware architect is also self-aware in understanding his or her own limits, and will bring in additional expertise as needed to supplement their own contextual understanding. Decisions made with contextual understanding are likely to be less brittle and more sustainable than otherwise. This is key in architectural decision making since, while architectures do evolve over time, changing certain architectural decisions after implementation can be very painful and very difficult. Enabling flexibility as an outcome is key to evolutionary architecture.

2. Tangible Direction Over Stale Documentation

The adage that a picture is worth a thousand words is still true, and having a reference architecture document that multiple parties can use to understand their proposed target state is also useful. The caution here is to avoid being an archaeological architect. An archaeological architect is someone stuck in the cycle of documenting current state and forever updating current state as the delivery teams continue to release. This is a trap of reactive thinking and offers very little value. Rather, be an ambitious architect. The ambitious architect is someone who upholds the documentation focus to be on the proposed future, and the decisions made to define that future, to sustain consistent thinking for posterity. This allows for the right kind of conversations and deliberations to be proactive and strategic. To point out what is feasible and what is a constraint, and to formulate a tangible plan to overcome challenges to achieve the proposed target. This kind of conversation and partnership is key to the success of the architect.

3. Driving Behavior Over Enforcing Standards

While an important outcome of architecture strategy is standardization and re-use of patterns, technologies, and solutions, that doesn’t mean that architects should strive to only be enforcers of standards. The caution here is to avoid being the administrative architect. An administrative architect is someone who focuses on compliance to the rules and regulations to the detriment of everything else. Rather, be an ambassador architect. An ambassador architect is someone who understands the rules and regulations, the acceptable proven patterns and solutions, to guide the delivery teams on the expectations of adherence. This position allows for driving the right behaviors with the flexibility for delivery teams to innovate within the guardrails that are laid out in the pursuit of safety and security. An ambassador architect is someone who is also willing to listen to feedback, and able to relay that feedback into improving the standards. Evolving standards and challenging the status-quo based on reality and innovation is necessary to improve the overall architecture guidance.

4. Evolution Over Frameworks

A good framework can provide a re-usable, clear methodology for solving problems and enabling consistency. The caution here is to avoid being an afraid architect. An afraid architect is someone who performs rigidly by the details of expansive frameworks to try to output what is needed. This is problematic in that it does very little to move the needle strategically. A strategy will be produced, yes; but it likely will not offer as many benefits as it could. Rather, be an audacious architect. An audacious architect understands the framework well enough to focus on its value driven output. An audacious architect can evolve the framework itself if needed and moreover understands that architecture solutions can evolve over time. Embracing change to inform better architectures can be risky, yet it is often a risk well worth taking. An audacious architect is always learning and keeps skills and knowledge of business and technology up to date.

anitsh commented 3 years ago

"

Make architecture fit for purpose

Often, we look to the architect to give us a "good" architecture. The catch is that architecture is rarely good or bad - it's either fit or unfit for purpose. The purpose is usually dependent on the context in which the system will live rather than specific user requirements. An architect's job therefore is to consider architecture options in a broader context, which can involve diverse factors such as commercial and legal agreements, skills availability, or an installed base.

An architect's job includes creating transparency on ramifications and to involve all levels in the architectural trade-off.

Even with all consideration, making architecture decisions is hard and runs a certain risk of getting it wrong. It’s therefore best to have decisions made by those people who have to live with the consequences.

Validate decisions through feedback loops

A well-known architecture department anti-pattern is the “ivory tower”: architects sit in the penthouse to define how developers should design and build software, without developing any software themselves. Such a setup has one cardinal flaw: it doesn't provide feedback to the architects as to the effectiveness nor the cost of their decisions. Worse yet: some architects quite enjoy themselves not having to deal with those consequences.

Most complex systems can only function by means of feedback loops.

Feedback loops apply to both project steering and architecture: predicting project cost and timeline becomes much easier once the team velocity is known, and allows for making necessary adjustments along the way. Architects should find out whether "reusable" APIs really fostered reuse, whether common frameworks sped up development, or whether the monitoring framework reduced unscheduled downtime. Understanding feedback requires identifying clear metrics and goals, which can be a useful exercise in its own right.

A great way for architects to obtain feedback is to be directly involved in, and accountable for, project delivery. Feedback cycles are most effective when they are short and immediate, making it appealing to empower development teams to make architecture decisions, within agreed-upon bounds of general principles or a published IT strategy.

" - Gregor Hophe

Detailed note - #538