|
Nick Gall's Weblog
 |
Saturday, January 31, 2004 |
Standardization is the fundamental source of increasing returns.This is a pretty profound statement:
Notice that, in the case of organizations and institutions as in the case of technology, standardization is arguably the fundamental source of increasing returns.
Richard N. Langlois, Knowledge, consumption, and endogenous growth
I'm going to have to reconcile this with my prioritization of my four "economic forces:" commoditization, virtualization, integration, and innovation. I'm also going to have to reconcile this with my prioritization of "modularity." I'm thinking that modularity is a means, and standardization is the end. Thus, contrary to some opinions (perhaps even my own at times): standardization is not a means of increasing modularity; modularity is a means of increasing standardization. This includes such forms of modularity as "division of labor."
The reasoning behind Langlois' assertion is I think captured in part by the following quote:
Consider the example of printing. If one is going to run off a few copies of a memo, a photocopy machine will do the trick. If one needs several hundred copies of documents on an ongoing basis, it might be worth investing in a small offset press. For even larger predictable production runs, it would pay to have a more serious printing press. As volume and predictability allow greater "durability of dies," unit costs decline. This is an effect of growth in the extent of the market distinct from the division of labor narrowly understood. And the reason that costs decline as dies become more durable is not because the knowledge itself leaks out but because the knowledge – created once – is spread over more and more units.
This means that increasing predictability in the system's environment (a market) favors increasing standardization of the system (the printing press). Even more generally: the behavior of the environment shapes the behavior of the system. But note that the system itself is part of the environment, so this creates a virtuous circle of environment shaping system shaping environment. And this shaping is in the direction of ever greater predictability and standardization.
(Is standardization then just a type of predictability? Is the direction of evolution then in the direction of organisms with ever greater predictability, including "predictive power"? Is the direction of evolution in the direction of ever greater standardization? Are ever greater predictability/predictive power the same as adaptability? How does this fit with increasing entropy?)
7:29:02 AM 
|
|
Ben Fry's Images.While looking for the intersection of blogging and the Knight Science Journalism Fellowship for a friend, I discovered the blog of former fellow which links to some amazing information visualization images by Ben Fry of MIT's Physical Language Workshop. Check them out. Here's an example called tendril: "tendril is a web browser that constructs typographic sculptures from the text content of web pages. the first page of a site is rendered as a column of text. links in the text are colored, and when clicked, the text for the linked page grows from the location of the link." 
6:35:31 AM
|
|
|
Saturday, January 10, 2004 |
The Heterogeneous Self.Self is hetro across time (diachronic?): old self, current self, future self.
Self is hetro in time (synchronic?): hetro components compose the self.
Both forms of hetro entail competition and cooperation.
7:09:52 AM
|
|
Why so few references to "Coordinated Change"?There are only about 1,880 Google hits for the query:
("coordinating change" OR "coordinated change" OR "to coordinate change")
This is surprisingly low, given how central I think this issue is to evolution (See Structure = Coordinated Heterogeneous Change?). Is there a different phrase for the same concept? E.g., Cooperative change?
Later, I used the plural, "changes," in the query:
("coordinating changes" OR "coordinated changes" OR "to coordinate changes")
And this resulted in about 6,250 hits. Still fewer than I would have expected. Also, "coordinated change" refers to the concept, while "coordinated changes" often refers to specific examples.
I did discover that "coordinated change" is often associated with attempt to refute Darwin's theory of evolution. It is part of the arguments around "irreducible complexity". Such critiques associate complexity of a change with the number of coordinated changes that would be needed to effect that change.
This reinforces my emerging understanding of complexity as a relative measure -- relative to a specific process, e.g., designing, building, using, repairing, changing -- not an absolute measure of an entity. Thus, "a software application is complex" is actually a non-sequitur (or at best an incomplete statement). The app may be simple to use, simple to install, and simple to update, but complex to design, complex to build, and complex to integrate. Furthermore, what makes these processes complex is the degree of coordination required. Thus, to manage complexity, we must modularize coordination.
6:25:33 AM
|
|
|
Friday, January 09, 2004 |
Structure = Coordinated Heterogeneous Change?You never know where Google will take you.
I was checking SiteMeter to see who had hit my blog lately (and, more importantly, why they had hit my blog), and I saw that someone had hit my blog while using Google to search for "dissipative structures and surfactant." It turns out that my blog discusses each concept, but in different entries. Since I was curious as to any possible connection that I hadn't made before, I did the same Google search.
I didn't find anything that I understood well enough to see any definitive connection, but I did discover two fascinating things in looking.
I read this as saying that order (stability) can arise spontaneously from disorder (chaos) through "coherence." Random fluctuations cancel one another out. Coherent fluctuations amplify one another into a stable "dissipative structure." This reminded me of a passage in "Entanglement" by Amir D. Aczel (a gift from my brother-in-law Clement Wang) about how laser light is coherent light and how a Bose-Einstein condensate is an ensemble of atoms "in a coherent state, just like laser light." (p. 53). This suggests how stasis (stability, structure, fixed points) and change are a duality: statis is coherent change.
Now what does "coherent" mean in all this (e.g., "coherently amplified")? Well certainly, "coherent" means "coordinated," "synchronized," etc. Aczel uses the term "in phase" when describing coherent (laser) light. So coherent suggests a time dimension to the coordination, i.e., coherence is coordinated in time, synchronized. Note also that laser light and Bose-Einstein condensate are both formed from homogeneous coherent fluctuations (e.g., photons in the case of laser). So perhaps matter is composed of coherent heterogeneous fluctuations? For example, a hydrogen atom is composed of two heterogeneous fluctuations (a proton and an electron) that coordinate to form an atom. To extend the example, two hydrogen atoms and one oxygen atom coordinate to form a water molecule. This molecule is itself a fluctuation.
Food for further thought.
3:34:35 PM
|
|
|
Tuesday, January 06, 2004 |
|
Friday, January 02, 2004 |
Interesting definition of a "standard."
A standard is a common language that promotes the flow of goods between buyer and seller and protects the general welfare.
I've never seen a "standard" defined as a "language." Given that XML is turning every standard into a "language," I thought it was quite apropos.
3:20:08 PM
|
|
Federated Specifications.I recently saw several more examples of people making the connection between Web Services and "separation of concerns" (a la Aspect-Oriented Programming). First, the IBM/Microsoft whitepaper entitled "Secure, Reliable, Transacted Web Services: Architecture and Composition" (also available as a pdf from IBM) makes the same overall point I made in my entry regarding aspect-oriented programming (AOP) and SOAP:
1.1 Composable Services
As we've done with SOAP and WSDL, IBM, Microsoft, and our partners have followed the design principle of composability in the definition of Web service specifications. The approach we have followed is based on the design principle of composability in the definition of Web service specifications. Each specification we developed solves an immediate need and is valuable in its own right. For example, developers can adopt reliable messaging to simplify their solution development or adopt BPEL4WS to define their service compositions. And while each specification stands on its own, they are designed to be combined and work with each other.
We use the term composability to describe independent specifications that can be combined to provide more powerful capabilities. Operating system and middleware providers can support composed capabilities, e.g. providers can integrate reliable messaging support for communicating BPEL4WS processes. This example combines two independent specifications to simplify the development of communicating processes by eliminating the need to handle message communication errors during process design.
Composability enables incremental consumption or progressive discovery of new concepts, tools and services. Developers only need to learn and implement what is necessary, and no more. The complexity of the solution increases only because the problem's requirements increase, and is not due to technology "bloat."
Composability has and continues to be one of the key design goals for Web services. Over the last several years we have defined the most basic Web service specifications (SOAP and WSDL) to inherently support composition. One of the fundamental characteristics of a Web service is a regular, multi-part message structure. This structure enables the composition of new functionality. New message elements supporting new services may be added to messages in a manner that does not alter the processing of existing functionality. For example, it is possible to independently add transaction identifiers and reliable messaging sequence numbers. The two extensions do not conflict with each other and are compatible with pre-existing message structures.
This is exactly what I pointed out in my September 2003 entry: "Each header (or set of related headers) deals with a distinct set of concerns." Unfortunately, the IBM/Microsoft whitepaper then goes on to use the term "Service Composition" in a completely unrelated way (see section 3.8) to refer to composing services via BPEL.
I also came across an entry discussing Project Liberty vs. WS-Federation in Radovan Janecek's blog, in which he cites Jeff Schneider saying, "I'm a huge fan of 'concern-based protocols'." Here's the full cite:
I'm a huge fan of "concern-based protocols". Thus, I like having 'trust' as its own protocol - and 'privacy' as another protocol. I don't like mixing concerns in a single protocol; which I believe Project Liberty is guilty of. From a cursory view, it is appears as though WS-Federation covers the bulk of what is actually needed. I'm not an expert in this area - but so far, it looks 'good enough'.
Obviously, Jeff is getting at the same point, but calling it something different: concern-based protocols. I googled the term and found only Radovan's and Jeff's usage.
However, the term "composable specification" is beginning to pick up steam. As of January 2, 2004, there were 118 hits from my Google search, including a draft of the Architecture of the World Wide Web: "Separating the concepts content, presentation, and interaction allows more easily composable specifications."
One other sighting is from xmlhack: "Trends in modular XML specifications at the W3C:" "The recent publication of three W3C documents, XForms Proposed Recommendation, XML Events Proposed Recommendation, and xml:id Requirements may mark a new trend toward fewer standalone XML vocabularies and more "building block" specifications."
So now we have several terms for this evolving concept:
- Composable services (too confused with BPEL-style composition)
- Composable specifications
- Composable standards (used to describe Microsoft's GXA)
- Modular [XML] specifications
- Federated standards (Google search hit Project Liberty, GXA, W3C, UBL etc.)
- Concern-based protocols
I prefer the term "federated specifications" because it highlights the autonomy of the specs being combined. I will have much more to say on this subject.
7:12:04 AM
|
|
|
