MUCH ADO ABOUT NOTHING: CHAOS THEORY AND LOGISTIC POPULATION GROWTH

All other things being equal, populations cannot grow indefinitely. Eventually, they will hit up against their enviornment’s capacity constraints.

The customary way of modeling capacity-constrained population growth is by way of the logistic function. The logistic function is a growth rate that allows a population level to grow exponentially when this level is far from the environmental carrying capacity. Growth slows as the population level approaches capacity and eventually levels off, thereby preventing overpopulation. Growth, so modeled, presents the appearance of an “S” curve.

The literature on the logistic function is interesting. Some if it has the intent of demonstrating tempered, S curve growth. Others, such as Marcus du Sautoy and his The Great Unknown: Seven Journeys to the Frontiers of Science, focus on the idea that logistic population growth exhibits chaotic behavior, as in chaos theory. Specifically, du Sautoy and others argue that population levels vary chaotically after a short period of time when the net reproduction rate (the difference between the natural birth and death rates) is sufficiently high. On this view, deterministic population growth models cannot produce reliable predictions of future population levels after just a short period of time.

Clearly, these two approaches are not compatible. And the latter flies in the face of many efforts to predict population levels.

In Logistic Growth and its accompanying appendix, I explore this issue. My findings can be summarized as follows:

• Claims about logistic population growth depend on how time is treated in the formal model.
  • When time is treated in continuous terms, the resulting model, the logistic equation, produces non-chaotic S curve growth.
  • When time is treated discretely, the resulting model, the logistic map, produces chaotic change after just a few time periods once the net reproduction rate becomes sufficiently large.
• The literature on the logistic function evinces considerable indifference with respect to the dependence of its conclusions on how time is modeled.  Some of it seems unaware of the dependence.  Others are aware, but do not appear to see the need to justify one choice over the other.  Neither approach is tenable.  Given the difference in results, and the gravity of this difference, a defensible justification for the approach taken to modeling time is not optional.
• I argue that time is best modeled in continuous terms in formal models of population growth.  The chaotic implications of discrete logistic growth models are interesting, counterintuitive, and disturbing.  But they are not meaningful when considered as empirical predictions.
• More importantly, the mechanism at the heart of the issue, the logistic function, is a poor model of capacity-constrained population growth.  I say this because it implies that a given species has some sort of built-in self-correcting adjustment mechanism with respect to its procreative behavior.  This is not a plausible claim because it lacks an empirical referent.
• I present an alternative model of capacity-constrained population growth that is not reliant on the dubious logistic function.  Instead, it uses an empricially plausible brute force starvation mechanim to keep population levels in check.  This alternative produces S curve growth.  And crucially, it does so when time is modeled in both continuous and discrete terms.  No chaos is evident.

In short, much ado about nothing.

I conclude with a brief discussion of the implications of my findings for realistic population growth models and for the methodology of dynamic process models as such.

Once again, the details of my argument can be found in the following notes:

• Logistic Growth
• Appendix

SOA AND NONTRIVIAL CHALLENGES TO ITS REALIZATION

Time for a reality check, I think.

There is a fair amount of consensus in the literature on SOA suggesting that organizational readiness and governance are essential keys to a successful SOA operating at an enterprise level.

The problem is that this prerequisite has a near-zero probability of being implemented meaningfully in any enterprise of moderate or large size. We can have meetings. We can have vision statements. We can have architectural initiatives. We can have well-intentioned business and technology stakeholders committed in principle to SOA.

None of this matters.

An SOA can expose a trivial service -- e.g., a holiday calendar that consuming systems use to determine business days in the U.S. and in other countries. While useful, the real promise of SOA, as an architectural style, stems from the notion that we can extract object-oriented principles, such as encapsulation and reuse, from the realm of application-level runtimes and implement them in a network-mediated enterprise environment -- meaning that we can provide a functional decomposition of LOB-specific applications, identify shared functionality across the LOBs, and consolidate those functions into unique services that can be consumed across LOBs through standardized network-based communication transport and messaging protocols.

This sounds great as both an architectural objective and as a business case pitched at the enterprise level. True, there are a number of challenges to be overcome: Stove-piped applications need to be decomposed and reassembled. Stove-piped data stores may need centralization--and surely need to be refactored so that LOB-specific data are derived from an enterprise-level ontology and concomitant semantic conventions. Tools need to be selected and implemented. Etc. These challenges are significant but not insurmountable as technical exercises.

Unfortunately, these technical exercises never take place in an organizational vacuum. And this is where some nasty realities rear their heads. Consider:

