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.
Spectrum of Adoption
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
|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, ...