Games in Digital Architecture and Systems Development

SAGANETHilversum, 20 januari 2010

Dr. Stijn Hoppenbrouwers

Dept. of Model Based System Development

2

About “Digital Architecture and Systems Development”

• Business-oriented side of IT• Mixture of organisational and IT issues and activities• Modelling, specification

• Enterprise Architectures: high-level views (and models) of organisations, their parts, processes, services etc., and the principles underlying them. “Enterprise Blue Print”, integrating and reconciling the diverse and often clashing concerns of the many parties involved.

• Enterprise Engineering: includes EA, but also the more operational models (e.g. data, process, business rules), including those used to build (often, generate) information systems of all sorts.

3

Some examples of EE diagrams

Plus lost and lots of text!

4

NAF Workgroup Games & Simulation in EA

• One year old• Headed by Jan Campschroer (Ordina); • SAGANET rep: Herman v.d. Bij (Simagine)• Goal: investigating possible role of games & simulations in

EA, and developing some games

• Workshop at LAC 2009• [Campschroer & ten Haken] (in “Informatie” magazine)• Google Group:

http://groups.google.nl/group/naf-werkgroep-games-en-simulaties-in-architectuur?hl=nl

5

4 types of games we distinguish

1. Convincing people of the added value of the concept of architecture through a game. (Game/simulation under development)

2. Creating architecture descriptions/models. A game or a number of games that support the creation of (representations of) architecture. (No specific game under development yet, but more general enterprise modellig under investigation)

3. Analyzing and validating architecture (first game ready)

4. Creating awareness of a completed architecture among the stakeholders. Important to note here is that the architecture is expected to be correct and stable. (No games)

6

Development context for the NAF workgroup

• The type 2-4 games will be largely situation dependent• Will gave to be adapted every time; generated?• When IT people think about games, they do “systems design”

• Potential users of the games are now primarily ICT service providers, and some of their large customers.

• I am dreaming of something quite different…

  AnalyserenModelleren

Ontwerpen

Realiseren Ervaren

Programma van Eisen x        

Systeembeschrijving   x      

Spelconcept     x    

Spel       x  

7

Focus: The Modelling Bottleneck

• Many promises of IT and AI: analysis, automation; helping people and organisations.

• Many depend on (formal) models; I use a broad notion here.• Some such models can be automatically derived, many cannot• Some such models can be created by experts at high

expense; many cannot• Especially in view of application on a large scale, for example

in the creation and maintenance of advanced enterprise systems, there is a problem

• It’s not traditionally one raising much academic interest, but it won’t go away by itself

[Hoppenbrouwers and Lucas, 2009]

My Hobby Horse: “Disintermediation”

“Knowledge Acquisition Bottle Neck”

8

(Situational) Method Engineering• Field within Information Systems: “development methods”, but clear link with “intervention methods” in Management

• Composition of situation-specific methods from standard elements (re-use); research paradigm: “Design Science”

• Includes processes/procedures, yet emphasis often still is on modelling languages

• Procedures: rough, process-oriented phasing “+ iteration”.• I want to push towards “operational modelling”: look at interaction

leading to models– Interaction between modellers

– Interaction between modeller and model

• HCI, interactive systems, collaboration engineering, …• Ultimately: “Modelling Wizards”?

[Hoppenbrouwers, van Bommel, and Jarvinen, 2008]

Where I come from: Method Engineering

9

The nature of operational modelling

• Goals• Strategies to achieve goals• Interaction to execute strategies (problem solving)• Rules to govern the process:

– Driving rules (goals)

– Constraining rules

• NOT: fixed procedures (as e.g. captured by means of flows)• Highly iterative• Rules (goals, constraints) can change along the way• Methods are “declarative” rather than “imperative”

10

What’s in a Game?

• Games have rules• But games also leave lots of space to decide your own

moves...• ... and therefore to make mistakes, or be brilliant.

• Part of the rules are the goals of the game:• Its “end or victory conditions”

• Many games are boiled-down versions of real life challenges (like battles, or problem solving)

• Games create “goal-driven activities combining creative behavior within a constrained setting”

11

The game metaphor

1. Can be used for analytical purposes, as a useful point of view, a “conceptual heuristic”

2. Can also be used in training people to use methods

3. Can also be applied to actual method design, implicitly or explicitly:

• Methods-for-modelling as games (mostly type 2 and 3)• But also methods in general as games?

– (link with intervention methods: management games)

• Games in operational processes? (Enterprises, decision making, …)

I don’t really know how much of this involves “simulation”;Possibly, quite a lot, but also there is a strong “creation”/”description” element

12

What if...

• We would view (Collaborative) Modelling as a Game, or a set of interlinked Games?

• We’re obviously mostly talking about multi-player games here• All sorts of known game types might be involved: quizzes,

puzzles, role playing games, negotiation games, dialogue games, management games, ...

