History
If we used word architecture some 200 years ago we would certainly relate to “an art of building” or “a style of building” that are the original meanings of the word. An architect was a chief builder responsible for:
- designing a building
- deciding on building blocks
- putting them together
Then came Charles Babbage, probably the first Computer Architect. He had to design his Difference Engine, decide on all wheels, levers and shafts it consisted of, and he definitely had to invent how to put all theses building blocks together, how they are going to communicate with each other to produce the desired end result.
It was not yet Software Architecture but it was a Computer Architecture (if we can call this machine a computer at all). Architecture referred mainly to hardware and structure of computers until about 15 years ago. There were Von Neumann, Harvard and Modified Harvard architectures with their components and communications among them. By the way, it is the Modified Harvard Architecture that is used in contemporary computers.
On the course of their development computers were growing more and more complex, not only their hardware but the software as well. And the word that had served well for the structure of computers found its way to software. Undoubtedly,
it was markedly popularized by Bill Gates who created position “Chief Software Architect” at Microsoft for himself (in January 2000). We could only speculate if he personally architected any of the company applications or OS and if yes if he’d done it well, nonetheless, we can thank him for architecture describing the software structure.
Software Architecture
The original meaning of the word “architecture” has not changed too much from 200 years ago when it was describing buildings. It still means three qualities of the end product, only the end product is different. Then it was a building, church or a castle, now, it is a software application.
It is still:
- type, purpose and design of the application
- libraries, components, classes the app consists of
- way of communication among the components for the desired end
1. Type, Purpose and Design of the Application
This is the most general view of the app and its type. We can have local applications such as word processors, spreadsheets, presentations, we know client-server applications like emailing clients and server agents, there are also specialized real-time applications for controlling industrial technological processes or cars, washing machines and other appliances.
Obviously, the type of the application has the decisive influence on other aspects of its architecture. A car control software would be significantly different from a JavaScript framework based client-server web application.
2. Libraries, Components, Classes
This is mainly about JavaScript applications, so the library used would be a framework (ExtJS, React, Vue, Angular), possibly also some additional libraries we might need (Google Maps and others). The library or frameworks themselves contains building blocks we use in architecting the application.
In spite of the plenty of useful library-packed components, one of the main tasks of the application architect is to specify the higher level of the custom, application components put up together from the simpler, generic library pieces.
Are we going to use MVC, MVVM, Blocking, Non-Blocking, Event-Driven, Synchronous, Asynchronous, Plugins, Extensions, to name a few of contemporary software architecture classifications? (You can google for them but for the purpose of this article you do not need to know what the above abbreviations or esoterically sounding words mean.)
The above concepts are generally supported so the architect must wrap his head around the medley and select those that best suit the Type, Purpose and Design of the Application as described in the previous article.
Corollary: The question if MVVM is better than MVC is irrelevant unless we evaluate it in the context of the application itself. For some types, MVVM is best, for other MVC, and usually it would be the combination thereof that is most suitable.
3. Inter-application Communication
This is the make-break area of the architect’s work. Based on how the communication is done you can tell stupid from wise, dilettante from qualified or amateur from professional. There are so many ways of how to go awry with components communication that it is quite rare to see a well-designed application. I have even seen a developer getting a reference to a button and then firing click event on it for the handler to execute and, unfortunately, these extremes are not too uncommon.
What we have and what we must not neglect here are component inputs, outputs and hierarchy.
Inputs are methods we can call on a component when we want it to do something – well, the real data of inputs are arguments to these methods. For example, if we want a component to enable and disable its main toolbar, we implement function (method) setMainToolbarDisabled() or we can also add enableMainToolbar() and disableMainToolbar().
Outputs are events (or publishing in MVVM). When we need to inform the rest of the application that something happened to a component, for example that data arrived, or the user clicked a button then we utilize events. We can use the predefined library or DOM events, but we could, and definitely should, utilize also the custom, application specific events.
Hierarchy should be similar to a structure of an organization in real life. Subordinates do not tell seniors what to do – views do not call methods of controllers. One junior does not have more bosses – one view is not controlled by more than one controller. Employees of different departments do not need to talk to each other – lateral communication among views or controllers is detrimental to the application quality.
Seriously, if you “only fix bugs”, if you are “scared to touch this code”, if “a change results in a heap of new bugs”, if the application is “too buggy”, or if the development, however fast it was at the beginning is now progressing a snail’s speed, then there is a problem in the area of inter-application communication. Period.
Some closing thoughts
To architect is to split the design idea of the application to (small) pieces, organizing them into a meaningful structure with the streamlined communication among them for achieving the application purpose.
The architecture itself, regardless of its sound name or acronym, is not a solution. It is just a tool.
If you cannot create an application with, let’s say, MVC architecture, you won’t be able to create it with MVVM. Conversely, any application can be made with any tools in hands, it can only be simpler or nicer with more suitable tools, more suitable architecture.
The architecture is the way how human beings see the software. Computers (machines) do not care. Hence, the architecture is extremely important because people, not machines, make the software.
Hope this helps you to architect your apps proficiently.
- Ext, Angular, React, and Vue - 27. June 2019
- The Site Resurgence - 11. February 2018
- Configuring ViewModel Hierarchy - 19. June 2015