One of the best things about being based in our Washington DC office is the sheer quantity of exhibitions and seminars that exist. Last weekend I went to one called "The Art of Video Games", which traced the evolution of video games over 40 years, from Pong to World to Warcraft. A phrase from one of the video interviews caught my attention;

 "What makes a video game real is the story, which provides the context for how the player interacts with the game. Technically, all you're doing is moving this blue pixel on top of this brown pixel, but when you're in the context of the game, the blue pixel is your gunsights and the brown pixel is your enemy."

Well it's great that I get to nerd-out on my weekends, but how does this relate to modeling? The unifying theme is that of The Story. Thinking about it, I realized that the same is true of diagrams. All that the diagrams are, is a collection of pixels…it's the message that they are trying to convey that gives them meaning. "This is the process for how we make an order" or "This is the deployment environment of the new SAP system" or "This is what we have installed in rack 4A of our New York datacenter".

Every diagram needs to have a story in mind. What is the information that you are trying to convey in your diagrams? 

Orbus has just released a new BPA solution for iServer, and one of its capabilities is Process Simulation. This is where you run through a proposed process multiple times and summing the results as a way of gaining insight into how the process might be optimized. To achieve this, we've partnered with ProModel, a leading Visio-based simulation specialist. It's been an interesting exercise working with them, not least because it has forced me to reassess my opinion of simulation.

Historically I've always been skeptical of the value of Process Simulation, feeling that you'd have to get the process durations estimated to such a high level of precision that it would be unworkable in a business situation. In practice, it turns out that you define ranges of durations for task...but more important is the application of scenarios. The idea here is that you vary certain parameters - how many of a given role is available, how often one path is gone down instead of another - and see how the throughput varies in response to changes in parameter.

What this means is that estimating the precise duration of each task is less important than knowing what values to vary between your scenarios to answer specific business questions. In which case, it turns out, simulation has a lot to offer.

A question that is very much in the minds of the Enterprise Architecture prospects that I talk to at the moment is "how can I show value from EA?". Sure, they like our tool, but how can they convince the management that the modeling activities that require a tool actually delivers value to the business? Really, the question has two answers - "before" and "after".

Before any modeling has taken place, the best approach that I have seen is to tell cautionary tales. Specifically, to reference past problems that have occurred and show how they could have been prevented if modeling had taken place. For example, the specialist product supplier that inadvertently made restricted products available to all of its direct sales force, because they did not know what data was being replicated between which systems. Or the US insurer that was unable to deliver on a promise made by the CEO on national TV because they had no idea of which systems they would have to change.

After modeling has taken place, a different strategy works better - you can point to problems that have been averted. "If we hadn't been doing modeling, this would have happened"

Abstract descriptions of the potential benefits of modeling tend to fall on deaf ears. Putting the fear of failure into management's hearts…that tends to get their attention.