http://www.handbookofsoftwarearchitecture.com The Handbook catalogs the software architecture of a large collection of software-intensive systems. en-us Copyright (C) 2000-2008 by Grady Booch http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog#593 Boyle's Law describes the inverse relationship between pressure and volume in a closed system. Density - being mass per unit of volume - has a role to play here as well, for given a constant temperature and a given mass, if you increase the volume of the closed space you reduce the pressure and therefore the density.

I hold regular office hours at Thornebridge in Second Life and have done so for about a year. You'll find me there conducting business, lecturing and occasionally meeting customers. I've noticed that the number of residents in world at any one time has been growing steadily - no matter what time of day, it's usually in the high 60,000s - but at the same time the amount of land has been increasing. Ergo, you may find it less dense and therefore more sparse, as noted here (and yet, as the article goes on to point out, the Second Life economy is growing).

Quote of the day:

Could it be that in the future they will say, 'A real relationship! Urgh, how horrible.' The messiness and squalor of the real world, and the real-time element, might be offset by the more sanitised, two-dimensional reality of Second Life.
Baroness Susan Greenfield

]]> 05 Jan 2010 12:08:53 MST http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog#592 Paul Goldberger, architecture critic for The New Yorker has just published his latest book, Why Architecture Matters. While Paul's work focuses on civil architecture, his remarks do resonate with the world of software architecture. He notes that "Architecture begins to matter when it brings delight and sadness and perplexity and awe along with a roof over our heads." David Minthorn offers a review of Paul's book, and while one might accuse Paul of being an architecture astronaut, he does care about the fragile balance between pragmatics and esthetics, wherein he talks about "the hospital that is a 'cold, forbidding environment' for patients and staff; the school designed 'more for the ease of the custodial staff' than the students and teachers; airports with 'endless concourses' designed for moving airplanes rather than people; and strip malls planned 'solely to make it easier to drive cars in and out.'"

Quote of the day:

Utilitas, firmitas, venustas.
Marcus Vitruvius Pollio

]]> 04 Jan 2010 11:16:01 MST http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog#591
Quote of the day:

We must be willing to get rid of the life we've planned, so as to have the life that is waiting for us. The old skin has to be shed before the new one can come.
Joseph Campbell

]]> 03 Jan 2010 16:22:07 MST http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog#590 Slashdot, here's a fascinating report on how much information Americans consume.

Quote of the day:

Data is not information. Information is not knowledge. Knowledge is not understanding. Understanding is not wisdom.
Anonymous

]]> 09 Dec 2009 10:21:05 MST http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog#589

We have designed a tool to help software architects evaluate their architecture designs for specific usability issues. We are inviting software architects to look at our design and take a brief online survey about their opinions.

Completing the survey will entitle you to be entered in a drawing for a $100US Amazon gift card. You must complete the survey to enter the drawing. When we have received 40 entries, a winner will be selected at random and notified via email.

In user tests of a prototype of our tool, software architects at a major European development organization estimated they received a 17:1 ROI on time they spent using the tool to evaluate a design for a product line architecture. An open-source version of the tool should become available for distribution in the near future.

Participation in the survey should take less than 30 minutes. Your responses will be kept confidential. To participate, please go here.

If you have any questions or would like further information, please contact egolden@cmu.edu. Thanks!

Quote of the day:

When television came roaring in after the war (World War II) they did a little school survey asking children which they preferred and why - television or radio. And there was this 7-year-old boy who said he preferred radio "because the pictures were better."
Anonymous

]]> 10 Nov 2009 13:21:31 MST http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog#588 failures in software projects wherein I'm quoted.

Quote of the day:

In my dream, the angel shrugged & said, If we fail this time, it will be a failure of imagination & then she placed the world gently in the palm of my hand.
Brian Andreas

]]> 02 Nov 2009 14:53:44 MST http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog#587 SOA manifesto.

Quote of the day:

