Software Component Architectures
Software systems range wildly in size depending on the need – everything from a single executable to hundreds of composite services spread across any number of deployment platforms. Systems architecture diagrams are a great way to make sense of the complexity of larger systems and determine dependencies inside the system.
At the systems architecture layer, services inside systems appear as neatly self-contained singular boxes. A system may contain many services both internal and external facing. Seeing the system as a whole at this level provides a clean view into the overall structure of the effort. The perception typically is that individual services can be patched, upgraded, or otherwise altered without necessarily affecting the system as a whole.
At a conceptual level, this is an accurate view of the system. However, the reality is much different in large software intensive systems. The well-defined service boundaries are usually blurry, and at worst, non-existent. Dependency management is typically an after-thought and instead, the ubiquitous “lib” directories show up throughout the codebase. Developers furiously write code to make deadlines reusing any code they can find regardless of where it came from. These dirty little secrets are some of the reasons why systems are bogged down and are unable to flex to meet customer needs. Everything takes longer – new features take longer to add, patches are fraught with peril, and customers get frustrated.
A solution to avoid these problems is to go the next layer deeper from the systems engineering level and track the software architecture. A move towards a software component architecture (SCA) would solve a number of problems and enforce rules such that the original top level architecture diagram is pretty close to reality. A SCA would enforce explicit dependency management such that a component defines all dependencies clearly. This would combat the problem of developers grabbing whatever library is at hand and jamming it into the system just to get something working.
Programming to interfaces is another critical part of a SCA. Components need to be “swap-able” for best-of-breed technologies to take hold and integrate into a system. Without programming to interfaces clients become completely tied to a specific implementation making upgrades difficult and product switches (to a new component) expensive, time consuming, and costly.
Software Component Architecture is by no means a panacea for software development. With any tool it requires utilizing them in the right situations to be effective. In environments where flexibility and rapid change management are high on the requirements list, this type of architectural pattern should be given serious consideration.
Author: John Madden, Senior Software Engineer
