Software development has a flagrant history of project failures and has earned an overall reputation as an unplanned, unorganized and naïve craft. Owing to that the questions of inefficient, less productive, less-scalable, and expensive products have been surfacing time and time again.
Unfortunately this negative reputation it has earned – has been achieved through a constant negligence from very basic things which should have been taken into account as the foremost effort of the software project/product engineering. This entails the incorporation of a comprehensive design paradigm right in the beginning – in fact before the development of the actual software.
The software Architecture and Design are two separate design paradigms to serve separate (but sometimes overlapping) requirements.
What is a Software Architecture?
Here are a few statements to elaborate what is a Software Architecture.
- A Software Architecture provides a blueprint for the proposed system. It provides an abstraction to manage the system’s complexity and establishes a communication and coordination mechanism among the constituent components, which themselves are the building blocks of the entire system.
- A Software Architecture is an elaborated plan that provides enough details to produce a software design. Architecture imposes constraints on Software Design to help achieve an organization’s business and technology objectives.
- A Software Architecture imposes big-picture constraints on the design to ensure that it aligns with the business domain of an organization. This includes considerations such as compliance, efficiency, coordination and technology standards.
- The Architectural view of a system is abstract which distills away details of implementation, algorithms and data representation and considering the behavior and interaction of elements inside the system. A software architecture is developed as the first step toward designing a system that has a collection of desired entities.
Many experts of the domain support the point that an Architecture includes a statement of stakeholders’ needs and a rationale for how those needs are met.
Software Architecting is essentially a decision-making process. Software Architect defines the architecture of the system and maintains its architectural integrity. He’s engaged in processes of creation, perfection, and destruction on an on-going basis. His responsibility consists of setting up standards for Software Designers and Developers – he keeps designing and interfacing new parts of the system with existing architecture, developing conducive interfaces to legacy systems, and occasionally creative destruction to pave the way for the optimized solution.
What is a Software Design?
A Software Design provides a design plan that depicts the elements of a system – how they fit, and work in a rather cohesive manner to fulfill the requirements of the system. This exercise is carried out after the domain- and requirements-analysis – and is followed by detailed design, coding, integration, testing and deployment.
So in general the Architecture and Design both elaborate the proposed ‘model’ but Architecture focuses on the abstract view of model while Design takes care of the detailed view and implementation. A Design is much more detailed and technical than Architecture. Architecture portrays the abstract view of the entire system in question whereas the Design illustrates the implementation of the constituent components. These components collaborate and work in conjunction and in effect, build up the entire system.
A couple of analogies will help us understand the categorical difference between the jurisdictions of Architectural and Design activities.
While designing a computer system the entire system; the motherboard, CPU, the system bus, memory slots, graphics card, hard disk drive and communications ports for the peripheral devices like USB, mouse, keyboard etc. is essentially called the Architect design. While architecting the system the engineer has to take into account all component parts, their adequate placement in the system, their collaboration with each other so that the entire system should work in unison and perform as desired. Each component should be perceived to be an essential part of the design and exquisitely contribute to the functioning of the system. On the other hand each individual component of the system such as a CPU entails to be designed separately. A CPU with its particular specifications; internal circuitry, processor cores, number of transistors and registers etc. requires a highly expert design and therefore, such sophisticated components are designed by the companies that are expert in manufacturing the micro-processor chips. So in the eyes of the system architect the design of the CPU is a part of “Design”. Likewise other component parts like system bus, memory chips, peripheral devices etc. will require a Design activity of their own.
If you were to build a house, the foremost design level asks questions like ranch or multi-story? Tudor, Queen Anne or Cape Cod? How many bedrooms? Which direction do the bedroom windows face? Hot-Water heat or Forced-air? Floor plan Open concept or Closed? Multi-material Façade? These questions also consider somewhat on details, but they’re much more about the style and overall design of the house, rather than things like 12- or 14- gauge wire for the electrical system, diameters of water pipes
or the dimensions of the air conditioning duct-work. This focus on type of style is what Software Architecture is all about. In essence, you need the foundation (architect) before you can design and build the rest of the structure (design).
In the realm of Software Development the Architecture provides abstraction and information hiding so that all stakeholders of the system should be able to comprehend it whereas the Design deals with managing complexity and details of the constituent parts.
Architectural and Design Patterns
Due to the maturity of Software Engineering practices, there are several predefined solutions available for certain problems which are called as Patterns. Design and Architecture Patterns have got immense popularity in the Software development industry over the years. They are universal and reusable solutions for the problems of recurring nature. Most of the time, they are the best possible solutions to most of such problems. A comprehensive knowledge of Patterns in their domains and the nature of problems they are designed for, is an added advantage for an Software Architect. This knowledge will greatly help them in designing the most suitable and perfect solution for the problem in question.
Architectural Patterns:
There are a bunch of architectural patterns available and choice of one solely depends on the nature of the given problem domain. Some famous patterns are:
Model View Controller
Model View Controller Service
Model View Presenter
Model View View Model
Multi tier
Micro services
Event Driven
Service Oriented
It should be kept in mind that the Architectural Patterns should not be considered as strictly mutually exclusive. A great many architects have to eventually choose more than one architectural patterns to adequately meet the requirements of the business, where each pattern kicks in to serve a specific purpose or function-area. For instance, Service Oriented architecture can work in conjunction with Model-View-Controller or Multi-tier in order to facilitate Service-Oriented access as well, to external entities.
Design Patterns:
Design Patterns describe design in a rather detailed level. They are smaller in scale than architectural patterns, but are at a higher level than the particular programming paradigm. Most, if not all, of the Design Patterns can be implemented seamlessly in an object-oriented world, but they are also enough to be applied to the legacy programming practices, like a procedural style. The Design Patterns are inherently capable of being programming-platform-skeptic, so by and large, any Design Pattern can be chosen for any modern development platform. Not to mention that the subsequent development practice should completely abide by the laid down Design Patterns.
There are plenty of famous design patterns divided into three major categories:
1- Creational Patterns:
Creational Patterns all have to do with creating objects. If we think about class definitions as templates for producing objects, then these patterns are all about how to create those templates. Creational Design Patterns are governed by two main ideas. One is encapsulating knowledge about which specific classes the system uses. Second one is hiding how instances of these particular classes are created. Remember, which Creational Pattern suits your application is totally dependent on your business domain – or may be your particular requirement. For instance, if some business function in your application requires some typical objects to be used frequently, you may prefer using Object Pool over Factory Method because object pool will save you lots of over-head of object creation every time an object is required.
Creational Patterns include Abstract Factory, Builder, Factory Method, Object Pool, Prototype and Singleton pattern.
2- Structural Patterns:
Structural Patterns help software engineers put objects together so they could be accessed and used more easily. They’re all about grouping objects together and providing ways for objects to coordinate to get work done. This roughly resembles the so-called one-window operation usually offered by some government department to the common public where they have to appear before a single window, where-from they get their requests served – shielding themselves from the internal procedures. Remember that aggregation, composition, delegation, and inheritance are all about structure and coordination.
Prominent Structural Patterns include Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Private Class Data and Proxy pattern.
3- Behavioral Patterns:
Behavioral Patterns use object composition instead of inheritance. Some of these patterns describe how a group of peer objects work in conjunction to perform a task that’s not intuitively possible to carry out by a single object. An important point is about the knowledge of peers about each other, but that results in the increase in object-coupling. The Mediator pattern ensures de-coupling by introducing mediator objects between peers. The mediator provides the indirection needed for loose coupling. The Chain of Responsibility provides even better loose coupling. It lets you send requests to the most suitable or available object implicitly through a chain of candidate objects. Typically any candidate object may fulfill the request depending on run-time conditions.
Behavioral patterns establish common communication and co-ordination mechanisms between objects and realize these mechanisms. These patterns make the co-ordination mechanism quite intuitive as well as maintainable and scalable to a great extent. Each of these provide solution to address various scenarios of typical natures.
Behavioral Patterns include Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Null Object, Observer, State, Strategy, Template method and Visitor pattern.
A Software Architecture implicates a set of important decisions about the organization, related to proposed software and each of these decisions may have a substantial impact on quality, performance, maintainability, and the overall success of the final product. A well-planned Architecture reduces the business risks associated with building the final software and builds a bridge between business domain and technical solution.
A Software Design represents an idea, not a particular implementation. The idea is to accelerate the development process by providing substantiated and well tested development/design paradigm. Remember, a well-defined and clean Design will ensure smooth sailing during the course of the entire software development exercise.
