This chapter is from the book
This chapter is from the book
This chapter is from the book
Of a System
We’re going to use the word “system” a lot in this book. The term appears in our definition of architecture and has already been mentioned half a dozen times in this chapter. But what is a system?
For our purposes, a system is any set of software components that work together to provide one or more capabilities. Systems can be large: They might contain hundreds or thousands of components and execute on a similar number of computers. But they can also be small: The embedded software running on a battery-powered wireless sensor is also a system.
Systems need not work in isolation. If you are developing wireless sensor software, then, for your purposes, the boundaries of your system can be set according to which software runs on the sensor. That sensor—along with others—will send data to some other system that processes that data. For you, the processing system may form part of your environment, not your system; it may, for example, be developed by a different team.
Systems may also be composed of other systems. In other words, a new system can be defined as the composition of two or more smaller systems, perhaps with some additional components added to the mix. For example, a system of wireless sensors, combined with a system for data processing, can be composed into a single system providing a monitoring capability.
Thus, when we use the term system regarding architecture, we’re allowing for the system boundaries to be set as befits the relevant scope of concern. Every aspect of software architecture covered by this book applies to any of these systems, regardless of its scale. Granted, some concerns are more readily addressed at smaller scales, so the extent and rigor with which you apply architectural practice can be adjusted according to the needs of the system at hand.