Business Analysis Methodologies and ARIS
In short Maglinets sorts business analysis methodologies into three families by the kind of model they produce, and singles out ARIS as the most developed way to describe an organization. His key practical point: a requirements model built without a model of the real organization risks producing a system that does not fit it.
Based on: Yu. A. Maglinets, Analysis of Requirements for Information Systems, lecture notes (in Russian), Siberian Federal University, 2007, lectures 3-4; with reference to A. Cockburn’s classification of projects.
On this page
Key ideas#
Three families of methodologies#
Maglinets groups methodologies by the type of model they build:
| Family | Purpose | Examples |
|---|---|---|
| Models for analyzing and improving the organization | Assess and change how the organization works | SWOT, value chain model, business process reengineering (BPR), continuous process improvement and total quality management (CPI/TQM), ISO 9000, Balanced Scorecard |
| General-purpose models | Describe functions, data and processes in any domain | SADT, data flow diagrams, IDEF1 (information), IDEF3 (process description), IDEF5 (ontology) |
| Models built specifically for automation | Describe an organization in order to build information systems for it | ISA, BSP, ARIS, RUP |
The families answer different questions. The first asks “how should the organization change?”. The second asks “how does this domain work?”. The third asks “what must an information system for this organization do?”.
ARIS: many views of one organization#
ARIS (Architecture of Integrated Information Systems) is, in Maglinets’s assessment, the most developed of these models for describing a problem domain. It looks at an organization through a set of views:
- Organizational: the hierarchy of units, positions and people, their links and locations.
- Functional: the functions the organization performs.
- Inputs and outputs: flows of products and services used and produced.
- Information: how information is obtained, distributed and accessed.
- Control processes: the logical order of functions, driven by events and messages over time.
- Goals: the hierarchy of goals that processes serve.
- Means of production: the lifecycle of main and supporting assets.
- Human resources: hiring, training and promoting staff.
- Locations: where organizational units are physically placed.
Maglinets notes that these “subsystems” are not subsystems in the strict systems-analysis sense. They overlap and interpenetrate; they are better read as different angles on the same object. ARIS’s main process notation is the eEPC (extended event-driven process chain) diagram.
Domain analysis vs. requirements analysis#
Maglinets distinguishes two kinds of modeling:
- Problem domain analysis models something that already exists: the organization. The analyst’s job is to represent it accurately enough.
- Requirements analysis models something that does not exist yet: the future information system. You build the model first, then build the system from it.
He describes system creation as a chain of models: the organization, then a model of the organization (business analysis), then a first model of the system (requirements), then analysis, design and implementation models, and finally the system itself. Once in use, the system becomes a new model of the organization, closing the loop.
A requirements document is therefore a second-order model: a model of a model of the organization. You can write requirements without modeling the domain, but you risk building a system that is inconsistent with how the organization actually works.
When you can skip domain modeling#
Drawing on Alistair Cockburn’s classification of projects, Maglinets names two situations where a separate domain model may be unnecessary: when the development team already holds enough tacit knowledge of the organization (developers are part of it, or domain experts sit in the team), and when the customer co-writes the requirements and shares responsibility for decisions. The second is the path taken by agile methods.
How to apply it#
- Pick the family by question. Changing the business? Start with the first family. Understanding a domain? Use general-purpose models. Specifying a system? Use automation-oriented models, but feed them from the other two.
- Use the ARIS views as a scoping checklist. Before an organizational study, go through the views and decide which ones matter for this change. You rarely need all of them.
- Check your requirements against a domain model. For each major requirement, find the part of the current-state model it changes. Requirements that touch nothing in the domain model deserve a second look.
- Decide consciously whether to skip domain modeling. If neither of Cockburn’s conditions holds, budget time for it.
Example#
The analyst at The Workshop, a fictional chain of 12 bike-repair workshops, uses the ARIS views as a checklist for the parts-ordering change:
- Organizational: who may order parts: managers only, or senior mechanics too?
- Functional and control processes: how a part request becomes an order, and what triggers it.
- Inputs and outputs: parts in, repaired bikes out.
- Information: where stock levels live today (a shared spreadsheet, updated irregularly).
- Locations: two workshops share a storeroom, which changes the stock model.
The locations view catches a fact the requirements had missed: stock must be tracked per storeroom, not per workshop.
Pitfalls#
- Modeling everything. Choose the views that matter; a full enterprise model is rarely affordable.
- Confusing the model with the organization. The model is a simplification. Validate it with the people who do the work.
- Assuming the team “knows the business.” Check Cockburn’s conditions honestly before skipping domain modeling.
Sources and further reading#
- Yu. A. Maglinets. Analysis of Requirements for Information Systems, lecture notes (in Russian). Siberian Federal University, 2007. Lectures 3-4 (context of requirements analysis, ARIS, problem domain analysis).
- A. Cockburn — classification of projects and methodologies, as presented by Maglinets (the specific work is not named in the lecture notes).