Ironick

Generic Identifiers aka Web Scale Identifiers

The most important aspect of WOA is application neutral interfaces (or as some prefer application generic interfaces). Since interfaces are constituted by their IFaPs (Identifiers, Formats, and Protocols), this means that all three aspects must be made "as generic as possible, but not too generic" (playing off Einstein's quote regarding simplicity).

We all know about generic interface operations, eg HTTP's GET, PUT, POST, DELETE, et al. And we are beginning to see more examples of generic formats (or generic schemas if you prefer). For example, ATOM and derivatives like GData.

But its harder to find compelling examples of generic identifiers that are web-oriented, ie, defined as URLs. Well, I just found at great example at the BBC!

| View | Upload your own

See slides 35 and on.

The basic idea is that MusicBrainz uses a GUID-based set of identifiers to uniquely identify artists, albums, and songs, like this URL for Led Zeppelin. So instead of inventing YAUN (Yet Another URL Namespace), BBC wisely decided to reuse MusicBrainz -- as have others (last.fm).

While I'm not sure I like the machine-generated, non-human friendly GUID approach, I do love the idea of id sharing across organizations. Such sharing is the essence of the network effect.

For more information see Web Scale Identifiers, Automatically Linking Artists, Permanent Web IDs, It's All About the URL, and BBC/Music/Brainz. The BBC definitely gets WOA and network effects.

The Tao of Modularity.

Chapter 11

Thirty spokes share the wheel's hub;
It is the center hole that makes it useful.
Shape clay into a vessel;
It is the space within that makes it useful.
Cut doors and windows for a room;
It is the holes which make it useful.
Therefore profit comes from what is there;
Usefulness from what is not there.

I read the Tao Te Ching many times as a philosophy major at Yale and for years after, but I haven't read it the last ten years. I guess I'd better read it again. "Usefulness [comes from] what is not there" beautifully states the value of modular extensibility. What is intriguing is the distinction between profit and usefulness.

At first pass it seems obvious that the maker of a modular object, like a clay vessel is paid for (on thereby makes a profit from) "what is there". On second pass, it strikes me that the user of the vessel makes a profit from "what is not there", either by adding it on, or by using the space to some purpose, say transporting liquid in the vessel. So the last two lines could be recast:

Therefore profit to the maker comes from what is there;
Profit to the user from what is not there.

Finally, the more I think about it, the more I believe that the profit to the maker really comes from what is not there. A potter buys a block of clay at a certain cost. Her "value add" is the vessel shape she forms the clay into. Someone pays her more money for the clay in the shape of a vessel than in the shape of the raw block of clay because the buyer values the shape--what is not there. Assuming she uses the entire clay block to make the vessel, her profit is the price of the vessel minus the price of the clay block. Now suppose she could get the same price for a vessel made from only half the block of clay. She has doubled her profit by halving "what is there." So the last two lines would be more clear if they were recast as:

Therefore profit is limited by what is there;
Usefulness from what is not there.

Which is another way of saying "Less is [worth] more." Which is why intangible artifacts (aka intellectual property) are the most profitable. There is no there there.

GM's reuse strategy.

This article about GM's efforts to increase reuse of part designs, touches on several very timely topics. First, software designers are not alone in preferring to design unique parts, rather than use existing ones. I find it the epitome of irony that the industry that IT seeks to emulate in its use of interchangeable parts, itself struggles with the issue! Second, to enable reuse, even of physical part, requires substantial IT investment to enable designers to simply find a part to reuse. Third, it touches on the "monoculture" issue being debated with regard to widespread use of Windows. In GM's case, when more product lines share a common part, design flaws in the part have wider repercussions.

Another nail in the coffin of OMG's MDA.

Saw this excellent article blogged by metamodel (itself an excellent resource). IMO, It very politely and constructively demolishes any hope that the OMG's Model Driven Architecture effort (especially PSMs--Platform Specific Models) will achieve any major benefits. I put my money on the more decentralized and federated approach of Domain-Specific Models (aka Domain-Specific Languages) (here's an upcoming workshop on the subject).