• A clear link presents itself with the world of virtual reality, video gaming, and (interactive) simulation

• Motivation (fun, boredom, self improvement, challenge, sense of purpose) is an undeniable issue in operationalization

• If the game is not playable, there’s something wrong (HCI point of view). What? For which situation/player?

13

Beyond study: Shaping Modelling Behavior

• Formal modeling: constrained by goals (utility, efficiency; syntax, validation, completeness, ...); rational

• Procedures for modeling may be basis for game procedures, in particular for inexperienced players (strong guidance).

• Yet we can also just set assignments: creative, interactive, ad-hoc; “messy” (especially for advanced players)

• So constraints are both needed and a problem; balance is called for –for each specific situation.

• EM and beyond: strategy/policy making, rule definition; blend with intervention methods (management science): System Dynamics

• Collaborative modelling as a “goal-driven interactive activity that requires freedom of action and decision within clearly set boundaries”

14

Extra aspect: Designing Motivation

• Especially if we address the challenge of “bringing high quality lightweight formal modeling to the masses”, we believe that:– Games will have to be designed that have the players create formal

models without them being confronted with any classic formal stuff (not even complex/abstract diagrams)

– Dragging them through this stepwise process will require considerable motivation on their behalf (problematic).

– So the process should be pleasantly challenging. It does not have to be “great fun” but should not be “a complete bore”.

• In Game Design, detailed study has been made of how to make basically unattractive tasks more interesting and even more fun. We can use this knowledge.

• Approach: “start with thinking about emotions/experiences you want to evoke, and design the game accordingly”

15

Interface-oriented game prototype

16

Game for validating architecture models

• Game created on the basis of a specific ArchiMate model

• So: general rules, but also a model-specific game board and model-specific assignments

• Players are expected to be laymen;

• The game helps them understand the model beyond just understanding what the symbols in the diagram mean

17

Ilona Wilmont’s Master’s Project

• A game concept for ICT Project Management

• Mirrors “project world” in colonization of a planet• Various deliverables are represented as villages, houses,

rooms• “Keep the Mayor Happy” (executive)• Sense of community• Central project overview and indicators• Game psychology and design principles used

18

19

Ilona Wilmont’s PhD project

• Somewhat extreme angle at Method Engineering: actual game design & implementation for “generic modelling game”

• Disintermediation as main goal• If possible, the typical “terms-fact-rules-processes” concepts,

but open to any angle for elicitation.• First board games, then digital implementation

• Link with rule-interaction-model triangle and reasoning (AI)• Also link with HCI, cognition (esp.

abstraction/conceptualisation) and (game) psychology

20

I question I have for you:

Does a game have to be fun to be a game?

21

References

Rouwette E.A.J.A., Hoppenbrouwers, S.J.B.A (2008). Collaborative systems modeling and group model building: a useful combination? In Dangerfield, BC. (Ed.) Proceedings System Dynamics Conference Athens, 2008, cd-rom: 1-15. Retrieved November 2008 http://www.systemdynamics.org/conferences/2008/proceed/papers/MCCAR357.pdf

S.J.B.A. Hoppenbrouwers and P.J.F. Lucas: Attacking the Knowledge Acquisition Bottleneck through Games-For-Modelling. In: proceedings of AISB’09 workshop “AI and Games”, Edinburgh, April 2009

S.J.B.A. Hoppenbrouwers, P. van Bommel, and Aki Järvinen. Method Engineering as Game Design: an Emerging HCI Perspective on Methods and CASE Tools. In: Proceedings of EMMSAD’08 (Exploring Modelling Methods for System Analysis and Design), held in conjunction with CAiSE’08. Montpellier, France, June 2008.

Alan R. Hevner, Salvatore T. March, Jinsoo Park, Sudha Ram: Design Science in Information Systems Research. MIS Quarterly 28(1): (2004)

22

More references

Denis Ssebuggwawo, Stijn Hoppenbrouwers and Erik Proper: Interactions, Goals and Rules in a Collaborative Modelling Session. In: Anne Persson, Janis Stirna (eds): The Practice of Enterprise Modeling, 2nd IFIP WG8.1 Working Conference, PoEM 2009. Springer, LNBIP series

Krogstie, J., Sindre, G., & Jorgensen, H. (2006). Process models representing knowledge for action: a revised quality framework. European Journal of Information Systems, 15, 91-102.

S.J.B.A. Hoppenbrouwers, H. Weigand, and E.A.J.A. Rouwette: Setting Rules of Play for Collaborative Modelling. In: P. Rittgen, edt., International Journal of e-Collaboration (IJeC), Vol. 5, Issue 4, 2009, p37-52. Special Issue on Collaborative Business Information System Development. IGI Publishing, USA.

J. Campschroer and S. ten Haken: Spelen met Spelsimulaties. Informatie 51 (9), p. 18-23. 2009.