But then, we upgraded our home computer to the Apple Mac.  My experience on the Apple Mac was exactly opposite to Don’s on the Apple II.

The Mac was the start (well, after Lisa) of Apple’s focus on the creativity of the users of computers, rather than on the creativity of software developers.  The Mac had amazing useability and rich interactive applications, but there was no out-of-the-box development environment.  Even when years later I did get the MPW, there was a killer learning curve to create simple apps that conformed to Apple’s strict UI guidelines.  Hypercard (especially Hypertalk) was ahead of its time and did encourage bespoke coding creativity, but then Apple ditched it.

Apple’s success is due to their user and customer focus, but ever since the Apple Mac they’ve been mostly hostile to developers.

The Innoboard team found its first industry trial partner through the Future Logistics Living Lab, which is run by NICTA, SAP, and Fraunhofer IESE, and has around twenty (and growing) industry & research participants.  (Fraunhofer’s involvement is through the Fraunhofer Project Centre in Transport and Logistics at NICTA).  Industry trials for Innoboard are continuing, in a use-case for distributed logistics operations planning.  The Future Logistics Living Lab is also hosting a demo instance of Innoboard, and setting it up in the lab has helped contribute to ironing out some of the use & set-up issues in the early prototypes.

An audio recording of the ENS presentation exists.  I’ve created a PDF transcript of that recording.  However, I don’t have the slides that Robin presented – I’d be interested to have a copy if anyone could send me one.

Windows runs a weekly maintenance task that deletes all your shortcuts if it thinks you have more than four “broken” ones.  Bad!  The problem is exacerbated my Windows being mistaken about what’s a “broken” file.  It’s counting all my shortcuts coming from an “always online” shared network drive, even though none of them are really broken.  System maintenance task can clean stuff out of temp all it likes, maybe even delete old log files, but stay away from messing with my desktop!

MSFT offers two solutions: don’t have more than four shortcuts on your desktop (ummm, no), or turn off all system mainteance (ummm, no).  The best solution I’ve found is to hack the Windows 7 maintenance scripts to stop them mis-counting files.  Doing this felt like being a Linux user used to feel like.  I guess I should be grateful that I can hack these files – I was a little surprised to be able to.

First let’s consider some of the earlier definitions. SEI has a huge collection of definitions on its website, including “classic” definitions, bibliographic definitions (stops in 1996?), “modern” definitions, and definitions submitted from the community.  Perry and Wolf (1992) have perhaps the most classic definition, though it’s a little sketchy:

Architecture = {elements, form, rationale}

where elements are Processing, Data, or Connecting elements. Taylor et al. (2010) note that when people talk about software architecture in terms of Components and Connectors, that’s an over-simplification of Perry and Wolf’s definition – over-simplified because it doesn’t always work. For example in REST, Data elements are pre-eminent.

The ANSI/IEEE 1471-2000 definition expands on Perry and Wolf’s definition, and also slips environment into the scope of form (relationships).

Architecture is the fundamental organisation of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

Elements (components) and their form (relationships) are clearly key to understanding what software architecture is, but many people think that’s all it is! Instead, software architecture researchers have understood for a long time that rationale (design/evolution principles) is also a key part of what software architecture is.

But contrari-wise, software architecture is not just rationale. So although Taylor et al. (2010) is a great architecture textbook, their definition of software architecture isn’t so great:

A software system’s architecture is the set of principal design decisions made about the system.

I would instead say that design decisions are the means by which elements, form, and rationale are created. The design decisions are not the architecture per se.

Software architecture is commonly misunderstood to be an exclusively structural model. Perhaps that’s because UML class diagrams and deployment diagrams are often presented as iconic for software architecture. The definition from the Bass et al. (2008) classic textbook also encourages this view:

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

But there has been a shift in the software architecture research community to think about architecture more abstractly: in terms of rules or constraints or styles. So instead of “structures”, I prefer using the word “abstractions”, to more easily accommodate a rule-based architectural perspective. The abstractions here are not just of software, but also non-software elements in the system, including the environment. Fielding (2000) also talks about abstractions this way (though for some reason he limits software architecture to run-time, which I don’t agree with):

A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture.

Apparently Clements et al. (2010) has another new definition:

The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

Here we have (ignoring “structures” for the moment) Perry and Wolf’s elements and form (relations) again, but now also with properties for each. Perry and Wolf’s rationale has not disappeared, but here appears as a qualifier (“needed to reason about”). I like this. I think the whole point of architecture is abstraction and analysis of a system for particular purposes. Here the “reasoning” objective implicitly encompasses those purposes and analyses.

I’d slightly prefer to say “communicate and reason” instead of “reason”, though perhaps you could say that understanding a communication is-or-requires reasoning. I’d also prefer to talk about “a” (not “the”) software architecture of a system (and similarly “a set” not “the set”), to more readily accommodate multiple views/perspectives of a single system.

So, in summary, my definition would be something like:

A software architecture of a system is a set of abstractions needed to communicate and reason about software in the system. A software architecture models elements of the system and its environment, relations among those elements, and properties of those elements and relations.

Today it’s another Coopers’ kit – the Traditional Draught (although I will bottle it, not put it in a cask!) supplemented by 1.5kg of the Coopers Light Malt.  O.G. is 1.040.

In business, invention is the conversion of cash into ideas, but innovation is the conversion of ideas into cash.

Nice.  I see this is also on wikipedia.  I wonder what’s the original source for this quote?