Process

The Catalysis approach also makes a clear distinction between:

	Structure of artifacts: you may "finally" produce some domain/business model, a specification of the system, its design and the architectural patterns it uses, and the implementation. These parts have a very well defined relationship to each other, independent of ...
	Process: the breakdown and sequencing of work to populate that eventual structure of artifacts. You may do it top-down, bottom-up, inside-out, or some combination. This process defines what things you tackle in what order, and the dependencies between them. Thus, you can have many "routes" through the same structure of artifacts, and would likely consider each a different process. For example, development with a framework or large set of existing reusable components will always follow a different route than building from scratch.
	Schedule: the particular unfolding of the process against time and other resources, and the tracking of actual progress against the plan.
	Deliverables: the concrete form, documentation templates, diagrams, that will be required at critical points of the above Process. Some aspects of these will certainly vary across processes.

artifacts-vs-process.GIF (8790 bytes)

It is useful to view adoption or usage of Catalysis in 2 dimensions:

Depth: how sophisticated or minimal is your use of the method?

	light adoption: minimal deliverables and checks, including type models, system context, and component models.
	sophisticated usage: package structures, multiple lines of business or subject areas, testable refinement, architecture standards, traceability to business models, clear process.

Breadth: what is the scope of adoption:

	individual: use selected techniques to make your own modeling and design more effective
	project: for a team, from the business context of an application to its deployment
	enterprise: establishing product-line architectures, consistent process across projects, cross-project reuse and domain models, process improvement, ...