Tight coupling means tight tolerances.

Most discussions of tight/loose coupling focus on the degree of information sharing across the interface. Here's an additional perspective that came out of a discussion with my colleague, Tom Murphy.

The tradeoff between tight and loose coupling is the trade off between efficiency (performance) and "robustness". Tightly-coupled systems are more "fragile" in that they "break" when a input is not "within tolerance," e.g., did not arrive fast enough, has an error in it. The "tight" in tightly-coupled actually refers to "tight" tolerances for errors. Loosely-coupled systems have loose tolerance for errors (more and/or bigger).

The most robust systems impose tight tolerances on output, but impose only loose tolerance of imput. By doing so, such systems "amplify correctness." In other words, they are anti-entropic amplifiers.

MDO == Aspect Oriented?

I saw this "Vision Statement" on the web site of an MIT professor of engineering, Olivier L. de Weck:

The success of Engineering Systems is mainly determined during conceptual design, where quantitative methods are immature. Some high capital investment systems (such as new automobiles, aircraft or satellites) fail economically or technologically due to an inadequate understanding of their underlying architecture. Also, it is observed that many engineering systems are not utilized according to their original intent or specification. One hypothesis is that the likelihood of system success and longevity can be increased by extending quantitative methods, such as multiobjective optimization, to the conceptual phase of system design. The vision of Prof. de Weck’s research program is to build a rigorous methodological bridge between System Architecture and Multidisciplinary Design Optimization (MDO), allowing systems to satisfy multiple criteria, while exhibiting desirable lifetime properties. Of particular interest are the challenges posed by families of systems/products that are built from a common platform.

Sounds like engineering systems and IT systems have some of the same basic needs: more mature (quantitative) design methodologies, flexible use beyond original intent, multidisciplinary designs. MDO seems focused on the same concerns as aspect-oriented design in IT systems.

Carving meat "where the natural joints are" isn't as easy as it sounds.

In a famous passage in Phaedrus, Plato defines the two fundamental principles or processes of rational thought (see below for the complete passage): synthesis and analysis.

In describing analysis, Plato uses a now famous metaphor: "[The principle] of dividing things again by classes, where the natural joints are, and not trying to break any part, after the manner of a bad carver." What could be more intuitive than carving reality at its "natural joints" as one carves meat at its joints? As Daniel Dennett would say, this metaphor is a powerful "intuition pump".

The only problem is, there is no "natural" way of jointing meat! This fact was just brought home to me by an amazing report entitled, "Successful business componentisation implies finding the natural joints". The obviously broadly-read author (whom I believe is Richard Pawson formerly of CSC Research and now of www.nakedobjects.org) unites the finer details of philosophy, IT, and beef butchering. Richard discusses "the different standards for jointing a carcass of beef in England, France and the United States," and illustrates it with the following diagram:

This is a graphic demonstration that there is no "natural" way to cut beef at its joints. Although "all have a common goal to maximise the total revenue, or yield, from the carcass" the "standard" jointing in a given culture is the result of socio-economic-culinary preferences in a given culture that change over time!

As my philosopher-friend Keith pointed out, this analysis is worthy of the best deconstructionists.

What I also find incredible (as usual) is how I came across this amazing report. I was reading "Design Rules: The Power of Modularity", which used Plato's "carving at the joints" quote. I remembered how much I liked the quote, so I Googled it to get the exact quote to add to my growing list of quotes (which I'll link to someday). That's how I found the report. Of course, then I go to read the context of the quote in Phaedrus, only to be blown away by the fact that is it part of Plato's definition of dialectic, which is central to my evolving philosophical system as well as my evolving understanding of IT system design based on aspect-oriented modeling:

[I]f I think any other man is able to see things that can naturally be collected into one and divided into many, him I follow after and walk in his footsteps as if he were a god. And whether the name I give to those who can do this is right or wrong, God knows, but I have called them hitherto dialecticians.

Its all coming together is a frighteningly powerful way.

Phaedrus

