Nick Gall's Weblog
[NOTE: I have moved. My new blog is ironick.typepad.com.]
        

Nick Gall's Weblog

Friday, August 29, 2003

Systinet Include Support For SOAP 1.2 and WS-Security.
SOAP 1.2 and WS-Security support is coming sooner than I expected.
2:09:36 PM      

Sun Wants to Shine on Blogs: The PR Power of Weblogs.
Apparently, Mark Bauhaus (Vice President, Sun ONE Java Web Services) wants to the chance to appear on Mitch Kapor's influential blog. (Or perhaps just his PR flack wants him to.) Interesting use of Google to discover that it was Mark, given that Mitch redacted the email. The phrase "disruptive competitive advantage" was the giveaway.
1:39:35 PM      

Wednesday, August 27, 2003

Whitepaper on Java Business Integration (JBI) - JSR 208.
Collaxa seemed to like it. I didn't. I skimmed the whitepaper. First, anyone who still thinks in terms of a "bus" just doesn't get it. Web Services Architecture (WSA) is network-oriented, which means "routing" happens at the SOAP message level. Routing is what distinguishes a bus from a network, thus the "Normalized Message Bus" shown in the white paper's functional architecture should be a "Normalized Message Network."

Second, the key to business integration is interoperability, and interoperability is best achieved by standardizing at the network (or wire) level--not at the software binding level. Thus, the real action in business integration is defining the identifiers, formats, and protocols (IFaPs) that enable business process interoperability across heterogeneous business processes.

Don't get me wrong, standardizing the J2EE environment (language) bindings that enable access to the emerging IFaPs that define the WSA is necessary work, but it is merely the icing on the cake (made from syntactic sugar BTW <grin>). Focusing on the J2EE bindings (whether you call them SPIs or APIs) or the container model as the key to business integration success is like focusing on the Winsock APIs or Berkeley Sockets APIs instead of the TCP/IP IFaPs as the key to network integration success!

The software/API mindset of Sun/Java rears its ugly head again in this white paper. And here I thought seemingly metadata-centric JSRs (175, 181, 207, 208) were a sign of hope. What's ironic is that the description of the proposal for JBI (JSR 208) seems to get it, i.e., it discusses the need for standard metadata (aka IFaPs). But that understanding is absent from the white paper, which barely mentions metadata. I guess I'll have to wait to see the spec.


9:36:24 AM      

Tuesday, August 26, 2003

Spanning Layer Metrics.
Maven, an open source project management tool, uses JDepend, a design quality metrics tool. The design quality metrics it purports to measure are the dependencies among modules (in this case Java classes and packages). It is based on Robert Martin's OO Design Quality Metrics: An Analysis of Dependencies (1994). Here is an example of a JDepend report.

What's interesting about Martin's approach is his relationship between abstraction and stability. His claim is that highly stable layers should be abstract, and that highly volatile layers should be concrete. Why? I didn't find this immediately intuitive. Why not have everything be volatile? or stable? Then I thought of it in the following terms. If there is a certain way of doing something that has stood the test of time, e.g., a particular sort module, then it makes sense to make it as abstract (i.e., generic, general purpose) as possible, so that many modules can use it (i.e., depend on it). Conversely, if the best way of doing something is still being actively debated and experimented with (e.g., ontology representation languages), it makes no sense to abstract it for more general purpose use. Such volatile modules should be concretely embodied in their specific domains.

Martin's metrics are interesting because they encourage a spanning layer style of abstraction (i.e., an abstraction layer that abstracts implementation as well as application). Martin gives the example of a copy module that uses two abstract classes (reader and writer) as a good stable abstraction layer because the concrete classes (e.g., keyboard reader and keyboard writer) are dependent on the abstraction layer, not the other way around:

Martin's Dependency Inversion Diagram

What would make Martin's example even more compelling is to abstract the copy module into a pipeline module, which invoked a transform abstract class. This would enable a diverse set of uses of the pipeline abstraction, beyond just copying; for example filtering, sorting, etc. In fact, this is roughly equivalent to Unix pipes, a spanning layer of great stability. Unfortunately, Martin's metrics don't distinguish between implementation and application abstract classes. I wonder if other metrics do?

Martin calls the switch from a design in which the general (abstraction) depends on (invokes) the specific (instantiation) to a design in which the specific depends on the general a dependency inversion. And he states the following dependency inversion principle:

High level modules should not depend upon low level modules. Both should depend upon abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.

