Sunday, April 17, 2011

Strategic Reuse

Product lines differ from ad hoc reuse in the granularity of components reused and the different products reuse is applied to. To explain, in ad hoc reuse, you can reuse inside the same system, reuse between different versions of the same system, or reuse a library or component. In product lines, this is not the case, reuse is planned and enforced by identifying which parts of the system will remain constant and which will vary, and design the system architecture to support multiple products which share the constant part.

Scoping defines what systems the organization predicts to build within a product line and what systems it can’t. Thus, the scope defines the products that their point of commonality can generate economies of scale (reduce cost). A scope will aid the organization to predict if the system can be built within a product line, and how much a product is specialized in a product line, and how much follows the line’s strategy. It also describes the market segmentation and type of users.

Commonality is the core asset base that doesn’t have to be changed from product to product in the same product line. Variability is the ability of the core asset base to provide mechanism to build the components that vary from one product to another in the same product line, without having to change the core asset base.

The decision to follow a product line approach can affect the organizational structure. The organizational structure is reflected in software development because it defines the stakeholders and assigns responsibilities to employees. This means that managing the system’s architecture and the core assets should be assigned to the right organizational unit. Choosing a particular line approach can involve changing the organization structures so that they can build products from the core assets that meet business goals and strategy.

Software Architecture in Practice, Second Edition, by Len Bass, Paul Clements, and Rick Kazman, Addison-Wesley 2003

Wednesday, April 13, 2011

Big Ball of Mud

"A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems."
—Brian Foote and Joseph Yoder, Big Ball of Mud.  

Some of the reasons why systems turn into big ball of mud include:The designers and implementer of the system might have no formal architecture or software engineering training, or they lack domain specific experience, which can limit the maturity of the architecture to evolve.

The system might have been developed over a long period of time, with different individuals working on various pieces and parts at different speeds, which make certain parts of the system to evolve in a different direction than other parts.

Designing the system as a prototype and then keep using it since it works is reason for it to turn into a Big Ball of Mud. Prototypes architecture usually experiment with certain quality attributes or functional requirements and is not designed to handle all architectural drivers.

Time and Cost: The business might not be able to invest the required time or resources to make sure the system doesn’t turn into a Big Ball of Mud. This usually requires an upfront investment or costly refactoring that the business decides it can’t afford.

Monday, September 29, 2008

Tomorrow I'm off, no more work for the rest of the week.