Socrates: It seems to me that the discourse was, as a whole,
[265d] really sportive jest; but in these chance utterances were involved two principles, the essence of which it would be gratifying to learn, if art could teach it.

Phaedrus: What principles?

Socrates: That of perceiving and bringing together in one idea the scattered particulars, that one may make clear by definition the particular thing which he wishes to explain; just as now, in speaking of Love, we said what he is and defined it, whether well or ill. Certainly by this means the discourse acquired clearness and consistency.

Phaedrus: And what is the other principle, Socrates?
[265e]
Socrates: That of dividing things again by classes, where the natural joints are, and not trying to break any part, after the manner of a bad carver. As our two discourses just now assumed one common principle, unreason, and then,
[266a] just as the body, which is one, is naturally divisible into two, right and left, with parts called by the same names, so our two discourses conceived of madness as naturally one principle within us, and one discourse, cutting off the left-hand part, continued to divide this until it found among its parts a sort of left-handed love, which it very justly reviled, but the other discourse, leading us to the right-hand part of madness, found a love having the same name as the first,
[266b] but divine, which it held up to view and praised as the author of our greatest blessings.

Phaedrus: Very true.

Socrates: Now I myself, Phaedrus, am a lover of these processes of division and bringing together, as aids to speech and thought; and if I think any other man is able to see things that can naturally be collected into one and divided into many, him I follow after and

walk in his footsteps as if he were a god.

And whether the name I give to those who can do this is right or wrong, God knows,
[266c] but I have called them hitherto dialecticians.

Loosely Coupled Consistency.

I keep seeing more discussions of the need to tolerate a certain degree of error and inconsistency in complex systems. Just read Carlos' post citing an interview with Jaron Lanier discussing the need to apply error-tolerant pattern matching to protocol design.

This is roughly related to the work on ACID vs BASE that I've run across from two completely independent sources. One is Rohit Khare's BASE: Best-effort networking, Approximate estimates, Self-centered trust management, and Efficient encoding. The other is Armando Fox et al's BASE: Basically Available Soft state Eventual consistency". Apparently, these two notions of BASE were created completely independently.

This is also related to the Internet "Robustness Principle" attributed to Jon Postel: "Be liberal in what you accept, and conservative in what you send." Tim Berners-Lee also cites this principle as a guiding principle in his design of the World-Wide Web, though he calls it the principle of "Tolerance."

Finally, this is all related to Signal Processing. See my previous post on Signal Processing as the Science of Patterns. Signal Processing differs from Information Processing in that it expects information to be noisy, imperfect, inconsistent, etc., whereas Information Processing is based on an expectation of perfect "digital" information.

Taken together, these are all approaches for amplifying order out of disorder, perfection out of imperfection, consistency out of inconsistency, rhythm out of noise: tolerate more noise in what you recognize than in what you generate.

Software Architecture is "Union of All Manuals".

This definition fits in nicely with the (re)emergence of an architecture as a set of views, each couched in a domain specific language:

In programming, the term architecture was first used to mean a description of a computer system that applied equally to more than one actual system. In 1969, Fred Brooks and Ken Iverson called architecture the "conceptual structure of a computer...as seen by the programmer". A few years later, Brooks (crediting Gerald Blaauw for the term) defined architecture as "the complete and detailed specification of the user interface. For a computer, this is the programming manual. For a compiler, it is the language manual... For the entire system it is the union of the manuals the user must consult to do his entire job." A careful distinction was drawn between architecture and implementation. Quoting Blaauw, Brooks writes, "Where architecture tells what happens, implementation tells how it is made to happen." This distinction survives today, and in the era of object-oriented programming it thrives. [emphasis added]

Find what varies and encapsulate it.

It seems to me that the Dependency Inversion Principle, the Bridge Pattern, and the Spanning Layer concept are all saying the same thing: enable independent change of a concrete consumer (using) system and a concrete provider (implementing) system by making them both depend on a two-sided abstraction layer. And all of these seem to be examples of "Find what varies and encapsulate it."