This is essentially an argument for abstract frameworks (J2EE containers, Microsoft Foundation Classes) over concrete component libraries. Calling a lower level concrete component makes the higher level component dependent on something more volatile. There is a good paper entitled Aspect-Oriented Dependency Inversion that discusses the principle in more depth and relates it to Aspect-Oriented Programming.

This begs the question of when one abstract (general) class is more general than another abstract class, e.g., is copy more or less general than reader or writer? My guess this question is related to the Aspect-Oriented Programming issue of the tyranny of the dominant decomposition. That is, a general/specific ordering is relative to a particular set of concerns. Thus, from the POV of the reader, copy is a specific type of transformation, and from the POV of copy, reader is a particular kind of source.

One other interesting association made by Martin is between abstraction and policy:

However the "Copy" module is not reusable in any context which does not involve a keyboard or a printer. This is a shame since the intelligence of the system is maintained in this module. It is the "Copy" module that encapsulates a very interesting policy that we would like to reuse.

Compare this to the following definition of policy: Policies are rules governing the choices in behavior of a system. Are policies then the highest level of abstraction?


5:46:39 PM      

Friday, August 22, 2003

Red Hat and Microsoft: Both Enforce Copyrights.

A very interesting article (and active discussion thread) on the impact of copyright enforcement on buying behavior. Ernie Ball decided to switch to Linux after being busted by the BSA for copyright infringement of (apparently) Microsoft software.

However, anyone who thinks that by switching to Linux she can make this problem go away is naively WRONG. Here is the REALITY from Red Hat's latest License Agreement (which is the distro Ernie Ball is using):

4. REPORTING AND AUDIT. If Customer wishes to increase the number of Installed System, then Customer will purchase from Red Hat additional Services for each additional Installed System. During the term of this Agreement and for one (1) year thereafter, Customer expressly grants to Red Hat the right to audit Customer's facilities and records from time to time in order to verify Customer's compliance with the terms and conditions of this Agreement. Any such audit shall only take place during Customer's normal business hours and upon no less than ten (10) days prior written notice from Red Hat. Red Hat shall conduct no more than one such audit in any twelve-month period except for the express purpose of assuring compliance by Customer where non-compliance has been established in a prior audit. Red Hat shall give Customer written notice of any non-compliance, and if a payment deficiency exists, then Customer shall have fifteen (15) days from the date of such notice to make payment to Red Hat for any payment deficiency. The amount of the payment deficiency will be determined by multiplying the number of underreported Installed Systems or Services by the annual fee for such item. If Customer is found to have underreported the number of Installed Systems or amount of Services by more than five percent (5%), Customer shall, in addition to the annual fee for such item, pay a penalty equal to twenty percent (20%) of the underreported fees. [Emphasis Added.]

Here is a recent debate on the issue. As you can see, the relationship between this clause and the GPL is a bit murky. I agree with the viewpoint that the RH distro contains both GPL and non-GPL code, so it is the non-GPL code that is restricted from further copying. If someone wanted to go through the effort of subsetting out just the GPL code, it would work and be legal to copy widely, so RH is not in violation of the letter of the GPL, but it would be a lot of effort to do so on an ongoing basis. I wonder how the GNU folks feel about it though. I think I will ask them.

