Software Architecture

From MyInfoRepo
Jump to navigation Jump to search

Topics covered by this course are: fundamentals of software architectures, modeling and designing software architectures, architectural patterns and styles, architecture viewpoints and perspectives, the role of the software architect, analyzing and evaluating software architectures, component and plug-in frameworks, software product lines, service oriented architectures, code quality, technical debt, refactoring.

Software Architect: what is it

suggested vid:


We look at the responsibilities of architects, to see how they should operate. Architects carry overall responsibility for all technical decisions in an organization. They will lead the organization to take the right decisions, this includes a responsibility to communicate well with people inside the organization. It is a leadership role, beside the technical role, they have to be able to take action when needed and keep processes organized. Architects should also see when a decision has to be held off and taken at a more appropriate time.

Consequently, architects have to posses the skills to solve hard problems to see where the biggest complications are. They should promote good practice in their field, to make sure the team produces quality output. The impact of decisions should be well understood by the architect before one is made. After it was made, they should be able to defend the design decision and make sure any releases contains the appropriate update. The architect should have technical skill, to know and understand relevant technology. One should be able to evaluate and influence the choice of 3rd party frameworks.

Architects are also quite important in business impact, they should know impacts of decisions. It used to be that problem domains were mapped to solution domains, which tends a bit to the waterfall approach. It may be better to look at capabilities of the software and turn those toward new business opportunities. They should be able to translate technical risk into business risk, going hand in hand with switching technical and business perspectives. Cost vs speed and other factors are examples of these risks.

Architects have to be good communicators, they are an essential contact for product managers, stakeholders, developers and other teams and relations. The architect creates a shared story, which is a representation of the product vision that can be shared in different levels of abstraction with all types of contacts. This shared story should clearly explain the product, it should be simple and concise. A credible roadmap should support the story, as well as a good architectural foundation. The product manager and architect work closely together on this.

Change is an important part of software designs and organizations. Architects should enable and embrace change. You want to introduce change in an early stage, anticipating change, and deferring change-blocking decisions. Dev-ops, CI/CD are important tools to make sure rapid change is possible.

Sam Newmans ideas about architects: CDNtvdg.png