¿What is Software Architecture?

¿What is Software Architecture?

1. WHAT

   • Is the process of defining a structured solution that meets all of the technical and operational requirements , while optimizing common quality attributes such as performance, security, and manageability
   • the software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural
   • The Architecture focuses on how the major elements and components within an application are used by, or interact with, other major elements and components within the application
   • Application architecture seeks to build a bridge between business requirements and technical requirements by understanding use cases, and then finding ways to implement those use cases in the software.
   • the goal of architecture is to identify the requirements that affect the structure of the application.
   • An architect must consider the overall effect of design decisions, the inherent tradeoffs between quality attributes (such as performance and security), and the tradeoffs required to address user, system, and business requirements. Keep in mind that the architecture should: • Expose the structure of the system but hide the implementation details. • Realize all of the use cases and scenarios. • Try to address the requirements of various stakeholders. • Handle both functional and quality requirements.

2. WHY

   • like any other complex structure, software must be built on a solid foundation. Failing to consider key scenarios, failing to design for common problems, or failing to appreciate the long term consequences of key decisions can put your application at risk
   • The risks exposed by poor architecture include software that is unstable, is unable to support existing or future business requirements, or is difficult to deploy or manage in a production environment.

3. HOW

   • He selection of data structures and algorithms or the implementation details of individual components are design concerns. Architecture and design concerns very often overlap.
   • ◄ Rather than use hard and fast rules to distinguish between architecture and design, it makes sense to combine these two areas. In some cases, decisions are clearly more architectural in nature. In other cases, the decisions are more about design, and how they help you to realize that architecture.
   • ◄ you will be able to construct architectural solutions that address all of the relevant concerns, can be deployed on your chosen infrastructure, and provide results that meet the original aims and objectives.
   • Good architecture reduces the business risks associated with building a technical solution, A good design is sufficiently flexible to be able to handle the natural drift that will occur over time in hardware and software technology, as well as in user scenarios and requirements.
   • • Market maturity: Take advantage of market maturity by taking advantage of existing platform and technology options. • Flexible design: Increasingly, flexible designs take advantage of loose coupling to allow reuse and to improve maintainability. • Future trends: When building your architecture, understand the future trends that might affect your design after deployment. • User empowerment: A design that supports user empowerment is flexible, configurable, and focused on the user experience. Consider the following key principles when designing your architecture: •Build to change instead of building to last. •Model to analyze and reduce risk. •Use models and visualizations as a communication and collaboration tool. •Identify key engineering decisions. •Consider using an incremental and iterative approach to refining your architecture.