Software factories and architectural frameworks

(prompted by "Mass Customizing Solutions" item in Fall 2007 Methods and tools)

Introduction
This item discusses the concept of Software Factories. While it is focused on a very specific sort of development I believe the principles it articulates have much broader application (if the approaches to development and integration are to be improved. It also describes the core thinking underlies the establishment of RHE's AMA (and the idea of instantiatable Development Approaches - DMAs). This lead directly to the need for multi-perspective modelling (e.g. as enable by a metamodeller) to make the management of the resulting knowledge viable.

It makes the point that the key intellectual content from a project is not the code. It is information (best held in models, and published in views suited to different audiences) that describes the requirements and design from many viewpoints.

Further, in my view, one of the key reasons business analysis does not mature as practice is the absence of a focus on quality (repeatability, consistenty). This is largely because there is not a focus on a consistent set of inter-related business domain viewpoints that can be explicitly captured (i.e. in a model) and people continue to think that the essay style is suited to conveying an sets of essays are useful for managing the knowledge.

Architecture frameworks
It item discusses Architecture Frameworks (e.g. Zachman):

• the key intellectual content of a project is not the code - "... interface design and functional factoring constitutes the key intellectual content of software.."
• this key intellectual content is captured in these frameworks - "Architectural frameworks capture the intellectual content using view points that identify, separate and interrelate well defined sets of stakeholder concerns"
• the frameworks have views for a variety of stakeholders (technical and non-technical) - "... stakeholders include business analysts, project managers, developers..."
• viewpoints include business rules, business info, business processes, UI workflow etc. - "Examples of viewpoints include business rules, business events, business information, business processes, user interface workflow and database design. Examples of stakeholder concerns include how business rules are enforced by a given process or how a physical database design supports a logical database design".
• viewpoints need to be able to be nested and adapted (i.e. a metamodeller is useful) - "The software factory schema is an architecture framework ... nesting viewpoints, specific to the solution family...dynamic [e.g.] new viewpoints are added.
• relationships between viewpoints are critical
• viewpoints imply artifact - "a viewpoint ... defines a set of related artifacts..., the activities that act upon the artifacts..."
• viewpoints/relationships support development - "Relationships between viewpoints are used to support the flow of development..."
• publishing information is key (that should be available from models) - "... publishing information about key processes and artifacts... This metadata is often readily available in the models used by factories."
• publishing information on requirements and design decisions is key - "...Two kinds of information are particularly important ... about requirements, sych as the information captured in feature models ..., about architecture"

Benefits
"The results are generally significant reduction in cost and time to market, significant improvement in the quality attributes, and greater consistency from solution to solution. Risk is also reduced..."

"When it is time to maintain or evolve ..., the metadata captured during its development is used to analyse the impact of changes in requirements and technologies.."

See other items related in one way or another
Enterprise data management
Business modelling with domain specific languages
UML not suited to requirements capture