I learned about cellular manufacturing when I was majoring in industrial engineering. In this post I’d like to show the game-changer nature of vertical organization by drawing some parallels between this idea and the organization of software work.
In a functionally organized plant, the shop floor is structured according to functionality: lathes are organized together, as well as mills, painting and polishing stations and various other functionalities. This brings efficiency in terms of keeping tool magazines, needed chemicals etc. together, centralizing the maintenance, optimizing utilization of the machines, sharing knowhow among the people operating the machines and so on.
Continue reading The power of verticality in SW (and manufacturing)
A non-functional requirement (NFR) is realized by the architecture and the implementation. The balance can vary. Sometimes the architecture does the most part, e.g. by providing a real-time OS and fixed priorities for critical threads; sometimes the implementation, e.g. by following coding conventions scrupulously to ensure code maintainability. And sometimes the balance is off.
Continue reading When architecture should help
For more than a year now, I’m working as a system designer, which roughly means being responsible not for a product or product line, but for a system to which different products are integrated. So I’d like to share my first reflections. Continue reading System vs. software architecture
All design is tradeoff. Any relevant system will ask for a balancing of forces while making design decisions. Therefore formulation of alternative designs and evaluation based on concrete criteria helps tremendously in laying out the tradeoff in front of the stakeholders and reaching a good decision in a transparent way.
This all works well except for simple designs. Continue reading No hard argument for simplicity
All parts of BAPO have a home turf of problems/aspects/challenges it can address efficiently. For instance, maintainability is best addressed in the architecture, rather than some complex maintenance processes or special teams designated in the organization. In most cases, modifiability is best first addressed in the business, where only the essential modifiability is prioritized and rest is eliminated to save on complexity. Knowhow management and regulations etc. are mostly best addressed in the organization and process areas. While some technical risks are best addressed in the architecture, I was surprised to hear of a case where the business people covered against a risk by just arranging an insurance, thereby relieving the architecture of the complexity. Continue reading BAPO imbalance
Anecdotal observations tell me that NIH (not invented here) is for the most part dying, and the general level of software reuse has increased significantly in the last ten years: Continue reading Choosing SW for reuse