Previously I have discussed the use of the word ‘architecting’ and whether it is a valid word when describing the thing that architects do.
One of the people who commented on that blog entry informed me that the IEEE have updated the architecture standard, IEEE-1471 which describes the architecture of a software-intensive system to ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description. They have also updated slightly the definition of the word architecting to:
The process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle (i.e., “designing”).
Interesting that they have added that last bit in brackets “that is designing”. I always fall back on the words used by Grady Booch to resolve that other ongoing discussion about whether the word architecture is valid at all in describing what we do “all architecture is design but not all design is architecture”.
A discussion has arisen on one of the IBM forums about whether the verb that describes what architects do (as in “to architect” or “architecting”) is valid English or not. The recommendation in the IBM word usage database has apparently always been that when you need a verb to describe what an architect does use “design,” “plan,” or “structure”. Needless to say this has generated quite a bit of comment (145 at the last count) including:
Police are policing, judges are judging, dancers are dancing, why then aren’t architects architecting?
Architects are not “architecting” because they design.
I feel a need to defend the term ‘architecting’. Engineers do engineering, architects do architecting. We have the role of software or system architecture and the term describes what they do. There is a subtle but useful distinction between a software designer and a software architect that was identified about 30 years ago by the then IBMer Fred Brooks in his foundational text, The Mythical Man Month.
From a grammatical point of view use of “architecting” as a verb or gerund is as poor as using leverage as a verb… and as far as meaning is concerned, as poor as any platitude used when knowledge of precise content and detail is lacking.
As someone who has co-authored a book called The Process of Software Architecting I should probably declare more than a passing interest in this and feel that the verb ‘architecting’ or ‘to architect’ is perfectly valid. Whether it is strictly correct English or not I will leave to others far better qualified to pass judgment on. My defence of using architect as a verb is that there is a, sometimes subtle, difference between architecture and design (Grady Booch says “all architecture is design but not all design is architecture”) and although architects do perform elements of design, that is not all they do. I, for one, would not wish to see the two confused.
The definition of architecting we use in the book The Process of Software Architecting comes from the IEEE standard 1471-2000 which defines architecting as:
The activities of defining, documenting, maintaining, improving, and certifying proper implementation of an architecture.
As a related aside on whether adding ‘ing’ to a noun to turn int into a verb is correct English or not it is interesting to see that the ‘verbing’ of nouns is picking up pace at the London Olympics where we now seem to have ‘medaling’ and ‘platforming’ entering the English language.
Grady Booch, IBM Fellow and Chief Scientist for Software Engineering in IBM Research has kicked off an initiative to produce a documentary on the history of computing called Computing: The Human Experience. This is a crowd sourcing initiative for which Grady is trying to raise $25,000 by January 2nd to get the project underway. It’s an all or nothing model, the project must be fully funded before time expires or no money changes hands.
I guess you may ask why you should contribute funds to an initiative like this in these austere times when there are far better causes that could take care of your $$$$. Here are three reasons:
If you are reading this blog you are almost certainly involved at some level in computing. You have helped, or still are helping, change the world in fundamental and unprecedented ways, ways that affect pretty much everyone who walks the face of the planet right now. Isn’t it time that story was told?
Computing more than any other industry has its roots at a very personal level. How many great computing ideas have started in kid’s bedrooms, dormitories or their parent’s garages? You can now help by making your own personal contribution.
You can donate as little as one dollar, a lot less than your first latte of the day or final glass of alcoholic beverage in the evening. Forego that and spend it on this instead, you could even get a hand written letter of thanks from Grady.
If you do donate, or even if you don’t, make sure you tweet it, blog it, Tumblr it or Facebook it so all your friends know about this.
I stumbled across this article by Grady Booch today whilst doing some research on complex systems. It’s quite old (well 3 years is an age in this profession) but what it has to say about developing complex systems is, I believe, timeless. In particular I loved Grady’s point about the importance of “developing social structures that encourage innovation whilst still preserving predictability”. Interestingly another post by Seth Godin says:
The challenge of our time may be to build organizations and platforms that engage and coordinate the elites, wherever they are. After all, this is where change and productivity come from.
Seth’s definition of an “elite” is anyone who is “actively engaged in new ideas, actively seeking out change, actively engaging.
The internet is a great platform for bringing people together. The challenge is in how to scale the creativity, that can be easily bought to focus in a small, co-located team, across the internet. The boundaries of the enterprises that used to do this are beginning to crumble. There is often more creativity outside the enterprise than is in it and new architectures (new platforms) need to learn how to make use of this. This is more than just what has been happening with the open source movement, where a group of people come together to build new products, its about how to use creativity at scale to build new platforms.
Spookily (well it is Halloween) and with a great bit of webendipity just as I was about to push the publish button on this article up popped in my twitter feed this article by my colleague Jeremy Caine about platforms (e.g. Facebook, iTunes, Twitter) and the creatives that build them.
Software, although an “invisible thread” has certainly had a significant impact on our world and now pervades pretty much all of our lives. Some software, and in particular some software architectures, have had a significance beyond just the everyday and have truly changed the world.
But what constitutes a world changing architecture? For me it is one that meets all of the following:
It must have had an impact beyond the field of computer science or a single business area and must have woven its way into peoples lives.
It may not have introduced any new technology but may instead have used some existing components in new and innovative ways.
The architecture itself may be relatively simple, but the way it has been deployed may be what makes it “world changing”.
It has extended the lexicon of our language either literally (as in “I tried googling that word” or indirectly in what we do (e.g. the way we now use App stores to get our software).
The architecture has emergent properties and has been extended in ways the architect(s) did not originally envisage.
Based on these criteria here are five architectures that have really changed our lives and our world.
World Wide Web
When Tim Berners-Lee published his innocuous sounding paper Information Management: A Proposal in 1989 I doubt he could have had any idea what an impact his “proposal” was going to have. This was the paper that introduced us to what we now call the world wide web and has quite literally changed the world forever.
There has been much talk in cyberspace and in the media in general on the effect and impact Steve Jobs has had on the world. When Apple introduced the iPod in October 2001 although it had the usual Apple cool design makeover it was, when all was said and done, just another MP3 player. What really made the iPod take off and changed everything was iTunes. It not only turned the music industry upside down and inside out but gave us the game-changing concept of the ‘App Store’ as a way of consuming digital media. The impact of this is still ongoing and is driving the whole idea of cloud computing and the way we will consume software.
When Google was founded in 1999 it was just another company building a search engine. As Douglas Edwards says in his book I’m Feeling Lucky “everybody and their brother had a search engine in those days”. When Sergey Brin was asked how he was going to make money (out of search) he said “Well…, we’ll figure something out”. Clearly 12 years later they have figured out that something and become one of the fastest growing companies ever. What Google did was not only create a better, faster, more complete search engine than anyone else but also figured out how to pay for it, and all the other Google applications, through advertising. They have created a new market and value network (in other words a disruptive technology) that has changed the way we seek out and use information.
Before WIkipedia there was a job called an Encyclopedia Salesman who walked from door to door selling knowledge packed between bound leather covers. Now, such people have been banished to the great redundancy home in the sky along with typesetters and comptometer operators.
If you do a Wikipedia on Wikipedia you get the following definition:
Wikipedia is a multilingual, web-based, free-content encyclopedia project based on an openly editable model. The name “Wikipedia” is a portmanteau of the words wiki (a technology for creating collaborative websites, from the Hawaiian word wiki, meaning “quick”) and encyclopedia. Wikipedia’s articles provide links to guide the user to related pages with additional information.
From an architectural point of view Wikipedia is “just another wiki” however what it has bought to the world is community participation on a massive scale and an architecture to support that collaboration (400 million unique visitors monthly more than 82,000 active contributors working on more than 19 million articles in over 270 languages). Wikipedia clearly meets all of the above crtieria (and more).
To many people Facebook is social networking. Not only has it seen off all competitors it makes it almost impossible for new ones to join. Whilst the jury is still out on Google+ it will be difficult to see how it can ever reach the 800 million people Facebook has. Facebook is also the largest photo-storing site on the web and has developed its own photo storage system to store and serve its photographs. See this article on Facebook architecture as well as this presentation (slightly old now but interesting nonetheless).
I’d like to thank both Grady Booch and Peter Eeles for providing input to this post. Grady has been doing great work on software archeology and knows a thing or two about software architecture. Peter is my colleague at IBM as well as co-author on The Process of Software Architecting.
The word ‘design’ is both a noun (a plan or drawing produced to show the look and function or workings of a building, garment, or other object before it is built or made) and a verb (decide upon the look and functioning of (a building, garment, or other object), typically by making a detailed drawing of it). Given an architecture is something you decide the look and function of, typically by making a drawing of it, saying you are designing an architecture is not as daft as it sounds. Grady Booch once remarked that “all architecture is design but not all design is architecture“. An architecture is what we create by applying good software engineering/design principles (separation of concerns, data hiding, contract-driven design, understanding stakeholder needs etc). An architecture can therefore be something that comes out of the process of design (by applying design thinking). However the architecture itself focuses on the essence of the [software] system and does not get bogged down in the detail.
Solution Architects need to create models of the systems they are building for a number of reasons:
Models help to visualise the component parts, their relationships and how they will interact.
Models help stakeholders understand how the system will work.
Models, defined at the right level of detail, enable the implementers of the system to build the component parts in relative isolation provided the interfaces between the parts are well defined.
These models need to show different amounts of detail depending on who is looking at them and what sort of information you expect to get from them. Grady Booch says that “a good model excludes those elements that are not relevant to the given level of abstraction”. Every system can be described using different views and different models. Each model should be “a semantically closed abstraction of the system” (that is complete at what ever level it is drawn). Ideally models will be both structural, emphasizing the organization of the system, as well as behavioral, emphasizing the dynamics aspects of the system.
To support different views and allow models to be created at different levels of abstraction I use a number of different diagrams, created using the Unified Modeling Language (UML) in an appropriate modeling tool (e.g. Rational Software Architect or Sparx Enterprise Architect). Using a process of “architecture drill-down” I can get both high level views as well as detailed views that are relevant to the level of abstraction I want to see. Here are the views and UML diagrams I create.
Enterprise View (created with a UML Package diagram). This sets the context of the whole enterprise and shows actors (users and other external systems) who interact with the enterprise.
System View (Package diagram). This shows the context of an individual system within the enterprise and shows internal workers and other internal systems.
Subsystem View (Package diagram). This shows the breakdown of one of the internal systems into subsystems and the dependencies between them.
Component View (Component diagrams and Sequence diagrams). This shows the relationships between components within the subsystems, both static dependency type relationships (through the UML Component diagram) as well as interactions between components (through the UML Sequence diagram).
Component Composition View (Composite Structure diagram). This shows the internal structure of a component and the interfaces it provides.
Note hat a good tool will link all these together and ideally allow them to be published as HTML allowing people without the tool to use them and also navigate through the different levels. Illustrative examples of the first three of the diagrams mentioned above are shown below. These give increasing levels of detail for a hypothetical hotel system. Click on the picture to get a bigger view.
In the actual tool, Sparx Enterprise Architect in this case, each of these diagrams is linked so when I click on the package of the first it opens up the second and son on. When published as HTML this “drill-down” gets maintained as hyperlinks allowing for easy navigation and review of the architecture.