Software Architecture and Design - Goals, Principles and Some Key Considerations

My Article , Grady Booch, Kurt Bittner, and Rich Reitman derived and refined a definition of architecture predicated on work by Mary Shaw and David Garlan (Shaw and Garlan 1996). Their definition is:

"Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is made up; behavior as specified in collaboration the type of elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns."

In Patterns of Enterprise Application Architecture, Martin Fowler outlines some typically common recurring themes when explaining architecture. He identifies these themes as:

"The highest-level breakdown of something into its parts; the decisions that are Hard to change; there are multiple architectures in something; what is architecturally Significant can change over a system's lifetime; and, ultimately, architecture boils Down to regardless of the important stuff is."

Software application architecture may be the process of defining and creating a solution that is well structured and meets all the technical and operational requirements. The architecture should be able to consider and improve upon the common quality attributes such as performance, security, and manageability.

The main focus of the program architecture is the way the major elements and components in a application are used by, or connect to, other major elements and components within the application form. Selecting data structures and algorithms or the implementation information on individual components are design concerns, they are no architectural concerns but sometimes Design and Architecture concerns overlap.

Prior to starting the architecting of any software, there are some basic questions that people should make an effort to get answers for. They're as follows:

How the users of the system will be interacting with the system?

How will the application be deployed into production and managed?

What are the various non-functional requirements for the application, such as for example security, performance, concurrency, internationalization, and configuration?

How can the application form be made to be flexible and maintainable over time?

Do you know the architectural trends that may impact the application now or after it's been deployed?

Goals of Software Architecture

Building the bridge between business requirements and technical requirements may be the definitive goal of any software architecture. The goal of architecture is to identify the requirements that affect the basic structure of the application. Good architecture reduces the business enterprise risks associated with creating a technical solution while a good design is flexible enough in order to handle the changes that may occur over time in hardware and software technology, in addition to in user scenarios and requirements. 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.

Principles of Software Architecture

The basic assumption of any architecture should be the belief that the design will evolve over time and that certain cannot know everything one need to know up front. The look will generally have to evolve through the implementation stages of the application form as one learn more, and as one tests the design against real world requirements.

Keeping the above statement at heart, let's try to list down a number of the Architectural principles:

The system should be built to change rather than building to last.

Model the architecture to investigate and reduce risk.

Use models and visualizations as a communication and collaboration tool.

The key engineering decisions should be identified and acted upon upfront.

Architects should consider utilizing an incremental and iterative approach to refining their architecture. Focus on baseline architecture to get the big picture right, and evolve candidate architectures as you iteratively ensure that you improve one's architecture. Usually do not try to get it fine the first time-design just as much as you can so that you can start testing the look against requirements and assumptions. Iteratively add details to the look over multiple passes to be sure that you obtain the big decisions right first, and focus on the details. A standard pitfall is to dive in to the details too quickly and obtain the big decisions wrong by making incorrect assumptions, or by failing woefully to evaluate your architecture effectively.

When testing your architecture, think about the following questions:

What were the main assumptions that were made while architecting the system?

What are the requirements both explicit and implicit this architecture is satisfying?

What are the key risks with this architectural approach?

What countermeasures are in place to mitigate key risks?

In what ways is this architecture an improvement over the baseline or the last candidate architecture?

Design Principles

When getting started with Software design, one should keep in mind the proven principles and the principles that adheres to minimizes costs and maintenance requirements, and promotes usability and extensibility. The main element principles of any Software Design are:

Separation of concerns: The main element factor to be kept in mind is minimization of interaction points between independent feature sets to attain high cohesion and low coupling.

Single Responsibility principle: Each component or module should be independent in itself and responsible for just a specific feature or functionality.

Principle of Least Knowledge: A component or object should not find out about internal details of other components or objects.

Don't repeat yourself (DRY): The intent or implementation of any feature or functionality ought to be done of them costing only one place. It should never be repeated in a few other component or module

Minimize upfront design: This principle is also sometimes referred to as YAGNI ("You ain't gonna need it"). Design only what is necessary. Especially for agile development, one can avoid big design upfront (BDUF). If the application requirements are unclear, or when there is a possibility of the look evolving over time, one should avoid making a large design effort prematurely.

Design Practices

Keep design patterns consistent within each layer.

Do not duplicate functionality within an application.

Prefer composition to inheritance. If possible, use composition over inheritance when reusing functionality because inheritance increases the dependency between parent and child classes, thereby limiting the reuse of child classes. This reduces the inheritance hierarchies, which can become very difficult to handle.

Set up a coding style and naming convention for development.

Maintain system quality using automated QA techniques during development. Use unit testing and other automated Quality Analysis techniques, such as for example dependency analysis and static code analysis, during development

Not only development, also consider the operation of your application. Know what metrics and operational data are needed by the IT infrastructure to guarantee the efficient deployment and operation of one's application.

Application Layers: While architecting and designing the machine, one needs to carefully think about the various layers into which the application will be divided. There are a few key considerations that need to be kept in mind while doing that:

Separate the areas of concern. Break the application into distinct features that overlap in functionality less than possible. The main benefit of this approach is that a feature or functionality can be optimized independently of other features or functionality

Be explicit about how layers communicate with one another.

Abstraction ought to be used to implement loose coupling between layers.

Do not mix several types of components in exactly the same logical layer. For example, the UI layer shouldn't contain business processing components, but rather should contain components used to take care of user input and process user requests.

Keep carefully the data format consistent inside a layer or component.