More on NoSQL Storage

In the last few days I've been collecting some interesting links about NoSQL databases in some blogs:

• This one and this other, about the CAP's theorem. The second one also includes a reference to the origins of punk rock :-)
• This entry discusses the NoSQL storage ecosystem and some features, and...
• ... this other goes deep into the main features of NoSQL storage.
• Finally this other document also introduces the main features and systems in the NoSQL ecosystem.

A New Book on Design

Some posts ago, I wrote about how design simplicity was applied to a concrete part of a software project and I mentioned a book I was reading called Subject to Change. Today, exploring the Pearson's higher education web page, I've found that Fred Brooks is preparing a forthcoming book about design. I'm glad to know that, as this blog pretends to do, other people find interest in how software can take profit from other disciplines such as aesthetics and design.

Software Architecture

I'm happy of having found this webpage on software architectures. I share with his author (Simon Brown) some of the same interest about software architectures. I seize the opportunity to recover some old thoughts.

I've been searching in my HD for a document I wrote some time ago about software architectures. In that document, I collected several definitions about what a software architecture is. Here they are some formal definitions from well-known members of the software engineering community:

• D. E. Perry and A. L. Wolf in "Foundations for the Study of Software Architecture", ACM SIGSOFT Software Engineering Notes, 17:4, 1992 "... software architecture is a set of architectural (or, if you will, design) elements that have a particular form. We distinguish three different classes of architectural element: processing elements; data elements; and connecting elements.”
• D. Garlan and D. E. Perry in editorial of IEEE Transactions on Software Engineering, April 1995: "the structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time.”
  Garlan and Perry, guest editorial to the IEEE Transactions on Software Engineering, April 1995
• D. Garlan and M. Shaw in Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, 1996: "the description of the elements that comprise as system, the interactions and patterns of these elements, ther principles that guide their composition, and the constraints on these elements".
• L. Bass, P. Clemens, R. Kazman in Software Architecture in Practice, Addison-Wesley, 1997: "is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them".
•  IEEE Std 1471 (Maier,  Emery,  Hilliar): "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".

Other prolific authors such as Martin Fowler do not want to enter into the definition of software architectures.

Of course, I finished my document giving my own definition of a software architecture (why not? :-):

"a software architecture is some kind of document which describes a high level view of the evolution of the structure and behaviour of a particular software system or application in terms of software components and their relationships".

By reviewing all these definitions I've realized that no one includes a reference to the fulfilment of the requirements that must drive the design process. So, I would like to change my definition :-) into this new one:

"the software architecture of a system or application comprises the necessary means (e.g. documents, figures, diagrams, graphs etc.) that, taking into account the collected requirements (functional and not funtional), best describe its design process and the evolution of its structure and behaviour (in terms of components and their relationships) with regard to the fulfilment of the expected requirements".
 
To conclude this post just to mention some sources of information on software architecture. First three (more or less recent) books in which I've paid attention:

• Software Systems Architecture, 2005
• Software Architecture and Design Illuminated, 2009
• Software Architecting, 2009

Of course it is also worth to mention here the work of Grady Booch on software architectures. His web page is an infinite source of reliable information.

Finally, I want to leave an open question here: Are system architecture, enterprise architecture and technical architecture related to the concept "software architecture"? That is, are/require they minor refinements of the concept, or they deserve particular attention and radically different definitions?

NOTE: I've just found an entry in Grady Booch's blog about something related to this open question (October 29th, 2009) discussing about enterprise and technical arthitectures: "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". So, it seems that Booch understands technical architecture as synonym of software architecture, separating the concept from the enterprise architecture concept. See also my blog entry on Application Architecture and Enterprise Architecture.