1. Large enterprises are organized into LOBs. Governance, accountability, profit and loss, rewards, etc. all get defined in these terms. Yes, there are enterprise-wide governance structures. But they function more like a federated aggregation of individual constituencies than as constituent components of a monolithic organization focused on the interests of the enterprise as a whole. (Sounds pretty much like a legislative assembly, doesn't it?) Organizations like this function by striking bargains and making compromises. This is not an environment conducive to promoting a cross-LOB decomposition of applications and data stores. There are too many LOB-specific constituencies that will not see how this benefits their organizations, their personal interests, or the interests of their customers.

2. Large size presents other problems. Even in the stove-piped world, not every technology function is packaged up into the one big box. There are networks, messaging systems, source control and deployment systems, system administrators, DBAs, etc. As we all know, this engenders more complexity in implementation, problem resolution, and day-to-day application management than comparable activities executed by programmers in a development environment. Decomposing business applications into functional services expands this complexity geometrically. And I would assert that, in large enterprises, the logic of geometric complexity serves to diminish the perceived benefits of application rationalization through SOA in the eyes of the very decision makers whose stove-piped LOB responsibilities make them predisposed to stove-piped solutions in any event.

3. Finally, there is the very thorny problem of LOB-specific business complexity in cases of proprietary product lines. Increasingly, large economies in the Western world are dominated by firms that produce proprietary services and intellectual products. Commodified products in traditional manufacturing industries have moved to low-wage economies. Automating business processes attending proprietary products and services typically means automating a complex ensemble of business rules. Complexity comes in the form of contingent logic, exceptions to contingent logic, exceptions to exceptions, and data elements whose semantic meaning are coupled tightly to a given LOB. In such an environment, it may be impossible, and almost certainly cost-prohibitive, to produce a functional decomposition and correlative abstractions resulting in business services that are reusable across LOBs while meeting the business needs of those units. A service interface that is nothing more than an if-then redirect to multiple LOB-specific implementations offers no value at all.

Note. I am not claiming that these barriers to effective SOA represent irrationality. Quite the opposite. Rationality resides at the level of the individual agent. Enterprises are neither rational nor irrational. Rather, they are ensembles of (complex) rules and concomitant incentives within which rational agents act. On this view, rational agents within large enterprises, particularly key decision makers, respond to LOB-specific incentives, organizational scale, and the inherent complexity attending proprietary business processes (and the software that automates them) in ways that militate against the architectural objectives of SOA.

Does this mean SOA is impossible? No. But I would expect that you will find successful implementations mostly in the form of utilities that are simple in function and uncontroversial in scale. A holiday calendar web service comes to mind. So do utilities like the Google Docs office suite. In such cases, the problem domain is simple, well understood, and noncontroversial. My experience tells me that value-add business applications almost never reflect such criteria. And so, for the reasons given above, you are not likely to see successful SOA implementations involving such applications. This leaves room for SOA. But perhaps not for all the hype surrounding it as the next great thing in enterprise computing.

WELCOME TO “Q.E.D.”

I am a software architect who focuses on problems and challenges attending the building, testing, and deployment of business applications in an enterprise setting.

Doing these things well is hard. It requires an understanding of how to assemble software building blocks into runtime applications that are testable, deployable, monitored, and updatable over time. It also requires knowledge of how enterprises behave, for this is the context within which applications are written, tested, deployed, monitored, and governed.

As it happens, these skills are not dissimilar from those required for modeling and testing problems in the social and physical sciences — areas of inquiry with which I have some passing familiarity through education and previous professional experience. The substantive domains and some of the technical tools may differ. But underlying principles of abstraction, encapsulation, and modularity span both engineering and scientific disciplines.

And sometimes, the technical tools overlap. Dynamic simulaiton modeling (e.g., system dynamics and discrete event simulation) is an example. Social and physical processes execute over time. So do software processes. Both, therefore, lend themselves to dynamic simulation modeling.

I grew up intellectually with a steady diet of comparative statics in graduate economics and political science (via game theory and cognate rational choice approaches). And so, I am embarrassed to admit that the importance of processes executing over time eluded me until I was forced to confront their import in problems related to the functional and performance testing of distributed software systems. I think I get it now (better late than never). Consequently, I have been paying increasing attention to the application of dynamic process modeling/simulation techniques to domain areas of interest to my current professional focus.

And thus, I will be using this blog to explore technical issues related to these and other related interests. An underlying theme that will tie these posts together, apart from what I have said already, is a hopefully relentless commitment to sustained logical argument supported by systematically assessed empirical evidence. In short, the kind of findings worthy of the epithet, Q.E.D.