Architecture: Layering Components

Ratio Group Ltd. has some interesting papers in its technical library. I posted a note on this one over a year ago and was rereading it again today:

Collins-Cope, Mark and Matthews, Hubert. A Reference Architecture for Component Based Development. Ratio Group Ltd.

The paper propose a reference architecture for object oriented/component based systems consisting of five layers... More specific (and therefore less reusable) components are placed in the higher layers, and the more general, reusable components are in the lower layers. Since general non-application components are less likely to change than application specific ones, this leads to a stable system as all dependencies are downward in the direction of stability, and so changes tend not to propagate across the system as a whole.

In general, systems implementation I have reviewed do not do a great job of eliminating dependencies across components so this paper is worth reading by all developers. There are a lot of good rules for placing components in a layered architecture in this paper.

TRIZ - Russian patterns for technology problem solving

A Higher Plane of Problem-Solving
Can the theories of a onetime enemy of Stalin solve your company's most vexing technological challenges? A cult of business consultants swears that they can.
By Andy Raskin, Business 2.0, June 2003

"In a 1948 letter addressed "Personally to Comrade Stalin," Genrich Altshuller, a 22-year-old lieutenant in the Caspian Sea Military Navy, argued that the Soviet Union's approach to technology was chaotic and ignorant. A prodigious inventor (by the 10th grade, he had patented an underwater diving apparatus and built a rocket-propelled boat), Altshuller wrote that he had devised a systematic approach by which any technical problem could be solved. A little over a year later, Soviet officials invited him to discuss his ideas in Tbilisi, Georgia; upon arrival, he was arrested and sentenced to 25 years in the gulag."

Technologists should check out TRIZ, a Russian acronym for "theory of inventive problem-solving." The picture above represents a problem in thermodynamics where a solution is looked for in mechanical effects. Just as the drunk looks for lost keys under the street lamp, the expert looks for the solution in his or her area of expertise, when the real breakthrough technology might be found elsewhere.

Substitute radiation therapy for thermo-dynamics, pharmaceuticals for chemical effects, and surgery for mechanical effects and you have a picture of the field of medicine. Major future breakthroughs will occur in electromagnetic devices and psychologic inertia will prevent current players from capturing the benefits of new technologies.

Agile Manifesto: Who does it have in common with Open Source and Hacking?

Eric Raymond's analysis of the convergence of hacking, open source, and the agile movement is of interest. Eric is well known for writing two seminal open source articles that have strongly influenced the movement:

"[Hacker] is a very complex term, but more than anything else, it describes an attitude—an intentional stance that relates hackers to programming and other disciplines in a particular way. I have described the hacker stance and its cultural correlates in detail in How To Become A Hacker...

"Open source is a programming style with strong roots in the Unix tradition and the hacker culture. I wrote the modern manifesto for it in 1997, The Cathedral and the Bazaar, building on earlier thinking by Richard Stallman and others."

Hacking and Refactoring: "Discovering the Obvious"
by Eric S. Raymond
June 14, 2003

"The open-source movement and agile programming may be converging. While reading Martin Fowler's excellent book 'Refactoring', I realized development by refactoring is a sharp description of the normal style of open-source hackers. In this essay ... I explore the connection further.

"In 2001, there was a history-making conference of software-engineering thinkers in Snowbird, Colorado. The product of that meeting was a remarkable document called the Agile Manifesto, a call to overturn many of the assumptions of traditional software development. I was invited to be at Snowbird, but couldn't make it." (Sad story, I almost didn't make it but thought better of it at the last moment!)

Raymond sees "an enormous mutual potential, a gap across which an arc of enlightenment may be beginning to blaze."

"First, people who are excited by agile-programming ideas can look to open source and the Unix tradition and the hackers for the lessons of experience. We've been doing a lot of the stuff the agile movement is talking about for a long time. Doing it in a clumsy, unconscious, learned-by-osmosis way, but doing it nevertheless. I believe that we have learned things that you agile guys need to know to give your methodologies groundedness. Things like ... how to manage communication and hierarchy issues in distributed teams.

"Second, open-source hackers can learn from agile programmers how to wake up. The terminology and conceptual framework of agile programming sharpens and articulates our instincts. Learning to speak the language of open source, peer review, many eyeballs, and rapid iterations gave us a tremendous unifying boost in the late 1990s; I think becoming similarly conscious about agile-movement ideas like refactoring, unit testing, and story-centered design could be just as important for us in the new century."