The i* modeling language

A friend asked me about the i* modeling language he was taught in a university graduate course.  I had to look it up, since it comes from academia  with little uptake in the business-computing world.

The big innovation in i* is to put motivations on a diagram.  Not just your enterprise’s goals, but any actor’s desires to get a product or service, save time, make or save money, and get satisfaction.  This is missing in UML and other common modeling languages.  As I said in my last post, a structured modeling language can make assumptions explicit, and allow more thorough consideration of alternatives.  The i* examples emphasize options analysis.

The big reason why I won’t be using i* is its complexity.  The modeling language is rich with symbols for actors, tasks and resources, as well as goals, dependencies, causes and effects.  Even the teaching examples are too busy to convey a message effectively.  Options analysis happens at the “sketching” stage, when diagrams should emphasize the issues to be decided upon.   If this language is meant to help you think, it needn’t document everything.

The i* literature should also recognize that this language is meant for making business decisions about strategy, staffing and contracts.  That should happen in the business-architecture stage, not as “early requirements gathering” for an automation project.  (This is a classic case of technology folks trying to interfere in business decisions that have already been made.)  This issue confounds the comparisons of i* to UML, which is most often used to specify automation design.

In the Government of Ontario, I’ve learned a set of business architecture modeling languages that do capture motivations.  Goals, objectives and needs are written in structured text (charts), but do not get as much attention as the SIAM diagram.   The SIAM, an adaptation of a UML use case diagram, shows services (major processes) delivering outputs (resources) to clients (actors).  It might be useful to diagram actor motivations, at least during the sketching process.  (Needs and objectives for each service are specified in a structured text format.)

So, I will be thinking about some UML adaptations or text structures to bring about more thorough consideration of actor motivations and options for business relationships.

Note: I’m basing my opinions on the basics at Wikipedia, examples in a presentation, and the quick notation guide, rather than trying to read the years and years of academic work.  My apologies for any misunderstandings that result from judging too quickly.  Note also that  i*  has become the GRL part of  User Requirements Notation (standardized by the International Telecommunication Union, oddly).

One thought on “The i* modeling language

  1. Sounds a bit like BMM, I see you have a bookmark to a BMM UML post. I’ll check that out. Motivation for me is an important part of what people do and why they do it. When I’m doing analysis there hasn’t always been a good way to express this, although the Ishikawa-Fish Bone has done on a few occasions.

Comments are closed.