There are no manifestos like cannon and musketry.
Arthur Wellesley

]]> 02 Nov 2009 13:09:07 MST http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog#586 here, and we covered a lot of ground, from design patterns to object-oriented gorp to the merits of Kona coffee.

Quote of the day:

No one can understand the truth until he drinks of coffee's frothy goodness.
Sheik Adb-al-Kadir

]]> 02 Nov 2009 12:35:21 MST http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog#585 IASA, in which they brought together a number of enterprise architecture folks (such as John Zachman) and technical architecture folks (such as Len Bass). The collision of those worlds is something that's been popping up in a number of conversations I've had recently, and it so moves me to make my position clear.

EA (enterprise architecture) is not TA (technical architecture).

Although the two share the noun "architecture" they are different things. EA attends to the architecture of a business that uses technology; TA attends to the architecture of the software-intensive systems that support the business. Each domain - that of the business and that of the system - have fundamentally different stakeholders with different perspectives and different viewpoints. The fact that the both share some aspects of terminology and concerns and even notation is good, but can be confusing in the dialog between those two worlds..

Indeed, speaking of two worlds, in the dialog between science and religion, there's also this notion of two worlds: science has some things of which it may speak with authority and faith has some things of which it may speak with authority, but when science tries to answer questions of faith (why is the world the way it is) or vice versa (is there or is there not a randomness in the laws of the universe) then conflict arises. Not to diminish the complex texture of the dance between science and religion - if you want to go there, then the Templeton Foundation is one place to start, although Richard Dawkings has some things to say about that too - but IMHO EA and TA are similarly of two worlds. Most contemporary economically-meaningful enterprises use software-intensive systems to carry out their mission, and so there is and should be this jiggling between the architecture of the business (as it uses technology) and the architecture of the software-intensive system (as it serves and leads the business).

If you accept my premise that this collision of worlds exists between EA and TA, then I want to be clear that both worlds must co-exist and both must interoperate. SOA actually has some interesting traction here, because on the one hand, architecting a business around the services it provides and architecting a software-intensive system that makes manifest those services are shared goals of the enterprise and the technology.

And yet - and here's where I'm likely to inflame some folks - IMHO it's a mistake to try and extend EA frameworks and notations and processes to attend to the architecture of the software-intensive systems it uses, just as it is a mistake to try and extend SA frameworks and notations and processes to attend to the architecture of the business. There might be some overlap in view and basic modeling elements and processes at a high enough level of abstraction, but when you get to the details, it becomes too much, and you lose the perspective of what each is trying to do. EA is not a desert topping and a floor wax and neither is TA.

I'm currently working with Tilak Mitra, a colleague at IBM, on surveying the 20 or so EA frameworks that appear to have some traction in the world. There are far fewer TA frameworks - most are some variation of Kruchten's 4+1 model view - and the fact that there are so many EA frameworks out there speaks to the vibrancy of that market, but my experience tells me that there are too many chasing the same problem, and eventually the market will make its choice; I view this as a healthy sign, but a sign that EA is still in its adolescence. In contrast, the fact that there are fewer TA frameworks is a sign to me of the greater maturity of that domain, not to say that it's any less vibrant (look for the next edition of Documenting Software Architectures, but the market appears to have made its choices.

Quote of the day:

There are two worlds: the world we can measure with line and rule, and the world that we feel with our hearts and imagination.
Leigh Hunt

]]> 29 Oct 2009 13:52:04 MST http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog#584 International Association of Software Architects who suggested the following t-shirt slogan

Architects do IT with models.

Not to be outdone, my colleagues in the UK, Ian Charters and crew, also suggested

Architects do IT with heroically.

Architects do IT with automagically.

Architects do IT with with pictures.

plus the rather lonely sounding

Architects do IT alone.

My contribution to the mix is

Carpe architecture.

Quote of the day:

I failed the Turing test.
Teenormous

]]> 24 Oct 2009 22:20:14 MST