It will be interesting to see what happens when the all but one of the older versions of Red Hat (which apparently don't have this clause) go off support at the end of the year, and a bunch of users have to upgrade to RH Enterprise Linux (which does).

Here's the punch line: Red Hat is a member and on the board of the Software & Information Industry Association, which like the BSA, has a piracy watchdog division. So guess what, if Ernie Ball makes unauthorized copies of Red Hat products, someone can drop a dime on it all over again--here's the toll free number.


6:21:43 AM      

Thursday, August 21, 2003

Sync and Stabilize (aka Spiral Concurrent Engineering)

At the XML Web Services One conference on Wednesday, Michael Cusumano, an author and professor at MIT's Sloan School of Management, revealed preliminary findings from a yet-to-be published survey of the latest worldwide trends in software development.

What was clear from the research is that a majority of developers are undertaking projects that use the so-called "sync-and-stabilize" approach, in which members of a development project work on modular blocks and then synchronize their code with other members on a regular basis throughout the life of the project. It also requires that they stabilize, or debug, that work on a continual basis as well.

In a study of 150 software projects conducted jointly by MIT, Harvard Business School, the University of Pittsburgh and Hewlett-Packard Co., 64% of developers worldwide said they worked on projects in modules. A majority also produced "builds" -- or individually coded components -- on a daily basis in the early or middle stages of a project. The rates were 63% in the United States, 57% in Europe and 53% in Japan. The exception was India, where only 27% of developers were in the daily-build habit.

Not surprising, except that it's an empirical study and it's from the MIT Sloan School. May be worth checking out.


2:50:22 PM      

WSDM (IBM et al) vs. WSMF (HP et al).

COMMENTARY - WSDM THE MISSING LINK. Web Services will not be used pervasively until we have platform neutral management. We assess two recent and very important announcements in this area, and revise our forecasts. [CBDI Newswire]

A good analysis of the two proposals, though IBM's WSDM can hardly be called a concrete proposal yet. The WSDM presentation currently only outlines concepts and principles.


10:14:59 AM      

A Little Linux Advice is a Dangerous Thing.

Gartner Ignored: Fortune 1000 Adopt Linux.. "As far as their internet presence goes, big companies are doing the exact opposite [of Gartner's 'go-slow' approach to Linux]; over 100 enterprise sites run by probably the very same Fortune 1000 and global near equivalent companies that recieved the SCO letter have switched to Linux since May, including Schwab.com. [Source: Email from Mike Prettejohn of Netcraft in Tim O'Reilly's weblog.]

Amusing set of disparaging comments about Gartner in the comments to the O'Reilly article. To some degree, the disconnect is between the world of IT developers, which is fact based, and the world of IT management, which is perception-based.


8:59:45 AM      

A Simple Guide to the A-List Bloggers.
Hilarious because its so true. It's amazing how many of these bloggers I have come across in my brief time blogging.
6:33:54 AM      

Monday, August 18, 2003

Flexible Production -- Another Spanning Layer.
I've talked in the past about how IP is a spanning layer, and intermodal shipping is a spanning layer. Here's another example: flexible manufacturing. I just read a New York Times article on flexible production that describes how different types of cars can be produced on the same assembly line. The key?

Flexible assembly plants require three key attributes: programmable welding robots, standardized production practices and one-size-fits-all conveyors for the assembly line. [emphasis added] Automotive News

The last requirement dovetails with my definition of SOA (aka spanning layer), which requires the concept of generic envelope or container processing. The container becomes the fixed point, and everything else is variable:

To make this possible, Chrysler designed a flexible pallet that can convey a variety of models on the assembly line. Chrysler began standardizing production in 1998. [emphasis added] Ibid.

By designing an assembly line with the pallet as the focal point, you can more easily minimize the coupling between that pallet and what it carries. This enables adapting of the design (i.e., the network, the assembly line) itself, not just adapting the components that populate the design.

BTW, it is interesting that in the automotive industry, it is the product (automobile) that is fairly fixed, while the (production process) assembly line is becoming adaptive. Contrast that to the software industry, where the product is adaptive, while the production process is fixed.


10:34:09 AM      

Tuesday, August 12, 2003

A Spanning Theory.
An interesting article on when to include suppliers in the design phase of concurrent engineering contained a quote from Albert Einstein that I had never seen before:

A theory is the more impressive the greater the simplicity of its premises, the more different kinds of things it relates, and the more extended its area of applicability.

In researching the origin of the quote, I discovered it is paraphrased in an alternative way:

[A law] is more impressive the greater the simplicity of its premises, the more different are the kinds of things it relates, and the more extended its range of applicability. [differences emphasized]

In either case, the description of the power (or impressiveness) of a theory (or law) exactly matches the description of a spanning layer, a phrase coined by David D. Clark, former chair of the Internet Architecture Board (IAB):

Certain protocols are designed with the specific purpose of bridging differences at the lower layers, so that common agreements are not required there. Instead, the layer provides the definitions that permit translation to occur between a range of services or technologies used below. Thus, in somewhat abstract terms, at and above such a layer common standards contribute to interoperation, while below the layer translation is used. Such a layer is called a “spanning layer” in this paper. Interoperation, Open Interfaces, and Protocol Architecture

Huh? This doesn't sound anything like Einstein's quote. Well, what Clark is describing is any spanning layer—an impressive one or an unimpressive one. He goes on to describe the attributes of an impressive spanning layer (i.e., the Internet) in terms of an hourglass:

The [spanning layer] is shown as the narrow point in the hourglass to illustrate that there must be a narrowing of the range of alternatives at that layer. There can be a wide range of applications supported over the [spanning layer] and of technologies utilized under it, but the [spanning layer] itself must represent the point at which there is a single definition of the provided capabilities. The power of the scheme is that programmers for all the applications write code that depends only on this single set of capabilities and thus are indifferent to the actual technology used below. If instead there were competing alternatives in the definition of the [spanning layer], the application programmers would have to cope with this variation, which in the limit is no more useful than having applications deal directly with the individual network technologies. In computer science terms, if there are N applications and M technologies, the [spanning layer] reduces the complexity of the resulting situation from N M to N + M. But for this to succeed, the [spanning layer] must be a point of agreement on a single set of capabilities.

I hope that the underlined section makes clear the connection between Einstein's description of an impressive theory and Clark's description of an impressive spanning layer. By the way, here is my version of a definition of a spanning layer:

A simple set of loosely coupled standard formats, protocols, and identifiers that generalizes diverse technologies into a virtual service for use by diverse applications

As you can see, at both the conceptual and technological level, generalization and unification are core concepts. This is a deep aspect of loose coupling in science as well as technology. To understand how spanning layers evolve is to understand evolution more deeply.

One other aspect of Einstein's quote is the context in which he made it (or at least one of the contexts—he seems to have used the quote several times). Here is a fuller quote:

A theory is more impressive the greater the simplicity of its premises, the more different are the kinds of things it relates, and the more extended its range of applicability. Therefore, the deep impression which classical thermodynamics made on me. It is the only physical theory of universal content, which I am convinced, that within the framework of applicability of its basic concepts will never be overthrown. M.J. Klein, Thermodynamics in Einstein's Universe, in Science, 157 (1967), p. 509

Here is a slightly different version of the quote:

A theory is the more impressive the greater the simplicity of its premises, the more different kinds of things it relates, and the more extended its area of applicability. Therefore the deep impression that classical thermodynamics made upon me. It is the only physical theory of universal content which I am convinced will never be overthrown, within the framework of applicability of its basic concepts. [differences emphasized]

Given my belief that entropy drives the evolution of complexity via spanning layers, such a quote gives me hope that I am on the right track.


6:18:04 AM      

Saturday, August 09, 2003

Rapid Diffusion is the Key to Success.
An expensive resource (exres) that is essential to only a few will be displaced by an inexpensive resource (inres) that is essential (or very useful) to many, even if the inres lacks some of the features of the exres. Examples: Internet, Web, Ethernet, IA-32, Linux. The inres will diffuse more broadly and rapidly, and the larger market will drive down costs of production. The unique features of the exres will then be ported to the inres, when the cost of the exres exceeds the cost of the port plus the cost of the inres. Visually this looks like a stovepipe in the first frame and in the second frame, a wide base with a shorter stovepipe (both which reach the same height as the first frame). How to represent the lower cost of the second frame? Since market size and cost are highly correlated, use the horizontal axis for both.
7:05:51 AM      

Friday, August 08, 2003

Think orgasmically.
Saw this post entitled Think orgasmically on Scripting News and it reminded me of an epiphany I had during a series of insights:

 

Epiphanies are functionally similar to orgasms in that both are emotional "rewards" for "connecting."

 

In the case of orgasm, the connection is sexual. While in the case of epiphany, the connection is conceptual. That is, my epiphanies occur when I connect concepts. Heidegger would note that both forms of connection share the same Latin root: copula—to link. <grin>

 

Of course, not every conceptual connection triggers an epiphany. Dave Winer says he has them when he has an idea that mixes well with the world. My epiphanies are triggered when I make a broad set of connections between concepts that had seemed unconnected and such connections lead to a whole series of insights.

 

Why do both ways of connecting (sexual and conceptual) trigger an emotional feeling of pleasure and satisfaction? I believe it is because both forms of connecting are essential to evolution, i.e., genetic and memetic.

 

BTW, I disagree with Dave's apparent suggestion that mostly women understand this relationship between sexual and conceptual connection. Google epiphany orgasm and you'll find many men observing the connection between them. When I did so, I found at least one man who has apparently thought about this extensively: Neil Greenberg, Professor of Ecology and Evolutionary Biology in the College of Arts and Sciences, University of Tennessee, Knoxville. His web site has interesting pages on epiphany as a state of consciousness triggered by connecting. Here's one other man who's made the connection.

 

My four greatest epiphanies (roughly spaced by decades) were triggered by the following (in order):

·         The realization of finality of death and my embrace of atheism

·         Derrida

·         Rorty

·         The realization of the fundamental importance of conceptual connection in the evolution of complexity

 

I hesitated to post this because it sounds so wacko, but given how many others have commented on the phenomenon, I felt I had to add my perspective on the issue.


1:56:01 PM      

Complexity is Relative.
I have been trying (like lots of others) to better understand complexity. And it struck me that we often speak of a given object as being both simple and complex. For example:

  • My TV is simple to operate, but really complex to set up.
  • This application is simple to install, but complex to upgrade.

To investigate this insight further, I did what I always do: Google. I googled "complexity is relative". One of the first results was this amazing paper entitled: Entropy as a fixed point. Apparently it was just published in February 2003. Given my previous post suggesting that complexity evolves to maximize entropy, I was amazed to see this connection to entropy in the title of the paper!

I was even more amazed when I read the abstract:

We study complexity and information and introduce the idea that while complexity is relative to a given class of processes, information is process independent: Information is complexity relative to the class of all conceivable processes. In essence, the idea is that information is an extension of the concept algorithmic complexity from a class of desirable and concrete processes, such as those represented by binary decision trees, to a class more general that can only in pragmatic terms be regarded as existing in the conception. It is then precisely the fact that information is defined relative to such a large class of processes that it becomes an effective tool for analyzing phenomena in a wide range of disciplines.

We test these ideas on the complexity of classical states. A domain is used to specify the class of processes, and both qualitative and quantitative notions of complexity for classical states emerge. The resulting theory is used to give new proofs of fundamental results from classical information theory, to give a new characterization of entropy in quantum mechanics, to establish a rigorous connection between entanglement transformation and computation, and to derive lower bounds on algorithmic complexity. All of this is a consequence of the setting which gives rise to the fixed point theorem: The least fixed point of the copying operator above complexity is information.

While I don't understand the formal discussion (yet), I am encouraged to see someone dealing formally with my intuition that complexity is relative to the process involved with (an) information (structure). This also reinforces my intuition that process and information are a duality.


7:27:36 AM      

Tuesday, August 05, 2003

Process is unchanging change? 'process' is change that is held to continue unchanged from a given point of view. This is a line tossed off by Salthe in the work cited in my previous post. It seems very profound to me. It seems to solve the endurantism/perdurantism dichotomy by suggesting how a process is like an object/structure in that it is unchanged over time from a given point of view. And an object is like a process in that it changes over time. Thus, process vs. information (i.e., structure) are simply two equally valid views of the same phenomenon, just as wave vs. particle are two equally valid views of energy. Somehow Quine's metaphor of Neurath's boat seems apropos here as well, though I haven't thought this through.


5:54:20 PM      

Evolution as Entropy. In searching for information on the "evolution of complexity," I came across a paper entitled The Natural Philosophy of Ecology: Developmental Systems Ecology (Infodynamics) by Stanley N. Salthe. It confirms my own recent insight into the "purpose" of evolution. Evolution of complex systems such as humanity or life itself is not an exception to the Second Law of Thermodynamics; it is a consequence of it. Complex systems evolved to maximize the production of entropy! As I put it in my rough notes back in October 2002:

One species is more successful than another in the biological reproduction sense to the degree it can successfully transform energy into copies of itself.

This is restated more generally (and more accurately in terms of entropy production rather than energy transformation) by Salthe:

Dissipative structures, and any systems that expand or grow, can be viewed as maximizing their entropy production, subject to constraints (which increase with age). The expansion of material systems can in general be viewed as a way to maximize entropy production, as the growth itself requires entropy production, and also delivers access to new energy gradients.

Accordingly, the dis-equilibrium that was the "big bang" is returning to equilibrium as quickly as possible through the evolution of matter from energy, astronomical bodies from matter, organic chemistry from planets, biological life from organic chemistry, and intelligence from biological life. Or as Salthe puts it:

Behind these considerations lies the Big Bang theory of the origin of the universe. According to Frautschi (1982), Landsberg (1984) and Layzer (1976), the expansion of the universe has been so fast that the system went out of global equilibrium rapidly, and has been trying to return to equilibrium ever since. As the system cooled, physical particles emerged, which then gave rise to matter, and this in turn gave rise to mass, which continually aggregated as collisions brought about by a random search for equilibrium evoked gravitation. In this scenario the system has been getting further and further away from an equilibrium distribution of energy and particles, thereby increasing the drive toward equilibration at the same time, thus making the Second Law of Thermodynamics an ever more powerful attractor in the material world as the universe expands.

Given the brute fact of masses of matter stuck in agglomerations nowhere near equilibrium, what can a system do to facilitate the approach to equilibrium? Following Schneider and Kay (1994), on the model of the Bénard instability, the massive frictional world finds a way to increase entropy production by way of convections facilitated by organized configurations abutting energy gradients, which they can use in an orderly manner (see also Swenson, 1997). This is the general explanation for abiotic dissipative structures like hurricanes and eddies; increasing the steepness of energy gradients spontaneously triggers the organization of material systems that will dissipate these same gradients as rapidly as possible. From this point of view, living systems are just a continuation of this project of reducing energy gradients. The evolution of animals is especially easily interpreted in this way: detrivores acquired movement to burrow into gradients; then they acquired mouths and claws to hurry the disintegration; then predators, as well as herbivores, evolve to hurry the production of detritus; then some of these became homeothermic so that gradients might continue to be dissipated even in the absence of activity; then some of these invested in large nervous systems, which consume large amounts of energy continuously. This scenario provides the basic 'meaning' of ecological systems, whose successional phenomenology shows a tendency to maximize energy flows (Lotka, 1922 / Odum and Pinkerton, 1955) by way of configurations and processes at many scalar levels. The punch line -- form results from, and further mediates, convective energy flows, which more effectively degrade energy gradients than would slow frictional conduction, like diffusion.

If I can paraphrase the punch line, and I don't think I have this exactly right yet: Information (i.e., forms, configurations, structures, organizations) production increases in order to increase entropy production. Or perhaps: Information flow increases in order to increase entropy flow.

I cannot begin to describe how important this insight is. I am amazed I have never come across this view before.


4:30:25 PM      

Monday, August 04, 2003

Architectural Description Language = Module (Inter)Connection Language? In my previous posting, I noted that "one can view the design as embedded not only in the circuit board, but also in the connectors embedded in the chips themselves." It is difficult to express this distinction between the concrete circuit board with specific chips embedded on it and an electronics kit containing a breadboard with a box of chips. Certainly the circuit board is a concrete, fully realized, architecture, whereas the "kit" is some form of abstract architecture. The kit cannot be used to design or build anything; it can only be used to realize a range of possible designs. The set of possibilities is determined to a large degree by the modular interfaces of the electronic components.

 

It turns out that others have noticed the connection between an architecture and connection or interconnection. Just try "module (mil OR mcl) adl language (connection OR interconnection)" as a Google search term. It appears that some of the literature considers a MIL (module interconnection language) to be simply an older term for ADL (Architectural Description Language). In any case, it seems clear that connections, interfaces, interconnections, interoperability, are all core concerns of architecture. I'll go further and claim that composition is the essence of architecture, and thus the design of interfaces among the composed components (be they objects or processes) is the essence of architecture.

 

Thus, the essence of the LEGO architecture is the stud-and-tube coupling system, which was patented in 1958. In fact, LEGO was originally (1955) described as the "LEGO System of Play." Not an individual toy, but a system for making toys. The original name for a LEGO brick was "Automatic Binding Brick." (Note the use of the term "binding" outside the realm of computer languages.) What do I mean by the essence of architecture? I mean something along the lines of the definition of architecture given in IEEE Std 1471 Recommended Practice for Architectural Description of Software-Intensive Systems:

 

Architecture: The fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution.

 

Of course, this begs the question, what is the fundamental organization of a system? This is where the term architecture gets overloaded. If I buy a LEGO kit for a Star Wars object, say the Millennium Falcon (MF), when it is finished, it has an architecture. Thus, what should we call the (1) kit, (2) the blueprint for building the MF, (3) the set of all possible LEGO Bricks, (4) the coupling system? LEGO calls (3) the "System of Play". I lean towards calling it the LEGO Modular Architectural Framework (MAF). I'd then call (4) the LEGO (Brick) Module Architecture (MA). That leaves (2), which I'd call the LEGO MF Architectural Blueprint.

 

Let's apply this to the electronics kit. The kit would still be the kit. The schematic for the kit would be the Architectural Blueprint. The result of using a blueprint would be an actual electronic application, say a radio, that has an Architecture. The bread board and all the chips I can use with it is the MAF. The chip and breadboard connectors would be the MA. Note how each of these architectures can evolve. I can evolve the radio without changing the MAF or the MA, say add a noise filter chip from the kit. I can evolve the MAF w/o changing the MA, say adding new types of components or changing the function of existing components. Or I can change the MA, which that new components may not work with old components.


4:05:16 PM      



© Copyright 2006 Nicholas Gall. Click here to send an email to the editor of this weblog.
Last update: 9/21/2006; 6:12:38 AM.