Software Architect

Choose Frameworks that play well with others

Book: 97 Things Every Software Architect Should Know
Publisher: O’Reilly Media
Author: Richard Monson-Haefel
97 Things Every Software Architect Should Know – 84/97

'Coz sharing is caring

When choosing software frameworks as a basis of your system, you must consider not only the individual quality and features of each framework, but also how well the set of frameworks that make up your system will work together, and how easy it will be to adapt them to new software you may need to add as your system evolves. This means you must choose frameworks that do not overlap and that are humble and simple and specialized.

It will be best if each framework or 3rd party library addresses a separate logical domain or concern, and does not tread into the domain or concern of another framework you need to use.

Make sure you understand how the logical domains and concerns addressed by your candidate frameworks overlap. Draw a Venn diagram if you need to. Two data models that overlap substantially in domain, or two implementations that address very similar concerns but in slightly different ways, will cause unnecessary complexity: the slight differences in conceptualization or representation must be mapped or patched with kludgy glue code. Chances are you’ll end up not only with complex glue, but also with the lowest-common-denominator of the functionality or representative power of the two frameworks.

To minimize the chance that any given framework will overlap with another framework, choose frameworks that have a high utility to baggage ratio, in the context of your system requirements. Utility is the functionality or data representation that your project needs from the framework. Baggage is the framework’s sweeping, all-encompassing, I’m-in-charge view of the world. Does it insist on mixing data representation and control? Does its data model or set of packages and classes extend well beyond what your system needs? Do you have to become a fundamentalist in the framework’s religion, and limit your choices of other frameworks to those of the correct denomination? Does its excess complexity limit the kinds of things you can mix with it? If a framework comes with lots of baggage, then that it had also better be providing 75% of the functionality value in your project.

Your system should be comprised of mutually exclusive frameworks, each of which may be a master of its domain, but which is also simple, humble, and flexible.

'Coz sharing is caring

By Swatantra Kumar

Swatantra is an engineering leader with a successful record in building, nurturing, managing, and leading a multi-disciplinary, diverse, and distributed team of engineers and managers developing and delivering solutions. Professionally, he oversees solution design-development-delivery, cloud transition, IT strategies, technical and organizational leadership, TOM, IT governance, digital transformation, Innovation, stakeholder management, management consulting, and technology vision & strategy. When he's not working, he enjoys reading about and working with new technologies, and trying to get his friends to make the move to new web trends. He has written, co-written, and published many articles in international journals, on various domains/topics including Open Source, Networks, Low-Code, Mobile Technologies, and Business Intelligence. He made a proposal for an information management system at the University level during his graduation days.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.