Process analysis, static? Yes, unless extended to include either discrete event simulation or systems dynamics. 

This is not to say that static analysis is useless. It is a necessary first step in sketching models. Dynamic analysis depends on understanding concepts and activities. I think my work to date will be suitable as a foundation.

I've been spending some professional development dollars on understanding three major aspects of industrial theory: Lean, Theory of Constraints (TOC), and Systems Dynamics (SD). Don't have much to report on the first two, because I've been focusing on SD. I always read multiple books at once, and so am immersed in:

Madachy, Softwre Process Dynamics
Senge, The Fifth Discipline
Morecroft, Strategic Modeling and Business Dynamics: A feedback systems approach
Warren, Strategic Management Dynamics
Warren, Competitive Strategy Dynamics
Sterman, Business Dynamics: Systems Thinking and Modeling for a Complex World

Currently focusing on working through the last one, since it is written by the director of MIT's Systems Dynamics group.

I have a ton to learn in this new field, but I'm already starting to see the utility. Not going to discuss the basic concepts here, since the interested reader can easily research themselves (the Wikipedia article appears to be basically sound). But a few initial reactions surface:

As an enterprise architect, I pride myself on understanding modeling languages. SD is boxes and lines, variously adorned. It even has some echoes of functional mapping ala IDEF0. But it is intended from the ground up for quantitative numerical analysis, and is especially suited for describing systems containing feedback loops. There are a number of discussions of SD versus discrete event simulation (used in business process analysis tooling) and enterprise architects trying to make sense of SD may find them a useful gateway.

It's interesting to see the term "architecture" used in various places in the SD literature. SD models are characterized as "strategic architecture" by Kim Warren in particular, in both books cited above.

What is the enterprise architect to make of such claims? I counsel humility and interest. I have long been unconvinced of the pretensions of enterprise architecture to "business" architecture relevance -- something is missing. Certainly, the ability to understand feedback processes would be essential to any method claiming "business" relevance. But we don't find much of anything useful for this in the usual EA toolkits.

I do think, however, that many enterprise architects have the temperament, intellect, and organizational positioning to master systems dynamics and apply it to both business and technical problems. And it may well be a necessary step if the end goal is business relevance. (That's the challenge.) Anyone else out there looking into this?

On another topic debated lately: business process management is not discredited by systems dynamics. Rather, we should start by training BPM specialists in SD. It will be a natural fit, and their process engineering work may very well benefit thereby. But SD is not a suitable language for describing and communicating workflow and procedure, and the need to do so will remain.

SD certainly does not per se invalidate the concept of a repeatable, countable process. It does however provide a rigorous means for understanding a process "architecture," that is, an overall ecosystem of processes. But the stocks and flows of SD need to be quantifiable in order to perform numerical simulations. (Actually, the SD concept of stock does not map to the concept of entity. It might be better understood as any quantifiable attribute of an entity. Or set, since the SD functions can be multivariate. Perhaps Object Role Modeling or Semantic Web are more appropriate at the data level.)

Finally I am cautious about the quantified intangibles we see in many SD models. More to come... Disclaimer: I am learning...

-Charlie