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.
Apple’s iTunes
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.
Google
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.
Wikipedia
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).
Facebook
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.
Enterprise View
System View
Subsystem 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.
As a follow-up to my six non-IT books here are five videos I have found some inspiration from recently (plus one that whilst cannot be described as inspirational is at least amusing in a vaguely nerdy programmer kind of way):
Steve Jobs (A CEO): How to Live Before You Die Steve Jobs steps out from his usual Apple presentation mode and delivers this keynote to students at Stanford. He highlights three things which have had a major impact on his life and how important it is to learn from such life experiences.
Winston Royce (A Methodologist): The Rise and Fall of Waterfall Not actually by Winston Royce but a humorous look at how we ended up with waterfall. An example of how to get a point across by telling a story (and using wonderfully simple graphics).
Grady Booch (A Software Architect): The Promise, The Limits, The Beauty of Software Grady is an inspirational speaker on all things software related. We were lucky enough to get him to write the forword to our book (which I’m sure has done its sales the world of good).
Sir Ken Robinson (An Innovator and Educationalist): Do Schools Kill Creativity SKR (as he calls himself on his website) has some strong views on how our present education system is letting down youngsters.For a great rendition of another of Sir Ken’s talks see here.
David Eustace (A Photographer): In Search of Eustace Nothing to do with IT but related to one of my other passions. This simple and beautifully filmed video set to music will resonate with anyone on life’s journey.
And finally…
Lady Gaga (A Singer) Lookalike: Sings About Java Programming An example of how creativity (the video production) can be used to improve even the worst ideas (the song). What else can I say!
Inspired by this book I discovered in the Tate Modern book shop this week I don’t (yet) have 101 things I can claim I should have learned in IT Architecture School but this would certainly be my 10 things:
The best architectures are full of patterns. This from Grady Booch. Whilst there is an increasing need to be innovative in the architectures we create we also need to learn from what has gone before. Basing architectures on well-tried and tested patterns is one way of doing this.
Projects that develop IT systems rarely fail for technical reasons. In this report the reasons for IT project failures are cited and practically all of them are because of human (communication) failures rather than real technical challenges. Learning point: effective IT architects need to have soft (people skills) as well as hard (technical skills). See my thoughts on this here.
The best architecture documentation contains multiple viewpoints. There is no single viewpoint that adequately describes an architecture. Canny architects know this and use viewpoint frameworks to organise and categorise these various viewpoints. Here’s a paper myself and some IBM colleagues wrote a while ago describing one such viewpoint framework. You can also find out much more about this in the book I wrote with Peter Eeles last year.
All architecture is design but not all design is architecture. Also from Grady. This is a tricky one and alludes to the thorny issue of “what is architecture” and “what is design”. The point is that the best practice of design (separation of concerns, design by contract, identification of clear component responsibilities etc) is also the practice of good architecture how architectures focus is on the significant elements that drive the overall shape of the system under development. For more on this see here.
A project without a system context diagram is doomed to fail. Quite simply the system context bounds the system (or systems) under development and says what is in scope and what is out. If you don’t do this early you will spend endless hours later on arguing about this. Draw a system context early, get it agreed and print it out at least A2 size and pin it in highly visible places. See here for more discussion on this.
Complex systems may be complicated but complicated systems are not necessarily complex. For more discussion on this topic see my blog entry here.
Use architectural blueprints for building systems but use architectural drawings for communicating about systems. A blueprint is a formal specification of what is to be. This is best created using a formal modeling language such as UML or Archimate. As well as this we also need to be able to communicate our architectures to none or at least semi-literate IT people (often the people who hold the purse). Such communications are better done using drawings, not created using formal modeling tools but done with drawing tools. It’s worth knowing the difference and when to use each.
Make the process fit the project, not the other way around. I’m all for having a ‘proper’ software delivery life-cycle (SDLC) but the first thing I do when deploying one on a project is customise it to my own purposes. In software development as in gentleman’s suits there is no “one size fits all”. Just like you might think you can pick up a suit at Marks and Spencers that perfectly fits you can’t. You also cannot take an off-the-shelf SDLC that perfectly fits your project. Make sure you customise it so it does fit.
Success causes more problems than failure.This comes from Clay Shirky’s new book Cognitive Surplus. See this link at TED for Clay’s presentation on this topic. You should also check this out to see why organisations learn more from failure than success. The point here is that you can analyse a problem to death and not move forward until you think you have covered every base but you will always find some problem or another you didn’t expect. Although you might (initially) have to address more problems by not doing too much up front analysis in the long run you are probably going to be better off. Shipping early and benefitting from real user experience will inevitably mean you have more problems but you will learn more from these than trying to build the ‘perfect’ solution but running the risk of never sipping anything.
Knowing how to present an architecture is as important as knowing how to create one. Although this is last, it’s probably the most important lesson you will learn. Producing good presentations that describe an architecture, that are targeted appropriately at stakeholders, is probably as important as the architecture itself. For more on this see here.
Yes it’s that old knotty problem again! Over at gapingvoid.com Hugh MacLeod is fond of using Venn diagrams to illustrate overlapping concerns so here’s one that I recently used for addressing the eternal architecture versus design debate that was the source of much discussion at a recent Architecture Thinking class I was giving.
As I remember it the discussion went something like this:
Student: So what’s the difference between architecture and design? It seems from what you’re saying its just a matter of scale?
Me: Whilst its true to say that architecture addresses the major components of the system, rather than the detail, it’s more than that. The architecture is the bridge between the “what” (that is the requirements) and the “how” (that is the design).
Student: Yeah but isn’t that we usually call “high-level design”.
Me: Not really. Grady Booch says: “All architecture is design but not all design is architecture”. (I cheated and looked up this quote afterwards and found that Booch goes on to say “architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”). In my experience high-level design is just the the view that allows the complete system to be represented on one page.
Student: I still don’t see what the difference really is.
Me: Okay, here’s the real difference for me (at this point I draw the above Venn on a flip-chart). As well as defining the structure of the system, architecture must also embrace the “what” and the “how” of that structure. The “what” in this context is the requirements (functional and non-functional) and so architecture involves reasoning about and resolving these sometimes conflicting requirements. It’s about addressing those architecturally significant requirements (the “what”) that will drive (and constrain) the “how” (the design).
Now, if I was drawing this again (and maybe I’ll do this next time) I would actually draw a third overlapping circle which I’d label the “why”. This is where we’d capture the rationale for why we make the (architectural) decisions we do.
Thanks Hugh, this is a neat way of explaining the way things are!
Software Architecture Zen 