Software Architecture Zen

Its Pretty Interactive, Yeah

2012-02-17T20:09:00.000Z

I have said a number of times in this space that I believe Tim Berners-Lee to be one of the greatest software architects of all time. This conversation, as recorded in Wired, not only reiterates this belief but also shows how incredibly humble and self-effacing Berners-Lee is, as well as being the grand master of the understatement.

Last week in a place called Tyler, eastern Texas, a scene which could have come straight out of a Woody Allen film was played out. For background on the case see here but, in a nutshell, a company called Eolas, claims it owns patents that entitle it to royalties from anyone whose website uses “interactive” features, like pictures that the visitor can manipulate, or streaming video. The claim, by Eolas’s owner, one Michael Doyle, is that his was the first computer program enabling an “interactive web.” Tim Berners-Lee was called as an expert witness and was being cross-examined by Jennifer Doan, a Texas lawyer representing two of the defendants Yahoo and Amazon. This is how part of the cross-examination went.

When Berners-Lee invented the web, did he apply for a patent on it, Doan asked.

“No,” said Berners-Lee.

“Why not?” asked Doan.

“The internet was already around. I was taking hypertext, and it was around a long time too. I was taking stuff we knew how to do…. All I was doing was putting together bits that had been around for years in a particular combination to meet the needs that I have.” [My italics]

Doan: “And who owns the web?”

Berners-Lee: “We do.”

Doan: “The web we all own, is it ‘interactive’?”

“It is pretty interactive, yeah,” said Berners-Lee, smiling.

I just love this. Here's the guy that has given us one of the most game changing technologies of all time FOR NO PERSONAL GAIN TO HIMSELF, finding himself in a out of the way courtroom explaining one of the fundamental tenets of software architecture: putting together bits that have been around.

Setting aside the whole thorny question of software patents and whether they are actually evil this is surely one of the greatest and most understated descriptions of what we, as software architects, actually do by the master himself. Thank you Tim.

You're Building Me A What?

2012-02-10T23:22:00.000Z

This week I've been attending a cloud architecture workshop. Not to architect a cloud for anyone in particular but to learn what the approach to architecting clouds should be. This being an IBM workshop there was, of course, lots of Tivoli this, WebSphere that and Power the other. Whilst the workshop was full of good advice I couldn't help of thinking of this cartoon from 2008:

Courtesy geekandpoke.typepad.com

Just replace the word 'SOA' with 'cloud' (as 'SOA' could have been replaced by 'client-server' in the early nineties) and you get the idea. As software architects it is very easy to get seduced by technology, especially when it is new and your vendors, consultants and analysts are telling you this really is the future. However if you cannot explain to your client why you're building him a cloud and what business benefit it will bring him then you are likely to fail just as much with this technology as people have with previous technology choices.

On Being a Versatilist

2012-01-30T22:30:00.000Z

For some time now I've been discussing the idea of a versatilist as someone whose numerous roles (across business, science and the arts) assignments and experiences enable them to synthesize knowledge in new and exciting ways that may not have been possible if only one of these viewpoints were taken. I truly believe that this is such an interesting and fruitful topic that I have teamed up with David Evans, Principal Consultant and Owner at Koan Solutions Ltd and created a new blog on the topic of versatilism and what being a versatilist means.

Check out our new blog The Versatilist Way and give us your thoughts and ideas.

What Now for Internet Piracy?

2012-01-22T20:40:00.001Z

So SOPA is to be kicked into the long grass which means it is at least postponed if not killed altogether. For those who have not been following the Stop Online Piracy Act debate, this is the bill proposed by a U.S Republican Representative to expand the ability of U.S. law enforcement to fight online trafficking in copyrighted intellectual property (IP) and counterfeit goods. Supporters of SOPA said it would protect IP as well as the jobs and livelihoods of people (and organisations) involved in creating books, films music, photographs etc. Opponents reckoned the legislation threatened free speech and innovation and would enable law enforcement officers to block access to entire internet domains as well as violating the First Amendment. Inevitably much of the digerati came out in flat opposition of SOPA and staged an internet blackout on 18th January where many sites "went dark" and Wikipedia was unavailable altogether. Critics of SOPA cited that the fact the bill was supported by the music and movie industry was an indication that it was just another way of these industry dinosaurs protecting their monopoly over content distribution. So, a last minute victory for the new digital industry over the old analogue one?

And yet...

Check out this TED talk by digital commentator Clay Shirky called Why SOPA is a bad idea. Shirky in his usual compelling way puts a good case for why SOPA is bad (the talk was published before the recent announcement on the bill being postponed) but the real interest for me in this talk was from the comments about it. There are many people saying yes SOPA may be a bad bill but there is nonetheless a real problem with content being given away that should otherwise be paid for and that content creators (whether they be software developers, writers or photographers) are simply losing their livelihoods because people are stealing their work. Sure, there are copyright laws that are meant to prevent this sort of thing happening but who can really chase down the web sites and peer-to-peer networks that "share" content they have not created or paid for? SOPA may have been a bad bill and really have been about protecting the interests of large corporations who just want to carry on doing what they have always done without having to adapt or innovate. However without some sort of regulation that protects the interests of individuals or small start-ups wishing to earn a living from their art, killing SOPA has not moved us forward in any way and certainly not protected their interests. Unfortunately some sort if internet regulation is inevitable.

For a historical perspective of why this is likely to be so, see the TED talk by the Liberal Democrat Paddy Ashdown called The global power shift. Ashdown argues that "where power goes governance must follow" and that there is plenty of historical evidence showing what happens when this is not the case (the recent/current financial meltdown to name but one).

So SOPA may be dead but something needs to replace it and if we are to get the right kind of governance we must all participate in the debate else the powerful special interest groups will get their own way. Clay Shirky argued that if SOPA failed to be passed it would be replaced by something else. Now then is our chance to ensure that whatever that is, is right for content creators as well as distributors.

Architecting Out Complexity

2012-01-05T19:39:00.001Z

“Complexity kills. Complexity sucks the life out of users, developers and IT. Complexity makes products difficult to plan, build, test and use. Complexity introduces security challenges. Complexity causes administrator frustration.”

Ray Ozzie - Ex-Microsoft Chief Software Architect and Creator of Lotus Notes

Complexity, or more precisely, overly complicated systems (not to be confused with complex systems) is one of the key anti-patterns architects must continuously fight against. Complexity is caused not just by adding additional and unwanted functionality (although that certainly does not help) but also by muddled architectural thinking as well as poorly made architectural decisions. Here's the real problem though, the initial architecture of almost any system, unless it borrows very heavily from other, similar, architectures will rarely be without complexity. There will almost always be refinements that can be made, over time, that remove complexity and make for a cleaner and more streamlined design. Sometimes you may even need to throw away the initial architecture and start again, using what you have learnt from the initial architecture to take out complexity. Frederick Brooks (author of The Mythical Man Month) famously said of software designs "plan to throw one away, you will anyway".

The other problem with complexity in systems is that it tends to increase over time due to software entropy. As more changes are made, some not envisaged by the architect because change cases were not adequately thought through, a system naturally becomes more complicated and harder to maintain. It almost seems that the lifecycle of a system could be represented by the complexity curve in the diagram below.

Complexity does not just apply to systems, it also applies to whole styles of architecture. Cloud computing would still seem to be fairly early on in the complexity curve in this respect. Cloud computing is almost the ultimate in information hiding. Just put everything in the cloud and get what you want when you want it. If you're inside the cloud looking out however you need to deal with a whole lot of pain to create that outward facing simplicity. If you're a cloud architect therefore you need to understand and design for that complexity otherwise over time our clouds will become weighed down with out of date junk that no one wants. This is definitely a topic I'll be returning to over the course of 2012.

Architecting and Social Media

2011-12-15T21:39:00.001Z

The arguments for and against the rise of user generated content on the web continue to rage. Depending on which side of the debate you take we are either on an amoral downward spiral of increasingly meaningless content being generated by amateurs (for free) that is putting the professional writers, musicians, software developers, photographers etc out of work as well as ruining our brains or are entering a new age where the combination of an unbounded publishing engine and the cognitive surplus many people now have means we are able to build a better and more cooperative world.

Like most things in life the truth will not be at one of these polar opposites but somewhere in between. Seth Godin makes an interesting point in a recent blog entry that "lifestyle media isn't a fad it's what human beings have been doing forever, with a brief, recent interruption for a hundred years of professional media along the way". He goes on to say "we shouldn't be surprised when someone chooses to publish their photos, their words, their art or their opinions. We should be surprised when they don't."

After all, given the precarious nature of the press in the UK at the moment with stories being obtained through all sorts of dubious means the professionals can hardly be seen as holding the ethical or moral high ground.

The possibilities for creativity, and building interesting and innovative solutions out of this mixed bag of social media self-publishing is going to be the place where architects are going to have a fertile ground over the coming years. A nice example of this is Flipboard which if you have an iPhone or iPad you should definitely download. This free app is a “social magazine” that extends links your friends and contacts are sharing on Facebook, Twitter, Linkedin, 500px and others into beautifully packaged "articles". It can also pull in content from a raft of other online content. It's a great example of what architects should be doing, namely taking existing components and assembling them in interesting and innovative ways.

Computing: The Human Experience

2011-12-08T22:09:00.001Z

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.

Social Objects as Instruments of Architecture

2011-11-30T17:21:00.001Z

According to Hugh MacLeod a social object:

“is the reason two people are talking to each other, as opposed to talking to somebody else.”

also:

"social networks are built around social objects, not vice versa. The latter act as “nodes”. The nodes appear before the network does."

In discussions around architecture there can often be much confused talk around what is needed, what an architecture looks like and what decisions need to be made in order to make it so. There are three useful architectural social objects that help cystalise our thoughts and allow a network of related artefacts to be created. These are:

Use Cases or Scenarios - Illustrate what I am trying to do via real-world examples that use human actors to illustrate what we are trying to achieve.
Architecture Overview - The main architectural elements (components) that the system is comprised of.
Architectural Decisions - What decisions am I making, what options did I consider and why did I choose the ones I did.

These social objects seem to apply to all levels of architecture from the smallest application to the largest enterprise architecture. Of course they are by no means all you need but serve as a pretty good starting point for all that follows.

Educating an IT Workforce for the 21st Century

2011-11-28T08:35:00.001Z

A report on the BBC Today programme this morning argues that the "Facebook generation needs better IT skills" and that UK schools should be providing courses in programming at GCSE. The report bemoaned the fact that so called Information and Communications Technologiy (ICT) GCSEs did little more than teach students how to use Office programmes such as Word and Excel and did not prepare students for a career in IT. The backers of this report were companies like Google and Microsoft.

This raises an interesting question of who should be funding such education in these austere times. Is it the role of schools to provide quite specific skills like programming or should they be providing the basics of literacy and numeracy as well as the more fundamental skills of creativity, communication and collaboration and leave the specifics to the industries that need them? Here are some of the issues related to this:

Skills like computer programming are continuously evolving and changing. What is taught at 14 - 16 today (the age of GCSE students in the UK) will almost certainly be out of date when these students hit the work force at 21+.
The computer industry, just like manufacturing before it, long ago sent out the message to students that programming skills (in Western economies at least) were commoditised and better performed by the low-cost economies of the BRIC nations (and now, presumably, the CEVITS).
To most people computers are just tools. Like cars, washing machines and mobile phones they don't need to know how they work, just how to use them effectively.
Why stop at computer programming GCSE? Why not teach the basics of plumbing, car mechanics, cookery and hairdressing, all of which are in great demand still and needed by their respective industries.
Public education (which essentially did not exist before the 19th century, certainly not for the masses) came about to meet the needs of industrialism and as such demanded skills in left-brained, logical thinking skills rather than right brained, creative skills (see Sir Ken Robinson's TED talk on why schools kill creativity). As a result we have a system that rewards the former rather than the latter (as in "there's no point in studying painting or music, you'll never get a job in that").

In an ideal world we would all be given the opportunities to learn and apply whatever skills we wanted (both at school and throughout life) and have that learning funded by the tax payer on the basis it benefits society as a whole. Unfortunately we don't live in that ideal world and in fact are probably moving further from it than ever.

Back in the real world therefore industry must surely fund the acquiring of those skills. Unfortunately in many companies education is the first thing to be cut when times are hard. The opposite should be the case. One of the best things I ever did was to spend five weeks (yes that's weeks not days), funded entirely by IBM, learning object-oriented programming and design. Whilst five weeks may seem like a long time for a course I know this has paid for itself many, many times over by the work I have been able to do for IBM in the 15 years since attending that course. Further, I suspect that five weeks intensive learning was easily equivalent to at least a years worth of learning in an educational establishment.

Of course such skills are more vital to companies like Google, Microsoft and IBM than ever before. Steve Denning in an article called Why Big Companies Die in Forbes this month quotes from an article by Peggy Noonan in the Wall Street Journal (called A Caveman Won't Beat a Salesman). Denning uses a theory from Steve Jobs that big companies fail when salesmen and accountants are put in charge of and who don't know anything about the product or service the company make or how it works. Denning says:

"The activities of these people [salesmen and accountants] further dispirit the creators, the product engineers and designers, and also crimp the firm’s ability to add value to its customers. But because the accountants appear to be adding to the firm’s short-term profitability, as a class they are also celebrated and well-rewarded, even as their activities systematically kill the firm’s future".

Steve Jobs showed that there was another way. Namely, to keep playing the offense and focus totally on adding value for customers by creating new and innovative new products. By doing that you can make more money than the companies that are milking their cash cows and focused on making money rather than products.

Companies like Google and Microsoft (and IBM and Apple) need people fully trained in the three C's (creativity, communication and creativity) who can then apply these to whatever task is most relevant to the conmpanies bottom line. It's the role of those companies, not government, to train people in the specifics.

Interestingly Seymour Papert (who co-invented the Logo programming language) used programming as a tool to improve the way that children think and solve problems. Papert used Piaget's work of cognitive development (that showed how children learn) and used Logo as a way of improving their creativity.

Finally, to see how students themselves view all this see the article by Nikhil Goyal's (a 16-year-old junior at Syosset High School in New York) who states: "for the 21st century American economy, all economic value will derive from entrepreneurship and innovation. Low-cost manufacturing will essentially be wiped out of this country and shipped to China, India, and other nations" and goes on to propose that
"we institute a 21st century model of education, rooted in 21st century learning skills and creativity, imagination, discovery, and project-based learning". Powerful stuff for one so young, there may yet be hope for us.

Parkinson's Law of Triviality (Applied to Architecture)

2011-11-17T10:20:00.001Z

Parkinson's Law of Triviality (as proposed by C. Northcote Parkinson in 1957) is that people give disproportionate weight to trivial issues. Parkinson gives as an example a hypothetical (planning) committe deliberating on the building of a nuclear power plant and a bicycle shed. Parkinson stated that "the time spent on any item of the agenda will be in inverse proportion to the sum involved." Clearly a nuclear reactor is vastly expensive and complicated and the average person is unlikley to understand it because it is so far outside the realms of their daily experience. A bike shed, on the other hand, everyone understands (or thinks they do, which can be even more dangerous). The result is that people will be reluctant to discuss for long the nuclear reactor either because they assume those working on it understand it or because they are to fearful of making themselves look foolish in front of the experts. The bike shed however can result in endless discussions because everyone involved wants to add their "feature" and show that they have contributed. While discussing the bikeshed, debate rages over what the best choice of roofing should be, whether there should be windows, whether it should be fully enclosed with walls and a door etc, etc rather than whether the shed is a good idea or not.

Parkinson's Law of Triviality is something that frequently creeps into architecture discussions. When requirements are being discussed and how best to realize them architecturally it is frequently the case that when the domain under discussion consists of parts that are familiar and ones that are not it is the former that will often receive inordinate amounts of discussion whereas the latter do not (but usually should). A good example to illustrate this is that of e-commerce systems. Because most people have used such systems everyone will have an opinion on the bits they are familiar with (the actual look and feel of the shopping experience for example, do you call it a shopping basket or a trolley, do you allow goods to be placed in the basket before you have logged in or registered and so on). The part of the system that deals with payment however (i.e. that goes off in the background and does credit checks etc) or checking stock level is not seen so people will probably have less of an opinion on it. This part, at least as far as the web site owner is concerned, is the most important however because if that does not work he will lose money. Worse however is if the "payments specialist" says that this is the way payments will work, and no one else feels they have the expertise or authority to challenge her. Doing something because that's the way we always do it is an example of the Golden Hammer anti-pattern and does not always result in the most innovative or creative new systems.

So how to protect against falling foul of Parkinson's Law of Triviality?

Good architects need to develop deep domain knowledge and know how to, and be fearless in doing so, challenge expert opinion. Frequently appearing foolish by challenging the blindingly obvious is a small price to pay for occasionally highlighting a problem which everyone else overlooked because they were following conventional wisdom.
Ensure complex problems receive proportionately more discussion than simple ones. In other words cut the discussion of addressing the simple problem sooner to allow time to discuss the complex ones. Better still if in a meeting there are several problems to be discussed prioritise them by complexity and start with the most complex first. Leaving simpler ones till the end means you can rush those through when everyone gets tired or you are out of time.
Recognise that everyone has an equal say and it is often the people who know least about the problem that ask the daft, but hard, questions. This of course would seem to go against number 1. If everyone is an expert doesn't that mean no one will be naive enough to ask the simple but challenging questions? No. A good team has a diverse mix of skills, knowledge and opinions and should allow everyone to comment.
Leave your ego at the meeting room door and do not use your relative position in the hierarchy of the company to trivialise other peoples ideas or prevent constructive discussion because it is not "going your way".
Finally capture all decisions in a systematic way (recording at the very least what the decision was, what options were discussed, the rationale for choosing the one you did and any related decisions or implications).

What Can Architects Learn from Steve Jobs

2011-11-08T09:04:00.001Z

I've just finished reading Steve Jobs by Walter Isaacson. In case there is anyone out there who doesn't know it yet, this is the authorised biography that Jobs asked Isaacson to write which was completed a few weeks before Jobs untimely death aged 56 last month. Jobs insisted that Isaacson would have complete control over the contents of the book saying he would not even read it before it was published adding "I don't have any skeletons in my closet that can't be allowed out".

Jobs is clearly a very complex personality, on the one hand a creative genius whose zen like focus on simplicity and efficiency helped create some of the most beautiful and useful gadgets of our time (some of which we never even knew we needed) whilst on the other he was a bully and a tyrant who knew exactly how to "size people up, understand their inner thoughts, and know how to relate to them, cajole them, or hurt them at will". One of jobs girl friends, who later went on to found a mental health resource network in California, even went so far to say that she thought Jobs suffered from Narcissistic Personality Disorder (NPD) in which the individual is described as being excessively preoccupied with issues of personal adequacy, power, prestige and vanity.

Whilst it is to be hoped that NPD is not a prerequisite for being a software architect Jobs did have vision and understanding of IT that we as architects can learn from. Six big ideas that stand out in this respect are:

Engineering matters. When jobs met with President Obama in 2011 he implored the President to reform the US education system and to create more engineering students. Jobs said "if you could educate these engineers we could move more manufacturing plants here". Whilst there was always an uneasy tension between engineering and design at Apple Jobs recognised and valued the importance of there being an engineering led rather than sales led team at the top of the company berating companies like Microsoft (under Balmer), IBM (under Akers) and HP (under their last several CEOs) for putting sales people in charge rather than engineers. For software architects, engineering clearly translates to being intimately knowledgeable with the technology you are using, knowing how to put the working parts together. The best architects I know are passionate about technology.
Artistry and design matters just as much as engineering. This is a theme that Jobs emphasises over and over again. From when he dropped out of college and instead took a course on calligraphy to his sometimes maniacal focus on the smallest details of design to make the product as satisfying and aesthetically pleasing as possible. He even emphasized that circuit boards, which no one would ever see once the product was fully assembled, should be laid out in as clean and uncluttered was as possible. It is this aspect of design that most matters for architects. Provided that functionally a system does what it is meant to do within the required constraints and system qualities one could argue it does not matter how messily the software is assembled. Whose going to see it anyway? This misses the point though.Great design, as opposed to just good enough design, means the system will be easier to maintain, take less effort to learn and generally be more enjoyable for those that need to carry on working on it once the architects and developers have moved on.
Simple is better than complex. Apple had a design mantra: "Simplicity is the ultimate sophistication" or as Jobs said "very simple, and we're really shooting for Museum of Modern Art quality". Jobs felt that design simplicity should be linked to making products easy to use.So much of the software that we create today is far too complex and feature rich and as a result is very hard to use. People will often say that it has to be like that because just look at all the features you are getting. Unfortunately a lot of the time many of those features are not needed but add to the general bloat of the systems we build making them hard to use as well as difficult to maintain. Sadly building a complex system is often easier than building a simple one and it is not many architects that see value in stripping out functionality rather than adding it.
An unremitting focus on detail is key to creating a great product. Jobs was unique in that he was able to hold both the big picture view as well as zooming in to fine details. He would often sweat over the smallest detail until he was satisfied it was just right. This could be anything from the colour of a screw on the back plate of the iPod to the angle of the bevel on the iPad to make someone want to pick it up. This capacity for holding both the big picture view whilst also being able to zoom right down and question low level details is probably one of the hardest things architects have to do but being able to do so gives a definite advantage and enables greater integrity as well as better execution of vision.
Customers don't always know what they want. In September 1982 when Jobs and his team were designing the original Macintosh he held a retreat for the Mac team near Monteray where he gave a presentation on his thoughts for the Mac. At the end someone asked whether or not they should do some market research to find out what customers wanted. "No", replied Jobs, "because people don't know what they want until we've shown them". He then pulled out a device the size of a desk diary and flipped it open, it turned out to be a mock-up of a computer that could fit into your lap with a keyboard and screen hinged together like a notebook. "This is my dream of what we will be making in the mid- to late eighties", Jobs said. Apple supposedly never did do any market research preferring to follow the Henry Ford approach who said he never asked what people wanted because they would have just asked for a better horseless carriage. Whilst it is probably the case that people can often see how to make incremental improvements to products they usually cannot see how to make disruptive changes that introduce a who new way of doing things, possibly making everything that went before it redundant. It is the job of the architect to show what is in the realms of the possible by creating new and innovative systems.
Putting things together in new and creative ways is sometimes more important than inventing things. Jobs was not the first to market with an MP3 player, a mobile phone or a tablet computer. Others had already innovated and built these things. What Jobs and Apple did were to tweak things that already existed. As Isaacson says "he had noticed something odd about the cell phones on the market: They all stank, just like portable music players used to". Jobs applied his design skills to these and came up with a (far) better product and in fact a whole new platform as well (i.e. the computer as the digital hub. Architects to need to learn that its often putting together existing components in new and innovative ways that really counts and gives a competitive and business advantage.

Creativity at Scale

2011-10-31T20:21:00.000Z

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.

Five IT Trends for Architects to Ponder

2011-10-31T15:36:00.001Z

This article on five big IT trends is interesting and highlights those areas you might want to consider improving your knowledge and skills in if you want to remain in-demand in the coming year or two. The trends are:

Mobile
Social Computing
Cloud
Consumerization
Big Data

After this bit of new I would also add cyber-security as a sixth!

Blackberry's Perfect Storm

2011-10-21T17:35:00.000+01:00

A perfect storm is defined as being: a critical or disastrous situation created by a powerful concurrence of factors.

A perfect storm is certainly what RIM, makers of the Blackberry, have been experiencing recently. For three days, starting on 10th October a problem caused by a router in an unassuming two-storey building in Slough, UK affected almost every one of its users around the world. Not only were users unable to Twitter, or Facebook, more seriously, those users who rely on their Blackberrys for email to do their business may have lost valuable work. Whilst many commentators may have made light of the situation, because people could no longer tweet their every movement, there is a far more serious message here which is that as a civilisation we are now completely dependent on software and hardware technology that runs our daily lives.

Here's what Blackberry had to say on their service bulletin board on 11th October, mid-way through the crisis:

The messaging and browsing delays that some of you are still experiencing were caused by a core switch failure within RIM’s infrastructure. Although the system is designed to failover to a back-up switch, the failover did not function as previously tested...

Unfortunately for Blackberry it was not only this technical and process failure that formed part of their perfect storm but two other factors, they could not hoped to have predicted, also occurred recently. One was the launch of the latest iPhone 4S from Apple which was released the very same week as Blackberry's network failure. The other is the allegation that Blackberry's, or more precisely the Blackberry Messaging Service (BBM), were implicated in the recent riots that took place in London and other UK cities in the summer. For many teens armed with a BlackBerry, BBM has replaced text messaging because it is free, instant and more part of a much larger community than regular SMS. Also, unlike Twitter or Facebook, many BBM messages are untraceable by the authorities.

From an IT architecture point of view clearly the technical and process failure of such a crucial data centre should just not have been allowed to happen. In some ways Blackberry has been a victim of its own success with the number of users growing from 10 million in 2005 to 70 million now without a corresponding increase in capacity of its network and fully functioning failover facility. However the more interesting, and in some ways more intractable, problem is the competitive, sociological and even ethical aspects of the situation. When Apple launched the first iPhone back in 2007 they changed forever the way people interacted with their phones. Some people have observed that the tactile way in which people "stroke" an iPhone rather than jab at tiny buttons has led to their more widespread adoption. Clearly a case of getting the human-computer interface right paying great dividends. Who would have thought however that the very aspect that once made Blackberry's so popular with business users (their security) could backfire on them in quite such a significant way? Architecture (and design) is not just about getting the right features at the right price it is also about thinking through the likely impact of those features in contexts that may not initially have been envisaged.

Steve Jobs 1955 - 2011

2011-10-06T14:00:00.001+01:00

During the coming days and weeks millions of words will be written about Steve Jobs, many of them on devices he created. Why does the world care so much about an American CEO and computer nerd?

For those of us that work with technology, and hope to use it to make the world a better place, the reason Steve Jobs was such a role model is that he not only had great vision and a brilliant understanding of design but also knew how to deliver technology in a form that was usable by everyone, not just technophiles, nerds and developers. Steve Jobs and Apple have transformed the way we interact with data, and the way that we think about computing, moving it from the desktop to the palm of our hands. As IT becomes ever more pervasive we could all learn from that and maybe even hope to emulate Steve Jobs a little.

Reusable Assets for Architects

2011-09-30T21:32:00.001+01:00

Architects are fond of throwing terms around which have mixed, ambiguous or largely non-existent formal definitions. Indeed one of the great problems (still) of our profession is that people cannot agree on the meanings of many of the terms we use everyday. There is no 'common language' that all architects speak. If you want to see some examples look up terms like 'enterprise architecture' or 'cloud computing' in wikipedia then look at what's written in the 'discussion' section.

Three terms that often get misused or are used interchangeably fall under the general category of reusable assets. A reusable asset is something which has been proven to be useful, in some form or another, in one project or architectural definition and could be reused elsewhere. The Object Management Group (OMG) defines a reusable asset as one that: provides a solution to a problem for a given context. See the OMG Reusable Asset Specification. Those of you familiar with the classic Design Patterns book by the so called "Gang of Four" will recognise elements of this definition from that book. Indeed reusable assets are a generalization of design patterns. Three other reusable assets, which are of particular use to an architect, are:

Reference architectures
Application frameworks
Industry solutions

What do each of these mean, what's the difference and when (or how) can they be used?

A reference architecture is a template which shows, usually at a logical level, a set of components and their relationships. Reference architectures are usually created based on perceived best-practice at the time of their creation. This is both a good thing (you get the latest thinking) but can also be bad (they can become dated). Reference architectures are usually associated with a particular domain which could either be a business (e.g. IBM's Insurance Application Architecture or IAA) or industry (such as a banking reference architecture) or technology domain (e.g. cloud and SOA). Ideally reference architectures will not preordain any technology and will allow multiple vendors products to be mapped to each of the components. Sometimes vendors use reference architectures as a way of placing their tools or products into a cohesive set of products that work together.

An application framework represents the partial implementation of a specific area of a system or an application. Reference architectures may be composed of a number of application frameworks. Probably one of the best known application frameworks is Struts from the Apache open source organisation. Struts is a Java implementation of the Model-View-Controller pattern which can be 'completed' by developers for their own applications.

Finally an industry solution is a set of pre-configured (or configurable) software components designed to meet specific business requirements of a particular industry. Industry solutions are usually created and sold by software vendors and are based on their own software products. However the best solutions adhere to open standards and would allow other vendors products to be used as well. Most organisations want to avoid vendor lock-in and are unlikely to take the "whole enchilada". Industry solutions may be implementations of one or more reference architectures. For example IBM's Retail Industry Framework implements reference architectures from a number of domains (supply chain, merchandising and product management and so on).

Assets can be considered in terms of their granularity (size) and their level of articulation (implementation). Granularity is related to both the number of elements that comprise the asset and the asset’s impact on the overall architecture. Articulation is concerned with the extent to which the asset can be considered complete. Some assets are specifications only, that is to say are represented in an abstract form, such as a model or document. Other assets are considered to be complete implementations and can be instantiated as is, without modification. Such assets include components and existing applications. The diagram below places the three assets I've discussed above in terms of their granularity and articulation.

There are of course a whole range of other reusable assets: design patterns, idioms, components, complete applications and so on. These could be classified in a similar way. The above are the ones that I think architects are most likely to find useful however.

Plus Two More

2011-09-29T22:16:00.002+01:00

In my previous post on five architectures that changed the world I left out a couple that didn't fit my self-imposed criteria. Here, therefore, are two more, the first of which is a bit too techie to be a part of everyone's lives but is nonetheless hugely important and the second of which has not changed the world yet but has pretty big potential to do so.

IBM System/360
Before the System/360 there was very little interchangeability between computers, even from the same manufacturers. Software had to be created for each type of computer making them very difficult to develop applications for as well as maintain. The System/360 practically invented the concept of architecture as applied to computers in that it had an architecture specification that did not make any assumptions on the implementation itself, but rather describes the interfaces and the expected behavior of an implementation. The System/360 was the first family of computers designed to cover the complete range of applications, from small to large, both commercial and scientific. The development of the System/360 cost $5 billion back in 1964, that's $34 billion of today's money and almost destroyed IBM.

Watson
Unless you are American you had probably never heard of the TV game show called Jeopardy! up until the start of 2011. Now we know that it is a show that "uses puns, subtlety and wordplay" that humans enjoy but which computers would get tied up in knots over. This, it turns out, was the challenge that David Ferrucci, the IBM scientist who led the four year quest to build Watson, had set himself to compete live against humans in the TV show.

IBM has "form" on building computers to play games! The previous one (Deep Blue) won a six-game match by two wins to one with three draws against world chess champion Garry Kasparov in 1997. Chess, it turns out, is a breeze to play compared to Jeopardy! Here's why.
Chess...

§Is a finite, mathematically well-defined search space.
•Has a large but limited number of moves and states.
•Makes everything explicit and has unambiguous mathematical rules which computers love.

§•Games like Jeopardy! play on the subtleties of the human language however which is...

Ambiguous, contextual and implicit.
•Grounded only in human cognition.
•Can have a seemingly infinite number of ways to express the same meaning.

According to IBM Watson is "built on IBM's DeepQA technology for hypothesis generation, massive evidence gathering, analysis, and scoring." Phew! The point of Watson however is not its ability to play a game show but in the potential to "weaves its fabric" into the messiness of our human lives where data is not kept in nice ordered relational databases but is unstructured and seemingly unrelated but nevertheless can sometimes have new and undiscovered meaning. One obvious application is in medical diagnosis but it could also be used in a vast array of other situations from help desks through to sorting out what benefits you are entitled to. So, not world changing yet but definitely watch this space.

Five Architectures That Changed The World

2011-09-28T16:15:00.000+01:00

A favourite quote of mine from Grady Booch is:

"Software is the invisible thread and hardware is the loom on which computing weaves its fabric, a fabric that we have now draped across all of life".

Software, although an "invisible thread" has certainly had a significant and visible 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.

First, exactly 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, preferably, must have woven its way into peoples lives.
Does not have to have introduced any new technology, may also have used use 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".
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).
Has emergent properties and been extended in ways the architect(s) did not originally envisage.

Based on these criteria then 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 created 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). Wilipedia 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 also 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.

Emergent Architectures

2011-09-14T19:16:00.000+01:00

I was slightly alarmed to read recently in a document describing a particular adaptation of the unified process that allowing architectures to ‘emerge’ was a poor excuse to avoid hard thinking and planning and that emergent architectures, and anyone who advocates them, should be avoided.

The term 'emergent architecture' was, I believe, first coined by Gartner (see here) and applied to Enterprise Architecture. Gartner identified a number of characteristics that could be applied to emergent architectures one of which was that they are non-deterministic. Traditionally (enterprise) architects applied centralised decision-making to design outcomes. Using emergent architecture, they instead must decentralise decision-making to enable innovation.

Whilst emergent architectures certainly have their challenges it is my belief that, if well managed, they can only be a good thing and should certainly not be discouraged. Indeed I would say that emergence could be applied at a Solution Architecture level as well and is ideally suited to more agile approaches where everything is simply not known up front. The key thing with managing an emergent architecture is to capture architectural decisions as you go and ensure the architecture adapts as a result of real business needs.

What Would Google Do?

2011-08-30T23:54:00.003+01:00

Readers of this blog will know that one of my interests/research areas is how to effectively bring together left-brain (i.e. logical) and right-brain (i.e. creative) thinkers in order to drive creativity and generate new and innovative ideas to solve some of the worlds wicked problems. One of the books that have most influenced me in this respect is Daniel Pink's A Whole New Mind - Why Right-Brainers Will Rule the Future. Together with a colleague I am developing the concept of the versatilist (first coined by Gartner) as a role that effectively brings together both right- and left-brain thinkers to solve some of the knotty business problems there are out there. As part of this we are developing a series of brain exercises that can be given to students on creative, problem solving courses to open up their minds and start them thinking outside the proverbial box. One of these exercises is called What Would Google Do? The idea being to try and get them to take the non-conventional, Google, view of how to solve a problem. By way of an example Douglas Edwards, in his book I'm Feeling Lucky - The Confessions of Google Employee Number 59, relates the following story about how Sergey Brin, co-founder of Google, proposed an innovative approach to marketing.

"Why don't we take the marketing budget and use it to inoculate Chechen refugees against cholera. It will help our brand awareness and we'll get more new people to use Google."

Just how serious Brin was being here we'll never know but you get the general idea; no idea is too outrageous for folk in the Googleplex.

To further backup how serious Google are about creativity their chairman Eric Schmidt, delivered a "devastating critique of the UK's education system and said the country had failed to capitalise on its record of innovation in science and engineering" at this year's MacTaggart lecture in Edinburgh. Amongst other criticisms Schmidt aimed at the UK education system he said that the country that invented the computer was "throwing away your great computer heritage by failing to teach programming in schools " and was flabbergasted to learn that today computer science isn't even taught as standard in UK schools. Instead the IT curriculum "focuses on teaching how to use software, but gives no insight into how it's made." For those of us bought up in the UK at the time of the BBC Microcomputer hopefully this guy will be the saviour of the current generation of programmers.

US readers of this blog should not feel too smug, check out this YouTube video from Dr. Michio Kaku who gives an equally devastating critique of the US education system.

So, all in all, I think the world definitely needs more of a versatilist approach, not only in our education systems but also in the ways we approach problem solving in the workplace. Steve Jobs, the chief executive of Apple, who revealed last week that he was stepping down once told the New York Times: "The Macintosh turned out so well because the people working on it were musicians, artists, poets and historians – who also happened to be excellent computer scientists". Once again Apple got this right several years ago and are now reaping the benefits of that far reaching, versatilist approach.

Creative Leaps and the Importance of Domain Knowledge

2011-08-25T22:30:00.000+01:00

Sometimes innovation appears to come out of nowhere. Creative individuals, or companies, appear to be in touch with the zeitgeist of the times and develop a product (or service) that does not just satisfy an unknown need but may even create a whole new market that didn't previously exist. I would put James Dyson (bagless vacuum cleaner) as an example of the former and Steve Jobs/Apple (iPad) as an example of the latter.

Sometimes the innovation may even be a disruptive technology that creates a new market where one previously did not exist and may even destroy existing markets. Digital photography and its impact on the 35mm film producing companies (Kodak and Ilford) is a classic example of such a disruptive technology.

Most times however creativity comes from simply putting together existing components in new and interesting ways that meet a business need. For merely mortal software architects if we are to do this we not only need a good understanding of what those components do but also how the domain we are working in really, really works. You need to not only be curious about your domain (whether it be financial services, retail, public sector or whatever) but be able to ask the hard questions that no one else thought or bothered to ask. Sometimes this means not following the herd and being fashionable but being completely unfashionable. As Paul Arden, the Creative Director of Saatchi and Saatchi said in his book Whatever You Think, Think The Opposite:

"People who create work that fashionable people emulate do the very opposite of what is in fashion. They create something unfashionable, out of time, wrong. Original ideas are created by original people, people who either through instinct or insight know the value of being different and recognise the commonplace as a dangerous place to be."

So do you want to be fashionable or unfashionable?

On Being an Effective Architect

2011-08-12T23:50:00.001+01:00

In a previous blog entry I talked about the key skills architects needed to develop to perform their craft which I termed the essence of being an architect. Developing this theme slightly I also think there is a process that architects need to follow if they are to be effective. Stripped down to its bare essentials this process is as shown below.

This is not meant to be a process in the strict SDLC sense of the word but more of a meta-process that applies across any SDLC. Here's what each of the steps means and some of the artefacts that would typically be created in each step (shown in italics).

Envision - Above all else the architect needs to define and maintain the vision of what the system is to be. This can be in the form of one or more, free-format Architecture Overview diagrams and would certainly include having an overall System Context that defined the boundary around the system under development (SUD). The vision would also include capturing the key Architectural Decisions that have shaped the system to be the way it is and also refer to some of the key Architecture Principles that are being followed.
Realise -As well as having a vision of how the system will be the architect must know how to realise her vision otherwise the architecture will remain as mere paper or bits and bytes stored in a modeling tool. Realisation is about making choices of which technology will be used to implement the system. Choices considered may be captured as Architectural Decisions and issues or risks associated with making such decisions captured in a RAID Log (Risks-Assumptions-Issues-Dependencies). Technical Prototypes may also be built to prove some of the technologies being selected.
Influence -Above all else architects need to be able to exert the required influence to carry through their vision and the realisation of that vision. Some people would refer to this as governance however for me influence is a more subtle, background task that, if done well, is almost unnoticed but nonetheless has the desired effect. Influencing is about having and following a Stakeholder Management Plan and communicating your architecture frequently to your key stakeholders.

Each of these steps are performed many times, or even continuously, on a project. Influencing means listening as well and this may lead to changes in your vision thus starting the whole cycle again.

Adopting this approach is not guaranteed to give you perfect systems as their are lots of other factors, as well as people, that come into play during a typical project. What it will do is give you a framework that allows you to bring some level of rigour to the way you develop your architectures and work with stakeholders on a project.

Happy Birthday WWW

2011-08-06T09:20:00.001+01:00

Today is the 20th anniversary of the world wide web; or at least the anniversary of the first web page. On this day in 1991 Tim Berners-Lee posted a short summary of the World Wide Web project on the alt.hypertext newsgroup:

The WorldWideWeb (WWW) project aims to allow all links to be made to any information anywhere. [...] The WWW project was started to allow high energy physicists to share data, news, and documentation. We are very interested in spreading the web to other areas, and having gateway servers for other data. Collaborators welcome!

He certainly found a lot of collaborators!

As I've said before I believe the WWW is one of the greatest feats of software architecture ever performed. Happy Birthday WWW!

The Tools We Use

2011-08-03T15:36:00.000+01:00

Back in 1964 Marshall McLuhan said "We shape our tools and afterwards our tools shape us". McLuhan was actually talking about the media when he said this but much of what he said then has a great deal of relevance in today's mixed up media world too.

It occurs to me that McLuhan's tool quote equally applies to the tools we use, or misuse, as software architects. PowerPoint (or Keynote for that matter) has received pretty bad press over the years as being a tool that inhibits rather than enhances our creativity. Whilst this does not have to be the case, too many people take tools, such as PowerPoint, and use them in ways I'm pretty sure their creators never intended. Here are some common tool (mis)uses I've observed over the years (anti-patterns for tools if you like):

Spreadsheets as a databases. Too many people seem to use spreadsheets as a sort of global repository for dumping ideas, data and information in general because it gives them the ability to easily sort and categorise information. Spreadsheets are good at numbers and presenting analytical data but not for capturing textual information.
Presentations as documents. Sometimes what started out as a presentation to illustrate a good idea seems to grow into a more detailed description of that idea and eventually turns into a full-blown specification! The excuse for doing this being "we can use this to present to the client as well as leaving it with them at the end of the project as the design of the system". Bad idea!
Presentations as a substitute for presenting. The best presenters present "naked". Minimal presentations (where sometimes minimal = 0) where the presenter is at the fore and his or her slides are illustrating the key ideas is what presenting is or should be about. Did John F Kennedy, Winston Churchill or Martin Luther King rely on PowerPoint to get their big ideas across? I think not!
Word processors as presentations. This is the opposite of number 2. Whilst not so common people have been known in my experience to 'present' their documents on a screen in a meeting. It goes without saying, or should do, that 12pt (or less) text does not come across well on a screen.
Word processors as web sites. Although most word processors have the capability of generating HTML this is not a good reason for using them to build web sites. There are a multitude of free, open and paid for tools that do a far better job of this.
Emails as documents. This is variant (generalisation) of one of my favourite [sic] anti-patterns. e-mails are one of the greatest sources of unstructured data in the world today. There must be, literally, terabytes of data stored using this medium that should otherwise be captured in a more readily consumable and accessible form. e-mails clearly have a place for forming ideas but not for capturing outcomes and persisting those ideas so others can see them and learn from them.

Oh Dear, Here We Go Again!

2011-07-28T18:30:00.000+01:00

So, here we go again. The BBC today report that "IT giants are 'ripping off' Whitehall, say MPs". As I presumably work for one of those "IT giants" I will attempt to comment on this in as impartial a way as is possible.

As long as we have 'IT projects' rather than 'business improvement' or 'business change' projects in government, or anywhere else come to that, we (and it is 'we' as tax payers) will continue to get 'ripped off'. Buying IT because it is 'sexy' is always going to end in tears. IT is a tool that may or may not fix a business problem. Unless you understand the true nature of that business problem throwing IT at it is doomed to failure. This is what software architects need to focus on. I'm coming to the conclusion that the best architects are actually technophobes rather than technophiles.
It's not Whitehall that is being 'ripped off' here. It's you and me as tax payers (assuming you live in the UK and pay taxes to the UK government of course). Whether you work in IT or anywhere else this effects you.
It's not only understanding the requirements that is important, it's also challenging those requirements as well as the business case that led to them in the first place. I suspect that many, many projects have been dreamt up as someones fantasy, nice to have system rather than having any real business value.
Governments should be no different from anyone else when it comes to buying IT. If I'm in the market for a new laptop I usually spend a little time reading up on what other buyers think and generally make sure I'm not about to buy something that's not fit for purpose. One of the criticisms leveled at government in this report is the "lack of IT skills in government and over-reliance on contracting out". In other words there are not enough experienced architects who work in government that can challenge some of the assumptions and proposed solutions that come from vendors.
Both vendors and government departments need to learn how to make agile work on large projects. We have enough experience now to know that multi-year, multi-person, multi-million pound projects that aim to deliver 'big-bang' fashion just do not work. Bringing a more agile approach to the table, delivering a little but more often so users can verify and feedback on what they are getting for their money is surely the way to go. This approach depends on more trust between client and supplier as well as better and more continuous engagement throughout the project's life.

The Innovation Conundrum and Why Architecture Matters

2011-07-27T22:48:00.001+01:00

A number of items in the financial and business news last week set me thinking about why architecture matters to innovation. Both IBM and Apple announced their second quarter results. IBM's revenue for Q2 2011 was $26.7B, up 12% on the same quarter last year and Apples revenue for the same quarter was $24.67B, an incredible 83% jump on the same quarter last year. As I'm sure everyone now knows IBM is 100 years old this year whereas Apple is a mere 35 years old. It looks like both Apple and IBM will become $100B companies this year if all goes to plan (IBM having missed joining the $100B club by a mere $0.1B in 2010).

Coincidentally a Forbes article also caught my eye. Forbes listed the top 100 innovative companies. Top of the list was salesforce.com, Apple were number 5 and IBM were, er, not in the top 100! So what's going on here? How can a company that pretty much invented the mainframe and personal computer, helped put a man on the moon, invented the scanning electron microscope and scratched the letters IBM onto a nickel crystal one atom at a time, and, most recently, took artificial intelligence a giant leap forward with Watson not be classed as innovative?

Perhaps the clue is in what the measure of innovation is. The Forbes article measures innovation by an "innovation premium" which it defines as:

"A measure of how much investors have bid up the stock price of a company above the value of its existing business based on expectations of future innovative results (new products, services and markets)".

So it would appear that, going by this definition of innovation, investors don't think IBM is expected to be bringing any innovative products or services to market whereas the world will no doubt be inundated with all sorts of shiny iThingys over the course of the next year or so. But is that really all there is to being innovative? I would venture not.

The final article that caught my eye was about Apples cash reserves. Depending on which source you read this is around $60B and as anyone who has any cash to invest knows, sitting on it is not the best way of getting good returns! Companies generally have a few options with what to do when they amass so much cash, pay out higher dividends to shareholders, buy back their own shares, invest more in R&D or go on a buying spree and buy some companies that fill holes in their portfolio. Whilst this is a good way of quickly entering into markets companies may not be active in it tends to backfire on the innovation premium as mergers and acquisitions (M&A) are not, at least initially, seen as bringing anything new to market. M&A's has been IBM's approach over the last decade or so. As well as the big software brands like Lotus, Rational and Tivoli IBM has more recently bought lots of smaller software companies such as Cast Iron Systems, SPSS Statistics and Netezza.

A potential problem with this approach is that people don't want to buy a "bag of bits" and have to assemble their own solutions Lego style. What they want are business solutions that address the very real and complex (wicked, even) problems they face today. This is where the software architect comes into his or her own. The role of the software architect is to "take existing components and assemble them in interesting and important ways". To that I would add innovative ways as well. Companies no longer want the same old solutions (ERP system, contact management system etc) but new and innovative systems that solve their business problems. This is why we have one of the more interesting jobs there is out there today!

A Service Based Development Process - Part 4

2011-07-21T20:33:00.000+01:00

The first three of these blog posts (here, here and here) have looked at the process behind developing business processes and services that could be deployed into an appropriate environment, including a cloud (private, public or hybrid). In this final post I'll take a look at how to make this 'real' by describing an architecture that could be used for developing and deploying services, together with some software products for realising that architecture.

The diagram below shows both the development time and also run-time logical level architecture of a system that could be used for both developing and deploying business processes and services. This has been created using the sketching capability of Rational Software Architect.

Here's a brief summary of what each of the logical components in this architecture sketch do (i.e. their responsibilities):

SDLC Repository - The description of the SDLC goes here. That is the work breakdown structure, a description of all the phases, activities and tasks as well as the work products to be created by each task and also the roles used to create them. This would be created and modified by the actor Method Author using a SDLC Developer tool. The repository would typically include guidance (examples, templates, guidelines etc) that show how the SDLC is to be used and how to create work products.
SDLC Developer - The tool used by the Method Author to compose new or modify existing processes. This tool published the SDLC into the SDLC Repository.
Development Artefacts Repository - This is where the work products that are created on an actual project (i.e. 'instances' of the work products described in the SDLC) get placed.
Business Process Developer - The tool used to create and modify business processes.
IT Service Developer - The tool used to create and modify services.
Development Repository - This is where 'code' level artefacts get stored during development. This could be a subset of the Development Artefacts Repository.
Runtime Services Repository -Services get published hereonce they have been certified and can be released for general use.
Process Engine - Executes the business process.
Enterprise Service Bus - Runs the services and provides adapters to external or legacy systems.

Having described the logical components the next step is to show how these can be realised using one or more vendors products. No surprise that I am going to show how these map to products from IBM's portfolio however clearly your own particular requirements (including whose on your preferred vendor list of course) may dictate that you choose other vendors products. Nearly all the IBM product links allow you to download trial versions that you can use to try out this approach.

Rational Method Composer - This enables you to manage, author, evolve, measure and deploy effective processes (SDLCs) tailored to your project needs. It is based on Eclipse. Rational Method Composer allows publishing to a web site so effectively covers the needs of both the SDLC Repository and SDLC Developer components.
IBM Business Process Manager - This is the latest name for IBM's combined development and runtime business process server. As well as a business process runtime, ESB and BPM repository it also includes design tools for building processes and services. The Process Designer allows business authors to build fully executable BPMN processes that include user interfaces for human interaction. The Integration Designer enables IT developers to develop services that easily plug into processes to provide integration and routing logic, data transformation and straight-through BPEL subprocesses. See this whitepaper for more information or click here for the IBM edition of the book BPM for Dummies. IBM Business Process Manager realises the components: Business Process Developer, IT Service Developer, Development Repository, Process Engine and Enterprise Service Bus.
WebSphere Service Registry and Repository - Catalogs,and organizes assets and services allowing customers to get a handleon what assets they have, making it easy to locate or distribute. Also enables policy management across the SOA lifecycle, spanning various domainsof policies including runtime policies as well as service governance policies. Included in the Advanced Lifecycle Edition is
Rational AssetManager which provides life cycle management capabilities to manage asset workflowfrom concept, development, build, deployment, and retirement as well as BuildForge integration. WebSphere Service Registry and Repository realises the Development Artfefacts Repository as well as the Runtime Services Repository.

So, there it is. An approach for developing services as well as an initial architecture allowing for the development and deployment of both business processes and services together with some actual products to get you started. Please feel free to comment here or in any of my links if you have anything you'd like to say.

A Service Based Development Process - Part 3

2011-07-12T22:12:00.001+01:00

In Part 2 I discussed how activities in a delivery process could be created from capability patterns that are comprised of tasks and/or activities. Capability patterns are reusable patterns which can be applied across a range of delivery processes. Capability patterns have input/output work products which together define the ‘contractual boundary’ to which performers of the capability pattern must conform. In this post I'll take a look at what these work products are and how they form part of a contract between capability patterns.

The table below shows the set of work products that are used in the process I have been describing.

Work Product	Description	Notation
Service Catalogue	Catalogue of all services owned or used by the enterprise. May be technical or business, legacy or new/to be provided. Usually implemented as a service registry.	WSDL
Service Certificate	Identifies a service that meets certain quality criteria.	Text
Service Portfolio Plan	Describes what services will be provided, when and by whom.	Text
Service Portfolio	Describes the entire collection of business services that an enterprise uses or plans to use.	Text
Service Model	Defines the complete hierarchy of business and technical services used or planned to be used by the enterprise. Can exist at a logical and physical level. Contains one or more Service Specifications.	UML
Service Specification	Defines a detailed specification for each service. Can exist at a logical and physical level.	Text/WSDL
Deployed Service	A service deployed in the service platform.	Jave, MQ etc
Deployed Service Environment	A deployed service platform.	N/A

This diagram shows the relationships (finish to finish dependencies) between the above work products.

Work Product Dependency Diagram

In this next diagram we can see how what I'm referring to as 'contractual boundaries' can be realised using these work products which are passed between two of the capability patterns I discussed last time.


Contractual Boundaries

Activities produce one or more work products which are consumed by other activities, either in the same capability pattern, or in a different one. This means that provided the input and output work products are agreed the capability patterns can run in parallel or, if needed, at different times. So, one capability pattern, the 'provide capability' one in the above example can contribute to the Service Model work product which another capability pattern, the 'manage service portfolio' one can contribute to at a later time if need be. Having a common set of agreed work products, which are shared in a repository, becomes the key to having an effective delivery process.

A Service Based Development Process - Part 2

2011-07-07T22:55:00.002+01:00

The basic Service Based Development Process I described previously described an end-to-end delivery process for creating services, whether these be cloud-based services or traditional ones running on a an enterprise service bus. The process consisted of a number of activities (where an activity groups together several tasks) as follows:

Business Modelling - Develop business process models to understand the business activities that need to take place. Probably a mix of as-is and to-be as well as manual and automated activities.
Solution Architecture and Design - Create the architecture for the solution, decides what services are to be used, what platform and delivery environment (public/private cloud, ESB etc) will be used.
Solution Assembly/Implementation - Assemble the services into an application and implement using the appropriate technology. Hopefully much of this will be done using tools that generate the appropriate process flows and pull in the right services.
Service Identification - Decide what new services need to be specified (i.e. not already in the Service Portfolio).
Service Specification - Specify services, their contracts (functional and service levels).
Existing Asset Analysis - What assets does the enterprise already have that could be service enabled (legacy code that could be wrappered etc).
Service Realisation - Decide what technology will be used to implement services.
Service Implementation - Implement services using the chosen technology.
Service Platform Design and Installation - Having decided the service runtime environment design and install it. For cloud-based services this means procuring the right cloud resources.
Service Operations and Management - Manage and run the service.
Service Portfolio Management - Ensure the Service Portfolio kept up to date.

In the example process we have seen so far each of these activities is composed together in such a way that a complete solution can be built out of a set of services that are deployed into a run-time environment. But that is not the only way these activities can be composed. A better way is to compose activities into capability patterns. Capability patterns are comprised of tasks and/or activities that can be composed into ‘higher-order’ capability patterns or delivery processes. They are reusable patterns which can applied across a range of delivery processes. Capability patterns have input/output work products which together define the ‘contractual boundary’ to which performers of the capability pattern must conform (more on this next time).

The delivery process described in part 1 is actually comprised of four capability patterns, each of which could be a process in its own right, or composed into different delivery processes. The four capability patterns are:

Provide Capability: Create a new or updated business process/capability based on user requirements. Uses existing services or specifies new ones where needed. Uses tasks mainly from the Consume discipline group.
Provide Service: Specify, design and build a new service according to business need. Certify, publish and deploy the service into the operational environment. Uses tasks mainly from the Provide discipline group.
Manage Service Portfolio: Create and maintain a service portfolio with an initial set of specified services. Ensure services are certified. Uses tasks from the Manage group.
Provide Environment: Design, build, test, install and run a new environment capable of running services. Uses tasks mainly from the Enable group.

Using the same diagrams as before here are the above four capability patterns laid out in terms of disciplines and phases from OpenUP.

Provide Capability

Provide Service

Manage Service Portfolio

Provide Environment

In the third part I'll look at the work products which together define the ‘contractual boundary’ to which performers of each of the capability patterns must conform.

The ideas in this blog were jointly developed with my ex-IBM colleague Bruce Anderson.

A Service Based Development Process - Part 1

2011-06-30T23:18:00.005+01:00

I have been toying around with this for quite a while. What prompted me to return to it was:

With the cloud hype curve reaching its peak I feel compelled to join in, in one of the ways I know best, method, process and architecture.
It allows me to further discuss the power of using an open, method framework based approach to building delivery processes in a plug-and-play kind of way.

I originally thought of calling this "A Cloud Service Based Development Process" however I think the word 'Cloud' is redundant. Whilst this process could be used for developing services "in the cloud" it is actually a generic process that can be used for developing services wherever they may actually be deployed. The process is based on three major components, all of which are in the public domain. All I'm doing is what architects are supposed to do, namely assemble components in new and interesting ways.

Service Based Disciplines (from the CBDI), see here.
The Open Unified Process (from the OMG's OpenUP), see here.
The concept of activities and capability patterns from the Software and Systems Process Engineering Metamodel (also from the OMG), see here.

The process emphasizes the organisational and contractual boundaries for a service-oriented enterprise (SOE) by a separation of concerns into a number of disciplines as follows:•

The service consumer and service provider are clearly separated as these require different skills and can be done by different teams.•
Enabling of SOA via the SO environment is a concern of its own (for example an ESB supports the implementation of services but does not affect their business content).•
Governance (manage) is integrated into everyday work. Example: negotiating the interface for a business service.

These disciplines (concerns) are shown below.

Process phases are from OpenUP and are:

Inception: Establish scope and define acceptance criteria. Identify key requirements, define candidate architecture and estimate the overall cost and schedule with detailed estimates for the elaboration phase. Identify risks and prepare the supporting environment.
Elaboration: Establish a baselined architecture, produce an evolutionary prototype of production-quality components, as well as possibly one or more exploratory, throw-away prototypes to mitigate specific risks. Demonstrate that the baselined architecture will support the requirements and establish the supporting environment.
Construction: Complete the analysis, design, development and testing of all required functionality. Iteratively and incrementally develop a complete product that is ready to transition to its user community. Establish that users are ready for the application to be deployed.
Transition: Perform user and acceptance testing to validate the new system against user expectations. Convert operational databases. Ensure users and maintainers and ready to use the system. Perform deployment-specific engineering such as cut-over, commercial packaging and production, sales roll-out, field personnel training. Achieve stakeholder concurrence that deployment baselines are complete and user self-supportability.

In the diagram below I show how the OpenUP phases combined with the previously mentioned disciplines can be overlayed with a deliver process for creating and deploying services.

The process is shown at the level of activities. An activity groups together one or more tasks and tasks deliver artefacts created by roles. I'll detail more what each of these activities consist of in the next blog.

The other aspect to this diagram is that of iterations. As I've mentioned elsewhere I believe the agile versus waterfall debate is essentially dead. We should deploy whatever processes make most sense for a particular project that can be accomplished in the most time efficient way possible. Using iterations usually makes sense so any process needs to allow for this as does this one. Each phase is iterative meaning that each iteration has elements of each discipline. You can view iterations as a wave which flows through the end-to-end process, early on the emphasis is on business modelling but also includes elements from the other disciplines whereas later on the emphasis shifts to operations and management even though the business process may still be being refined.

Like I say, next time I'll look at what each of the activities in this service based development process consists of and what artefacts they create.

Keeping Your Creative Mojo

2011-06-29T12:15:00.000+01:00

In this article Mary Beth Maziarz proposes nine ways to "screw up your creative mojo". Sometimes, despite our best efforts, we inevitably find ourselves in a bit of a creative cul-de-sac that we feel unable to get out of. At times like this, or just as a way of approaching our work from a new angle, it helps to try and bring some creative, right-brained, thinking to problem solving. Here's how Mary's creativity tips might apply to the world of architecture.

Collect the pieces when they come. Solutions to problems rarely arrive fully formed and on-demand. Sometimes solutions to problems arrive at inopportune times. We have enough digital devices at our disposal these days never to have the excuse of not capturing those thoughts as they occur whether it be in the middle of the night or when out walking the dog.
Stop talking and do it. Architects, especially it seems, are very good at talking around all aspects of a problem endlessly. Sometimes you just have to get on and do it. If you are not sure about something use prototypes or proofs of concept to help crystallize your ideas.
Decide the time is now. Architecture is all about compromise. The role of the architect is, as much as anything, about making decisions based on the best information available at the time. Don't prevaricate endlessly until you have the perfect solution, you never will!
Detach from critical thoughts and circles.You are your own worst critic, there are always many, many reasons for not doing something but usually only one for doing it. Do what you think is right and learn from your mistakes.
Find and believe in your strengths. Not thinking you are clever enough, educated enough or simply having the right level of authority in your organisation can sometimes prevent you from coming out with that great idea.This is about believing in yourself.
Focus your energies. This is about avoiding the distractions and trivia of everyday life (email, filling in that expense form, tweeting you're in the coffee shop etc) that prevent us from doing our art. Read Steven Presfield's War of Art (no, this is not written the wrong way round for all you business "warriors" who have read Sun Tzu's book).
Try anything. Architects tend to be more logical, left-brain thinkers. Reach out to your left-brain to unblock your thoughts and improve your creativity.
Enjoy the journey and your companions. Getting there is part of the fun. Work with others to make the journey more pleasant. Learn from your colleagues (both junior and senior to you) and let them learn from you. Work together, not against each other and reject the cynics and the ne'er-do-well's.
Be nice to yourself. It's increasingly difficult these days to justify that long lunchtime walk or afternoon away from the office as proper work. Enjoying yourself (as part of your work) helps those creative juices to flow though.

How to Avoid the Teflon Architecture Syndrome

2011-06-17T10:01:00.000+01:00

So you've sent all of your budding architects on TOGAF (or similar) training, hired in some expensive consultants in sharp suits to tell you how to "do architecture" and bought a pile of expensive software tools (no doubt from multiple vendors) for creating all those architecture models you've been told about but for some reason you're still not getting any better productivity or building the more reliable systems you were expecting from all this investment. You're still building siloed systems that don't inter-work, you're still misinterpreting stakeholder requests and every system you build seems to be "one-of-a-kind", you're not "leveraging reuse" and SOA seems to be last years acronym you never quite got the hang of. So what went wrong? Why isn't architecture "sticking" and why does it seem you have given yourselves a liberal coating of Teflon.

The plain fact of the matter is that all this investment will not make one jot of difference if you don't have a framework in place that allows the architects in your organisation to work together in a consistent and repeatable fashion. If it is to be effective the architecture organisation needs careful and regular sustenance. So, welcome to my architecture sustenance framework*.

Here's how it works, taking each of the above containers one at a time:

Common Language: Architects (as do any professionals) need to speak the same, common language. This needs to be the foundation for everything they do. Common languages can come from standards bodies (UML and SPEM are from the OMG, IEEE 1471-2000 is the architecture description standard from the IEEE) or may be ones your organisation has developed and is in your own glossary.
Community: Communities are where people come together to exchange ideas, share knowledge and create intellectual capital (IC) that can be shared more broadly in the organisation. Setting up an architecture Community of Practice (CoP) where your thought leaders can share ideas is vital to making architecture stick and become pervasive. Beware the Ivory Tower Antipattern however.
Tools: If communities are to be effective they need to use tools that allow them to create and share information (enterprise social networking tools, sometimes referred to as Enterprise 2.0). They also need tools that allow them to create and maintain delivery processes and manage intellectual capital of all types.
Processes: Anything but a completely trivial system will need some level of system development lifecycle (SDLC) that enables it creation and brings a level of ceremony that the project team should follow. An SDLC brings order to the chaos that would otherwise ensue if people working on the project do not know what role they are meant to perform, what work products they are meant to create or what tasks they are meant to do to create those work products. Ideally processes are defined by a community that understands, not only the rules of system development, but also what will, and what will not, work in the organisation. Processes should be published in a method repository so that everyone can easily access them.
Guidance: Guidance is what actually enables people to do their jobs. Whereas a process shows what to create when, guidance shows how to create that content. Guidance can take many forms but some of the most common is examples (how did someone else do it), templates (show me what I need to do so I don't start with a blank sheet every time) and guidelines (provide me with a step-by-step guide on how to perform my task) and tool mentors (how can I make use of a tool to perform this task and create my work product). Guidance should be published in the same (method) repository as the process so it is easy to jump between what I do as well as how I do it.
Projects: A project is the vehicle for actually getting work done. Projects follow a process, produce work products (using guidance) to deliver a system. Projects (i.e. the work products they produce) are also published in a repository though ideally this will separate from the generic method repository. Projects are "instances" of a delivery process which is configured in a particular way for that project. The project repository stores the artefacts from the project which serve as examples for others to use as they see fit.
Project and Method Repositories: The place where the SDLC and the output of multiple projects is kept. These should be well publicized as the place people know to go to to find out what to do as well as what others have done on other projects.

All of the above elements really do need to be in place to enable architecture (and architects) to grow and flourish in an organisation. Whilst these alone are not a guarantee of success without them your chances of creating an effective architecture team are greatly reduced.

*This framework was developed with my colleague at IBM, Ian Turton.

Is Designing an Architecture an Oxymoron?

2011-06-14T16:49:00.000+01:00

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.

The Legacy Issue

2011-05-31T20:13:00.000+01:00

Much of the work we do as architects involves dealing with the dreaded "legacy systems". Of course legacy actually means the last system built, not one that is necessarily 5, 10, 20 or more years old. As soon as a system goes into production it is basically "legacy". As soon as new features get added that legacy system gets harder to maintain and more difficult to understand; entropy (in the sense of an expression of disorder or randomness) sets in.

Apple have recently been in the news again for the wrong reasons because some of the latest iPod's do not work with previous versions of Mac OSX. Users have been complaining that they are being forced to to upgrade to the latest version of OSX in order to get their shiny new iPods to work. To make matters worse however Apple do support the relatively ancient version of Windows XP. Apple have always taken a fairly hard line when it comes to legacy by not supporting backwards compatibility particularly well when their OS gets upgraded. The upside is the operating systems does not suffer from the "OS bloat" that Windows seems to (the last version of OSX actually had a smaller footprint than the previous version).

As architects it is difficult to focus both on maintaining legacy systems and also figuring out how to replace them. As Seth Godin says:"Driving with your eyes on the rearview mirror is difficult indeed". At some point you need to figure out whether it is better to abandon the legacy system and replace it or soldier on supporting an ever harder to maintain system. There comes a point where the effort and cost in maintaining legacy is greater than that needed to replace the system entirely. I'm not aware of any formal methods that would help answer this particularly hard architectural decision but it's one I think any architect should try and answer before embarking on a risky upgrade program that involves updating existing systems.

Ethics and Architecture

2011-05-26T13:01:00.001+01:00

If you've not seen the BBC2 documentary All Watched Over By Machines of Loving Grace catch it now on the BBC iPlayer while you can (doesn't work outside the UK unfortunately). You can see a preview of the series (another two to go) on Adam Curtis' (the film maker) web site here. The basic premise of the first programme is as follows.

Back in the 50's a small group of people took up the ideas of the novelist Ayn Rand whose philosophy of Objectivism advocated reason as the only means of acquiring knowledge and rejecting all forms of faith and religion. They saw themselves as a prototype for a future society where everyone could follow their own selfish desires. One of the Rand 'disciples' was Alan Greenspan. Cut to the 1990's where several Silicon Valley entrepreneurs, also followers of Rand's philosophy, believed that the new computer networks would allow the creation of a society where everyone could follow their own desires without there being any anarchy. Alan Greenspan, now Chairman of the Federal Reserve, also became convinced that the computers were creating a new kind of stable capitalism and convinced President Bill Clinton of a radical approach to cut the United States huge deficit. He proposed that Clinton cut government spending and reduce interest rates letting the markets control the fate of the economy, the country and ultimately the world. Whilst this approach appeared to work in the short term, it set off a chain of events which, according to Curtis' hypothesis, led to 9/11, the Asian financial crash of 1997/98, the current economic crisis and the rise of China as a superpower that will soon surpass that of the United States. What happened was that the "blind faith" we put in the machines that were meant to serve us led us to a "dream world" where we trusted the machines to manage the markets for us but in fact they were operating in ways we could not understand resulting in outcomes we could never predict.

So what the heck has this got to do with architecture? Back in the mid-80's when I worked in Silicon Valley I remember reading an article in the San Jose Mercury News about a programmer who had left his job because he didn't like the applications that the software he'd been working on were being put to (something of a military nature I suspect). Quite a noble act you might think (though given where he worked I suspect the guy didn't have too much trouble finding another job pretty quickly). I wonder how many of us really think about what the uses of the software systems we are working on are being put to?

Clearly if you are working on the control software for a guided missile it's pretty clear cut what the application is going to be used for. However what about if you are creating some piece of generic middleware? Yes it could be put to good use in hospital information systems or food-aid distribution systems however the same software could be used for the ERP system of a tobacco company or in controlling surveillance systems that "watch over us with loving grace".

Any piece of software can be used for both good and evil and the developers of that software can hardly have it on their conscious to worry about what that end use will be. Just like nuclear power leads to both good (nuclear reactors, okay, okay I know that's debatable given what's just happened in Japan) and bad (bombs) it is the application of a particular technology that decides whether something is good or bad. However, here's the rub. As architects aren't we the ones who are meant to be deciding on how software components are put together to solve problems, for both better and for worse? Is it not within our remit to control those 'end uses' therefore and to walk away from those projects that will result in systems that are being built for bad rather than good purposes? We all have our own moral compass and it is up to us as individuals to decide which way we point our own compasses. From my point of view I would hope that I never got involved in systems that in anyway lead to an infringement of a persons basic human rights but how do I decide or know this? I doubt the people that built the systems that are the subject of the Adam Curtis films ever dreamed they would be used in ways which have almost led to the economic collapse of our society? I guess it is beholden on all of us to research and investigate as much as we can those systems we find ourselves working on and decide for ourselves whether we think we are creating machines that watch over us with "loving grace" or which are likely to have more sinister intents. As ever, Aurthur C. Clarke predicted this several decades ago and if you have not read his short story Dial F for Frankenstein now might be a good time to do so.

The Essence of Being an Architect

2011-05-19T15:43:00.000+01:00

There are many skills frameworks out there that tell us what skills we should have for 'doing architecture'. My company has (at least) one and I'm sure yours does as well. There are also organisations that specialise in creating such frameworks (check out the Skills Framework for the Information Age for example). Whilst there are some very specific skills that software architects need (developing applications using xyz programming language, building systems using a particular ERP package and so on) which come and go as technology evolves there are some enduring skills which I believe all architects must acquire as they progress in their careers. What I refer to as being the essence of being an architect. Seth Godin recently posted a blog entry called What's high school for? where he listed 10 things all schools should be teaching that should sit above any of the usual stuff kids get taught (maths, chemistry, history etc). A sort of list of meta-skills if you like. Borrowing from, and extending, this list gives me my list of essential architect skills.

How to focus intently on a problem until it's solved. There is much talk these days about how the internet, the TV networks and the print media are leading to a dumbed down society in which we have an inability to focus on anything for longer than 30 minutes. Today's business problems are increasingly complex and often require prolonged periods of time to really focus on what the problem is before charging in with a (software) solution. Unfortunately the temptation is always often to provide the cheapest or the quickest to market solution. You need to fight against these pressures and stay focused on the problem until it is solved.
How to read critically. As architects we cannot hope to understand everything there is to know about every software product, technology or technique that is out there. Often we need to rely on what vendors tell us about their products. Clearly there is a danger here that they tell us what we, or our clients, want to hear glossing over faults or features that are more 'marketechture' than archihtecture. Learn how to read vendor product descriptions and whitepapers with a critical eye and ask difficult questions.
The power of being able to lead groups of peers without receiving clear delegated authority. The role of an architect is to build solutions by assembling components in new and interesting ways. You are the person who needs to both understand what the business wants and how to translate those 'wants' into technology. Business people, by and large, cannot tell you how to do that. You need to lead your peers (both business people and technologists) to arrive at an effective solution.
How to persuasively present ideas in multiple forms, especially in writing and before a group. Obvious really, you can have the greatest idea in the world but if you cannot present it properly and effectively it will just stay that, an idea.
Project management, self-management and the management of ideas, projects and people. How to manage your and others time to stay focused and deliver what the client wants in a timely fashion.
An insatiable desire (and the ability) to learn more. Forever! This job cannot be done without continuous learning and acquiring of knowledge. Everyone has their own learning style and preferences for how they acquire knwledge, find out what your style is and deploy it regularly. Don't stick to IT, I've discussed the role of the versatilist extensively (see here for example). Be 'V' shaped not 'T' shaped.
The self-reliance that comes from understanding that relentless hard work can be applied to solve problems worth solving. Belief in ones ideas and the ability to deploy them when all around you are doubting you is probably one of the hardest skills to acquire. There is a fine balance between arrogance and self-belief. In my experience this is not an easily repeatable skill. Sometimes you will be wrong!
Know how to focus on what is important and to ignore what is not. If you have not heard of Parkinson's Law of Triviality take a look at it.
Know who the real client is and focus on satisfying him/her/them. There can be lots of distractions in our working lives, and I'm not just talking about twittering, blogging (sic) and the rest of the social networking gamut. Projects can sometimes become too inward focused and lose track of what they are meant to be delivering. We live in a world where numbers have achieved ascendency over purpose. We can sometimes spend too much time measuring, reviewing and meeting targets rather than actually doing. I love this quote from Deming: "If you give a manager a numerical target, he’ll make it, even if he has to destroy the company in the process". There is little merit in a well executed project that no one wants the output from.
Use software/system delivery lifecycle (SDLC) processes wisely. SDLC's are meant to be enablers but can end up being disablers! Always customise an SDLC to fit the project not the other way around.

If all of this seems hard work that's because it is. As Steven Pressfield says in his book The War of Art: "The essence of professionalism is the focus upon the work and its demands, while we are doing it, to the exclusion of all else".

Sketching with the UML

2011-05-13T18:18:00.002+01:00

In his book UML Distilled – A Brief Guide to the Standard Object Modeling Language Martin Fowler describes three ways he sees UML being used:

UML as sketch: Developers use UML to communicate some aspect of a system. These sketches can be used in both forward (i.e. devising new systems) as well as reverse (i.e. understanding existing systems) engineering. Sketches are used to selectively talk about those parts of the system of interest. Not all of the system is sketched. Sketches are drawn using lightweight drawing tools (e.g. whiteboards and marker pens) in sessions lasting anything from a few minutes to a few hours. The notation and adherence to standards is non-strict. Sketching works best in a collaborative environment. Sketches are explorative.
UML as a blueprint: In forward engineering the idea is that developers create a blueprint that can be taken and built from (possibly with some more detailed design first). Blueprints are about completeness. The design/architecture should be sufficiently complete that all of the key design decisions have been made leaving as little to chance as possible, In reverse engineering blueprints aim to convey detailed information about the system, sometimes graphically. Blue prints require more sophisticated modelling tools rather than drawing tools. Blueprints are definitive.
UML as a programming language: Here developers draw UML diagrams that are compiled down to executable code. This mode requires the most sophisticated tooling of all. The idea of forward and reverse engineering does not exist because the model is the code. Model Driven Architecture (MDA) fits this space.

In practice there is a spectrum of uses of UML which I've shown below in Figure 1. In my experience very few organisations are up at level 10 and I would say most are in the range 3 - 5. I would classify these as being those folk who use UML tools to capture key parts of the system (either in a forward or reverse engineering way) and export these pictures into documents which are then reviewed and signed-off.

Figure 1

An interesting addition to the 'UML as sketch' concept is that at least two vendors that I know of (IBM and Sparx) are offering 'sketching' capabilities within their modeling tools. In Rational Software Architect the elements in a sketch include shapes such as rectangles, circles, cylinders, stick figures that represent people, and text labels. Checkout this YouTube video for a demo. Unlike other types of models, sketches have only a few types of elements and only one type of relationship between elements. Also, sketches do not contain multiple diagrams; each sketch is an independent diagram. You can however move from a sketch to a more formal UML diagram or create a sketch out of an existing UML diagram so allowing you to work with a diagram in a more abstract way.

Below in Figure 2 is an example of a sketch for my example Hotel Management System, that I've used a few times now to illustrate some architectural concepts, drawn using the current version of Rational Software Architect. I guess you might call this an Architecture Overview used to show the main system actors and architectural elements.

Figure 2

I guess the ability to be able to sketch with modeling tools could be a bit of a double edged sword. On the one hand it means sketches are at least captured in a formal modeling environment which means they can be kept in one centrailsed repository and can be maintained more effectively. It also means they can potentially be turned into more formal diagrams thus providing a relatively automated way of moving along the scale shown in Figure 1. The downside might be that sketching is as far as people go and never bother to provide anything more formal. I guess only time will tell whether this kind of capability gains much traction amongst developers and architects alike. For my part I would like to see sketching in this way as a formal part of a process which encourages architects and developers to create models using this approach, get them roughly right and then turn them ino a more formal and detailed model.

Change Cases and the Limits of Testing

2011-05-10T07:25:00.000+01:00

This recent blog entry from Seth Godin on "the culture of testing" set me thinking about software architecture and testing. Is it possible to 'over test' applications or systems? Is there a point at which you need to stop testing and let your software 'go free' so users can 'complete' testing themselves? Let's be clear here:

Software needs testing very rigorously. No one wants to fly on an airplane where the on-board flight control software has not been fully tested.
I'm also not talking about the well established practice of releasing beta versions of software where you get together a bunch of early adopters to complete testing for you and iron out the "last few bugs".
Testing software against known requirements is most definitely a good thing to do and I'm not advocating just running your system tests against a subset of those functional and non-functional requirements.

Where it gets interesting is when you don't overly constrain the architecture so that it allows users to take resulting application or system and evolve it (test it) in new and interesting ways. When defining an architecture we usually talk about it having to address functional as well as non-functional requirements but there is a third, often overlooked, class of requirement referred to as change cases or future requirements. Change cases are used to describe new potential requirements for a system or modifications to existing requirements. Change cases usually come from the specifier of the system (e.g. "in three years time we want introduce a loyalty scheme for our regular guests"). Some change cases however are not envisaged in advance and it's only when users of the application get hold of it that they explore and find new ways of using the application that may not have originally been thought of. Such applications need to be carefully architected, and tested, such that these change cases can be discovered without, of course, breaking the application altogether.

So, by all means ship systems or application that do what they say on the tin but also lets users do other, possibly more interesting things, with them that may lead to new and innovative uses that the original specifiers of the software had not thought about.

Architectural Granularity

2011-04-27T22:21:00.001+01:00

There's an old joke about defining granularity:

Granularity is a bit like pornography, it's hard to define but you know it when you see it.

The whole topic of granularity of software components is important to the Software Architect for a number of reasons:

If you are creating too many fine-grained components then you are probably not doing architecture but design.
As I discussed previously, getting components at the right level of granularity is important when it comes to placing those components (on nodes) and satisfying non-functional requirements such as availability and performance.
The granularity of components impacts performance. Too many fine-grained components will probably result in increased traffic on the network because the client using the component must make several queries to complete a task or get the information it needs.
Generally speaking, the coarser grained a component the more likely it is to have a direct correlation to something the business finds useful (e.g. a 'Reservation' component that handles all aspects of allowing a customer to reserve a room is more useful than one that 'finds a vacant room').

The terms “fine-grained”, “medium-grained” and “coarse-grained” are frequently used to describe architectural components (or indeed services) but there seems to be no common definition for these terms. This leads to confusion and ambiguity in their use. Whilst there is no agreed definition of what these terms mean there does seem to be a consensus that granularity is about more than just the number of operations an interface on a component has. Everware-CBDI (see their June 2005 edition which is only available via subscription) suggests that other factors might be (and I'm simplifying here):

The number of components (C) in the directed-acyclic-graph (DAG) that are invoked through a given operation on that components interface.
The function points (F) for each component.
The number of database tables (D) created, read, updated or deleted.

So one measure of granularity (G) might be:

G = C + F + D

Put simply, if a component is self-contained (C = 1), has a single function point (F = 1) and updates a single entry in a database (D = 1) it will have a granularity of '3'. Such a 'component' is going to be something like a class 'Integer' with a single operation such as 'increment' which adds one to the previous value. Whilst such a component may be infinitely reusable it is not particularly useful from an architectural (or business) standpoint. We could honestly call such a component 'fine-grained'. At the other extreme a CRM system will probably have C, F and D each equal to several thousand giving it a granularity in the tens of thousands. Again, from an architectural standpoint, this is not very useful. There is not much we can do with such a 'component' other than observe it is (very) coarse-grained. I suggest that we architects are more likely to be interested in creating, and (re)using components that sit somewhere in between these extremes (maybe in the low 100's region using this measure of granularity).

What we are actually talking about here is what ZapThink refer to as 'functional granularity' (as opposed to 'interface granularity') that is, granularity of the component itself rather than the granularity of any interfaces the component may expose. For the architect it is getting this functional granularity right that is most important. The coarser the (functional) granularity of the component the more likely it is to have a useful business context. So a 'Reservation' component that deals with all aspects of reserving a room for a customer (i.e. takes the dates, room preferences, hotel location, customer loyalty status etc) and finds a sutable room is a useful component at both an architectural level (i.e it addresses the points I started with above) as well as a business level (i.e. it is understandable by the business and can therefore be mapped to business users requirements).

When composing systems into components working out what level of granularity you need is a key aspect of creating the systems architecture so you have the right number of components that are most useful in both an architectural as well as business context.

EA Wars

2011-04-20T19:38:00.000+01:00

Lots of great discussion in the blogosphere right now on the relevance of Enterprise Architecture in the brave new world of the 'extended' enterprise and whether architecture is something that is planned or 'emerges'. This is largely prompted, I suspect, by the good folk at ZapThink asking Why Nobody is Doing Enterprise Architecture (possibly to plant seeds of doubt in the minds of CIOs and send them rushing to one of their "licensed ZapThink architecture courses"). For a nice, succinct and totally dismissive riposte to the ZapThink article check out David Sprott's blog entry here. For a more reasoned and skeptical discussion on whether emergent architecture actually exists (I think it does, see below) read Richard Veryard's blog entry here.

However... despite some real FUD'iness on the part of ZapThink there are some elements in their argument that definitely ring true and which I have observed in a number of clients I have worked with over the last few years. In particular:

Emergence (i.e. "the way complex systems and patterns arise out of a multiplicity of relatively simple interactions") is, like it or not, a definite factor in the architecture of modern-day enterprises. This is especially true when the human dimension is factored into the mix. The current Gen Y and upcoming Gen V are not going to hang around while the EA department figure out how to factor their 10th generation iPhone, which offers 3-D holographic body-time, into an EA blueprint. They are just going to bypass the current systems and use it regardless. The enterprise had better quickly figure out the implications of such devices (whatever they turn out to be) or risk becoming a technological backwater.
EA departments seem to very quickly become disjoint from both the business which they should be serving and the technicians which they should be governing. One is definitely tempted to ask "who is governing the governors" when it comes to the EA department? Accountability in many organisations definitely seems to be lacking. This feels to me like another example of gapology that seems to be increasingly apparent in such organisations.
Even though we are better placed than ever to be able to capture good methodological approaches to systems development I still see precious little adoption of true systems development lifecycles (SDLC's) in organisations. Admittedly methods have had very bad press over the years as they are often seen as been an unnecessary overhead which, with the rise of agile, have been pushed into the background as something an organisation must have in order to be ISO 9000 compliant or whatever but everyone really just gets on with it and ignores all that stuff.
Finally, as with many things in IT, the situation has been confused by having multiple and overlapping standards and frameworks in the EA space (TOGAF, Zachman and MODAF to name but three). Whilst none of these may be perfect I think the important thing is to go with one and adapt it accordingly to what works for your organisation. What we should not be doing is inventing more frameworks (and standards bodies to promote them). As with developing an EA itself the approach an EA department should take to selecting an EA framework is to start small and grow on an as needs basis.

Applying Architectural Tactics

2011-04-15T12:28:00.001+01:00

The use of architectural tactics, as proposed by the Software Engineering Institute, provides a systematic way of dealing with a systems non-functional requirements (sometime referred to as the systems quality attributes or just qualities). These can be both runtime qualities such as performance, availability and security as well as non-runtime such as maintainability, portability and so on. In my experience, dealing with both functional and non-functional requirements, as well as capturing them using a suitable modeling tool is something that is not always handled very methodically. Here's an approach that tries to enforce some architectural rigour using the Unified Modeling Language (UML) and any UML compliant modeling tool.

Architecturally, systems can be decomposed from an enterprise or system-wide view (i.e. meaning people, processes, data and IT systems), to an IT system view to a component view and finally to a sub-component view as shown going clock-wise in Figure 1. These diagrams show how an example hotel management system (something I've used before to illustrate some architectural principles) might eventually be decomposed into components and sub-components.

Figure 1: System Decomposition

This decomposition typically happens by considering what functionality needs to be associated with each of the system elements at different levels of decomposition. So, as shown in Figure 1 above, first we associate ‘large-grained’ functionality (e.g. we need a hotel system) at the system level and gradually break this down to finer and finer grained levels until we have attributed all functionality across all components (e.g. we need a user interface component that handles the customer management aspects of the system).

Crucially from the point of view of deployment of components we need to have decomposed the system to at least that of the sub-component level in Figure 1 so that we have a clear idea of each of the types of component (i.e. do they handle user input or manage data etc) and know how they collaborate with each other in satisfying use cases. There are a number of patterns which can be adopted for doing this. For example the model-view-controller pattern as shown in Figure 2 is a way of ascribing functionality to components in a standard way using rules for how these components collaborate. This pattern has been used for the sub-component view of Figure 1.

Figure 2: Model-View-Controller Pattern

So far we have shown how to decompose a system based on functional requirements and thinking about which components will realise those requirements. What about non-functional requirements though? Table 1 shows how non-functional requirements can be decomposed and assigned to architectural elements as they are identified. Initially non-functional requirements are stated at the whole system level but as we decompose into finer-grained architectural elements (AKA components) we can begin to think about how those elements support particular non-functional requirements also. In this way non-functional requirements get decomposed and associated with each level of system functionality. Non-functional requirements would ideally be assigned as attributes to each relevant component (preferably inside our chosen UML modelling tool) so they do not get lost or forgotten.

Table 1
System Element	Non-Functional Requirement
Hotel System (i.e. including all actors and IT systems).	The hotel system must allow customers to check-in 24 hours a day, 365 days a year. Note this is typically the accuracy non-functional requirements are stated at initially. Further analysis is usually needed to provide measurable values.
Hotel Management System (i.e. the hotel IT system).	The hotel management system must allow the front-desk clerk to check-in a customer 24 hours a day, 365 days a year with a 99.99% availability value.
Customer Manager (i.e. a system element within the hotel’s IT system).	The customer manager system element (component) must allow customer details to be created, read or updated (but not deleted) 24 hours a day, 365 days a year with a 99.99% availability value.
Customer Manager Interface (i.e. the user interface that belongs to the Customer Manager system element).	The customer manager interface must allow customer details to be created, read or updated (but not deleted) 24 hours a day, 365 days a year with a 99.99% availability value.

Once it is understood what non-functional requirement each component needs to support we can apply the approach of architectural tactics proposed by the Software Engineering Institute (SEI) to determine how to handle those non-functional requirements.

An architectural tactic represents “codified knowledge” on how to satisfy non-functional requirements by applying one or more patterns or reasoning frameworks (for example queuing or scheduling theory) to the architecture. Tactics show how (the parameters of) a non-functional requirement (e.g. the required response time or availability) can be addressed through architectural decisions to achieve the desired capability.

In the example we are focusing on in Table 1 we need some tactics that allow the desired quality attribute of 99.99% availability (which corresponds to a downtime of 52 min, 34 sec per year) to be achieved by the customer manager interface. A detailed set of availability tactics can be found here but for the purposes of this example availability tactics can be categorized according to whether they address fault detection, recovery, or prevention. Here are some potential tactics for these:

Employing good software engineering practices for fault prevention such as code inspections, usability testing and so on to the design and implementation of the interface.
Deploying components on highly-available platforms which employ fault detection and recovery approaches such as system monitoring, active failover etc.
Developing a backup and recovery approach that allows the platform running the user interface to be replaced within the target availability times.

As this example shows, not all non-functional requirements can be realised suitably by a component alone; sometimes full-realisation can only be done when that component is placed (deployed) onto a suitable computer platform. Once we know what non-functional requirements need to be realised by what components we can then think about how to package these components together to be deployed onto the appropriate computer platform which supports those non-functional requirements (for example on a platform that will support 99.99% availability and so on). Figure 3 shows how this deployment can be modelled in UML adopting the Hot Standby Load Balancer pattern.

Figure 3: Deployment View

Here we have taken one component, the ‘Customer Manager’, and showed how it would be deployed with other components (a ‘Room Manager' and a ‘Reservation Manager'’) that support the same non-functional requirements onto two application server nodes. A third UML element, an artefact, packages together like components via a UML «manifest» relationship. It is the artefact that actually gets placed onto the nodes. An artefact is a standard UML element that “embodies or manifests a number of model elements. The artefact owns the manifestations, each representing the utilization of a packageable element”.

So far all of this has been done at a logical level; that is there is no mention of technology. However moving from a logical level to a physical (technology dependent level) is a relatively simple step. The packaging notion of an artefact can equally be used for packaging physical components, for example in this case the three components shown in Figure 3 above could Enterprise Java components or .NET components.

This is a simple example to illustrate three main points:

Architecting a system based on functional and non-functional requirements.
Use of a standard notation (i.e. UML) and modelling tool.
Adoption of tactics and patterns to show how a systems qualities can be achieved.

None of it rocket science but something you don't see done much.

Oops There Goes Our Reputation

2011-04-13T11:15:00.000+01:00

I'm guessing that up to two weeks ago most people, like me, had never heard of a company called Epsilon. Now, unfortunately for them, too many people know of them for all the wrong reasons. If you sign up to any services from household names such as Marks and Spencer, Hilton, Marriott or McKinsey you will have probably had several emails in the last two weeks advising you of a security breach which led to "unauthorized entry into Epsilon's email system". Unfortunately because Epsilon is a marketing vendor that manages customer email lists for these and other well known household brands chances are your email has been obtained by this unauthorised entry as well. Now, it just might be a pure coincidence, but in the last two weeks I have also received emails from the Chinese government inviting me to a conference on some topic I've never heard of, from Kofi Annan, ex-Secretary General of the United Nations and from a lady in Nigeria asking for my bank account details so she can deposit $18.4M into the account so she can leave the country!

According to the information on Epsilon's web site the information that was obtained was limited to email addresses and/or customer names only. So, should we be worried by this and what are the implications on architecture of such systems?

I think we should be worried for at least three reasons:

Whilst the increased spam that is seemingly inevitable following an incident such as this is mildly annoying a deeper concern is how could the criminal elements who now have information on the places I do business on the web put this information together to learn more about me and possibly construct a more sophisticated phishing attack? Unfortunately it's not only the good guys that have access to data analytics tools.
Many people probably have a single password to access multiple web sites. The criminals who now have your email as well as knowledge of which sites you do business at only have to crack one of these and potentially have access to multiple sites, some of which may have more sensitive information.
Finally how come information I trusted to well known (and by implication 'secure') brands and their web sites has been handed over to a third party without me even knowing about it? Can I trust those companies not to be doing this with more sensitive information and should I be withdrawing my business from them?. This is a serious breach of trust and I suspect that many of these brands own reputations will have been damaged.

So what are the impacts to us as IT architects in a case like this? Here are a few:

As IT architects we make architectural decisions all the time. Some of these are relatively trivial (I'll assign that function to that component etc) whereas others are not. Clearly decisions about which part of the system to entrust personal information to is not trivial. I always advocate documenting significant architectural decisions in a formal way where all the options you considered are captured as well as the rationale and implications behind the decision you made. As our systems get ever more complex and distributed the implications of particular decisions become harder to quantify. I wonder how many architects consider the implications to a companies reputation of entrusting even seemingly low grade personal information to third parties?
It is very likely that incidents such as this are going to result in increased legislation that covers personal information just like there is legislation on Payment Card Industry (PCI) standards. This will demand more architectural rigour as new standards essentially impose new constraints on how we design our systems.
As we trundle slowly to a world where more and more of our data is to be held in the cloud using a so called multi-tenant deployment model it's surely only a matter of time before unauthorised access to one of our cloud data stores will result in access to many other data sources and a wealth of our personal information. What is needed here is new thinking around patterns of layered security that are tried and tested and, crucially, which can be 'sold' to consumers of these new services so they can be reassured that their data is secure. As Software-as-a-Service (SaaS) takes off and new providers join the market we will increasingly need to be reassured they are to be trusted with our personal data. After all if we cannot trust existing, large corporations how can we be expected to trust new, small startups?
Finally I suspect that it is only a matter of time before legislation aimed at systems designers themselves is enforced that make us as IT architects liable for some of those architectural decisions I mentioned earlier. I imagine there are several lawyers engaged by the parties whose customers email addresses were obtained and whose trust and reputation with those customers may now be compromised. I wonder if some of those lawyers will be thinking about the design of such systems in the first place and, by implication, the people who designed those systems?

Open vs. Closed Architectures

2011-04-05T20:12:00.000+01:00

There has been much Apple bashing in cyberspace as well as the 'dead-wood' parts of the press of late. To the extent that some people are now turning on those that own one of Apple's wunder-devices (an iPad) accusing them of being "selfish elites". Phew! I thought it was a typically British trait to knock anything and anyone that was remotely successful but it now seems that the whole world has it in for Mr Jobs' empire.

Back in the pre-google days of 1994 Umberto Eco declared that "the Macintosh is Catholic and that DOS is Protestant. Indeed, the Macintosh is counter-reformist and has been influenced by the ratio studiorum of the Jesuits. It is cheerful, friendly, conciliatory; it tells the faithful how they must proceed step by step to reach -- if not the kingdom of Heaven -- the moment in which their document is printed."

The big gripe most people have with Apple is their closed architecture which controls not only who is allowed to write apps for their OS's but who can produce devices that actually run those OS's (er, that would be Apple). It's one of life's great anomalies as to why Apple is so successful in building products with closed architectures when most everyone would agree that open architectures and systems are ultimately the way to go as, in the end, they lead to greater innovation, wider-usage and, presumably, more profit for those involved. The classic case of an open architecture leading to wide-spread usage is that of the original IBM Personal Computer. Because IBM wanted to fast-track its introduction many of the parts were, unusually for IBM, provided by third-parties including, most significantly the processor (from Intel) and the operating system (from the fledgling Microsoft). This together with the fact that the technical information on the innards of the computer were made publicly available essentially made the IBM PC 'open'. This more than anything gave it an unprecedented penetration into the marketplace allowing many vendors to provide IBM PC 'clones'.

There is of course a 'dark side' to all of this. Thousands of vendors all providing hardware add-ons and extensions as well as applications resulted in huge inter-working problems which in the early days at least required you to be something of a computer engineer if you wanted to get everything working together. This is where Apple stepped in. As Umberto Eco said, Apple guides the faithful every step of the way. What they sacrifice in openness and choice they gain in everything working out the box, sometimes in three simple steps.

So, is open always best when it comes to architecture or does it sometimes pay to have a closed architecture? What does the architect do when faced with such a choice? Here's my take:

Know your audience. The early PC's, like it or not were bought by technophiles who enjoyed technology for the sake of technology. The early Mac's were bought by people who just wanted to use computers to get the job done. In those days both had a market.
Know where you want to go. Apple stuck solidly with creating user friendly (not to mention well designed devices) that people would want to own and use. The plethora of PC providers (which there soon were) couldn't by and large give a damn about design. They just wanted to sell as many devices as possible and let others worry about how to stitch everything together. This in itself generated a huge industry which in a strange self-fulfilling way led to more devices and world domination of the PC and left Apple in a niche market. Openness certainly seemed to be paying.
Know how to capitalise on your architectural philosopy. Ultimately openness leads to commoditization. When anyone can do it price dominates and the cheapest always wins. If you own the space then you control the price. Apple's recent success has been not to capitalise on an open architecture but to capitalise on good design which has enabled it to create high value, desirable products showing that good design trounces an open architecture.

So how about combining the utility of an open architecture with the significance of a well thought through architecture to create a great design? Which funnily enough is what Dan Pink meant by this:

Significance + Utility = Design

Huh, beaten to a good idea again!

It's Only Television But I Like It

2011-03-31T13:34:00.001+01:00

Yes I know it's a television program and yes I know they are playing up to the camera and yes I know we only see the 'edited highlights' but Jamie's Dream School on Channel 4 last night was an exemplar on how to deliver motivational talks to a disinterested audience. As I discussed last time the 'teachers' (actually people at the leading edge in their field) are truly inspirational, passionate individuals who use every trick in the book to engage with and inspire their students. Not only that they are incredibly humble, as typified by one of the pupils asking Robert Winston if he "had ever cured anything" to which he replied he "thought they had helped with some advances, yes". As well as all this inspirational and motivational teaching you will see there is not a single PowerPoint slide in sight. It's all about naked presenting (well, apart from the odd prop or two) and story telling.

I've recently been reading Nancy Duarte's book Resonate which looks at how storytelling as done by great writers and film-makers can be used by presenters to really engage with their audience. If you want a book that helps you with presentations that is something other than the boring 'how to' guides on structuring PowerPoint presentations then it's definitely worth a read.

So what's this got to do with IT architecture? Nothing and everything! At one level architecture is just a pile of models and diagrams describing ways for solving business problems. However architecture also needs to be 'bought alive' if the ideas it encompasses are to be explained and the costs of implementing it justified to non-technical people. Explaining and presenting architecture is probably one of the most important aspects of the architects role and communication skills should definitely be up their as one of the key competencies possessed by architects. Without these architectures will just remain a bunch of ideas gathering virtual dust in a modeling tool.

On Lego, Granularity, Jamie Oliver and Architecture

2011-03-22T21:28:00.000Z

There's a TV program running here in the UK called Jamie's Dream School where the chef, entrepreneur, restaurateur and Sainsbury's promoter Jamie Oliver brings together some of Britain's most inspirational individuals (Robert Winston, Simon Callow, Rankin and Rolf Harris to name but four) to see if they can persuade 20 young people who've left school with little to show for the experience to give education a second chance. The central theme seems to be one of hands-on student involvement and live demos, the more outrageous the better. The highlight so far being Robert Winston hacking away at rats and pigs with scalpels and a circular saw resulting in several students vomiting in the playground.

This set me thinking about how best to demonstrate software architecture to a bunch of students of a similar age to those in the Jamie Oliver program for a talk I gave at a UK university last week. Much has been written about the analogy between LEGO (R) and services (see this article from Zapthink and another from ZDNet for example). Okay it may not be quite as imaginative as pig carcasses being hacked about but LEGO was the best I had at hand! Here's how the demo works:

First I give them my favourite defnition of architecture, namely: Architects take existing components and assemble them in interesting and important ways. (Seth Godin).
Then I invite an unsuspecting candidate to come and assemble the body (importantly excluding the wheels) of a car out of LEGO (actually Duplo as its bigger) making a big thing of tipping a bag of bricks out onto the table. This they usually do without too much hassle, the key learning point being that they have created an "interesting" construct out of "existing components".
I then ask them to add some wheels and tip out a bag of K'NEX (R). As I'm sure even non-parents know K'NEX and LEGO are essentially different "systems" and the two don't (easily) connect to each other. This usually ends up in bemused looks and a good deal of fiddling around with wheels and bricks trying to figure out how to make the two systems connect to each other.

Depending on how much time and energy you have as well as the attention span of the students there are lots of great learning points to be made here. In order of increasing depth these are:

LEGO (components) have a well defined interface and can easily be assembled in lots of interesting ways.
K'NEX is a different system and has been designed with a different interface. K'NEX and LEGO were not designed to work with each other. One of the jobs of an architect is to watch out for incompatible interfaces and figure out ways of making them work with each other. This is possibly done using a third party product e.g Sellotape (R). I guess an extension to this demo could be a roll of this.
It may be in the component providers interest to use different interfaces as it results in vendor lock-in which means you have to keep going back to that vendor for more components,
Granularity (i.e. in the case of LEGO the number of "nobbles") is important. Small bricks (few nobbles, fine-grained) may be very reusable but you need lots and lots of them to do anything interesting. Conversely LEGO have now taken to quite specialized pieces (not "bricks" any more but large-grained pieces) that perform one function well (the LEGO rocket for example) but cannot be reused so easily. The optimum for re-usability is somewhere in-between these two.
LEGO may be aimed at children who, with relatively little expertise or training, may be able to assemble interesting things but they are not about to build LEGOland. For that you need an architect!
Finally, if you are feeling really mean, disassemble the lovingly built construction of your student then ask her to re-build it in exactly the same way. Chances are that even for a relatively simple system they won't be able to. What might have helped was some type of document that described what they had done.

I'm sure there are other interesting analogies to be drawn but I'll finish by saying that this is not quite as trivial as it sounds. Not only was this a good learning exercise for my students I happen to know a client who is using building blocks like LEGO to help their architects architect systems. The key thing it helps demonstrate is the importance of collaboration in assembling such systems.

Skills for Building a Smarter Planet

2011-03-17T20:56:00.000Z

This is the transcript of a talk I gave to a group of sixth formers, who are considering a career in IT, at a UK university this week. The theme was "What do IT architects do all day" however I expanded it into "What will IT architects be doing in the future?".

What I want to do in the next 30 minutes or so is not only tell you what I, as an IT architect, do but what I think you will be doing should you choose to take up a career as an IT architect and what skills you wil need to do the job. In particular I'd like to explain what I mean by this:

Today's world is full of wicked problems. Solving these problems, and building a smarter planet needs new skills. I believe that IT architects need to be a versatile and adaptive breed of systems thinkers.

Here's the best explanation I've seen of what architects do:

Architects take existing components and assemble them in interesting and important ways. (Seth Godin)

As an example of this consider something that we use everyday, the (world-wide) web. Invented by Tim Berners-Lee just 20 short years ago, Tim basically assembled the web from three components that already existed: hypertext, internet protocols and what are referred to as markup languages. All these things existed, what Tim did was to assemble them in an "interesting" way. So what I do is to use IT to try and solve interesting and important business problems by assembling (software) components. I'm not just interested in any problems though, the type of problems that interest me are the "wicked" variety. What do I mean by these?

Wicked problems are ones that you often don't really understand until you've formulated a solution to it. It's often not even possible to really state what the problem is and because there is no clear statement of the problem, there can be no clear solution so you never actually know when you are finished. For wicked problems 'finished' usually means you have run out of time, money, patience or all three! Further, solutions to wicked problems are not "right" or "wrong". Wicked problems tend to have solutions which are 'better', or maybe 'worse' or just 'good enough'. Finally, every wicked problem is essentially novel and unique. Because there are usually so many factors involved in a wicked problem no two problems are ever the same and each solution needs a unique approach.

But there's a problem! Here's a headline from last year Independent newspaper: "Labour's computer blunders cost £26bn". What's going on here? This is your and my money being wasted on failed IT projects. And it's not just government projects that are failing. Here's an estimate from the British Computer Society of how many IT projects re actually successful. 20%! How poor is that? It projects 'fail' for many reasons but interstingly it's rarely for just technical reasons. More often than not it's due to poor project and risk management, lack of effective stakeholder management or no clear senior management ownership. So we have a real problem here. As we'll see in a minute, problems are not only getting harder to fix (more 'wicked') but our ability to solve them does not seem to be improving!!

So what are these wicked problems I keep talking about? They are many and numerous but many of them are attributable to inefficiencies that exist in the "systems" that exist in the world. Economists estimate that globally we waste $15 trillion of the worlds precious resources each year. Much – if not most – of this inefficiency can be attributed to the fact that we have optimized the way the world works within silos, with little regard for how the processes and systems that drive our planet interrelate. These complex, systemic inefficiencies are interwoven in the interactions among our planet’s core systems. No business, government or institution can solve these issues in isolation. To root out inefficiencies and reclaim a substantial portion of that which is lost, businesses, industries, governments and cities will need to think in terms of systems, or more accurately, a system of systems approach. This means we will need to collaborate at unprecedented levels. For example no single organization owns the world’s food system, and no single entity can fix the world’s healthcare system. Success will depend upon understanding the full set of cause-and-effect relationships that link systems and using this knowledge to create greater synergy. Basically many of the problems the world faces today are cause by the fact that our systems don't talk to each other. What do I mean by this? Here's a simple example to illustrate the point.

Imagine you are driving your car around town trying to find a parking space. You can be sure that somewhere in town there's a parking meter looking for a car to park in it. How do we marry your car with that parking meter? Actually the technology to do this pretty much exists already. However the challenge of actually fixing this problem stretches beyond just technology. A solution to this problem includes at least: intelligent sensors, communications, public and private finance, local government involvement, control and policing as well as well established open standards.

Like I said, from a pure technology point of view we are in pretty good shape to solve problems like this. We now have an unprecedented amount of: instrumentation, interconnectedness and intelligence
such that organisations (and societies) can think and act in radically new ways. However in order to solve problems like the parking one as well as significantly more 'wicked' ones I believe we need skills that stretch beyond the mere technological. If you are to help solve these problems then you need to be a versatile and adaptive systems thinker. A systems thinker is someone who not only uses her left-brained logical thinking capabilities but also uses her right-brained creative and artistic capabilities. Here are six attributes (from Dan Pink's book A Whole New Mind) that a good systems thinker needs to adopt which I think will help in solving some of the worlds wicked problems:

Design – It is no longer sufficient or acceptable to create a product or service that merely does the job. Today it is both economically critical as well as aesthetcially rewarding to create something that is beautiful and emotionally engaging.
Story – We are living in a time of information overload. If you want your sales pitch or point of view to be heard above the cacophony of background noise that is out there you have to create a compelling narrative.
Symphony – We live in a world of silos. Siloed processes, siloed systems and siloed societies. Success in business and in life is about breaking down these silos and pulling all the pieces together. Its about synthesis rather than analysis.
Empathy – Our capacity for logical thought has gone a very way to creating the technological society we live in today. However in a world of ubiquitous information that is available at the touch of a button logic alone will no longer cut the mustard.In order to thrive we need to understand what makes our fellow humans tick and really get beneath their skin and to forge new relationships.
Play – In a world where we are all having to meet targets, pass tests and achieve the right grades in order to get on it is easy to forget the importance of play. There is a lot of evidence out there of the benefits to our health and general well-being of the benefits of play, not only outside work but also inside.
Meaning – We live in a world of material plenty put spiritual scarcity. Seeking meaning in life that transcends above “things” is vital if we are to achieve some kind of personal fulfilment.

A Gartner report published in 2005 predicted that by 2010, IT professionals will need to possess expertise in multiple domains. Technical aptitude alone will no longer be enough. IT professionals must prove they can understand business realities – industry, core processes, customer bases, regulatory environment, culture and constraints. Versatility will be crucial. It predicted that by By 2011, 70 percent of leading-edge companies will seek and develop “versatilists” while deemphasizing specialists.

Versatilists are people whose numerous roles, assignments and experiences enable them to synthesise knowledge and context in ways that fuel business value. Versatilists play different roles than specialists or generalists. Specialists generally have deep technical skills and narrow scope, giving them expertise that is recognized by peers, but it is seldom known outside their immediate domains. Generalists have broad scope and comparatively shallow skills, enabling them to respond or act reasonably quickly, but often at a cursory level. Versatilists, in contrast, apply depth of skill to a rich scope of situations and experiences, building new alliances, perspectives, competencies and roles. They gain the confidence of peers and partners. To attain versatilist skills, IT professionals should..

Look outside the confines of current roles, regions, employers or business units. The more informed a professional is about a company, its industry segment and the forces that affect it, the greater the contextual grasp.
Lay out opportunities and assignments methodically. Focus on the areas and challenges that fall outside the comfort zone; those areas generally will be the areas of greatest growth.
Explore possibilities outside the world of corporate business. Not-for-profit ventures, startup companies, government agencies and consumer IT service providers offer powerful ways to bolster experiences, behavioral competencies or management skills.
Enroll in advanced degree programs or in qualified education courses to expand perspective.
Identify companies, projects, assignments, education and training that will increase professional value.

I believe we’ve only just begun to scratch the surface of what's possible on a “smarter planet”. However if we are to really address the truly wicked problems that are out there in order to make our world a better, and maybe even a fairer place, we need people like you to make it happen.

Finally you might be tempted in these hard economic times when you are being asked to pay outrageous amounts for your education not to bother with university. However bear this in mind:

"Unskilled labor is what you call someone who merely has skills that most everyone else has. If it's not scarce, why pay extra? Skills matter. The unemployment rate for US workers without a college education is almost triple that for those with one. Even the college rate is still too high, though. On the other hand, the unemployment rate for skilled neurosurgeons, talented database designers and motivated recombinant DNA biologists is essentially zero, despite the high pay in all three fields. Unskilled now means not-specially skilled".

The only real investment you have for the future is the piece of grey matter between your ears. Make sure you continue to nurture and nourish it throughout your life by stimulating both the left and right sides.

Thank you and good luck with whatever path you choose to take in life.

The Next Generation?

2011-03-10T21:40:00.000Z

Demographers, social scientists and new media watchers are fond of dividing people into generations based on what recent (i.e. post-World War II) period of history they were born in. Whilst there are no consistent definitions of when these generations begin and end they roughly fall into these periods:

Baby-boomers: 1940 – 1960. Those born during the post–World War II demographic boom in births. This generation more than any other rejected the moral and religous beliefs of their parents and created their own sets of values. This is the generation that invented sex, drugs and rock'n'roll and is still largely the one that is ruling the roost so to speak (President Obama, born in 1961, catching the tail end of this particular demographic).
Generation X (post boomers): 1960 - 1980. This term was apparently coined by the great Magnum photographer Robert Capa in the early 1950s. He used it as the title for a photo-essay about young men and women growing up immediately after the Second World War. Sometimes referred to as the "unknow" or "lost" genaration this group has signified people without identity who face an uncertain, ill-defined (and perhaps hostile) future. This is the generation that grew up during the fall of the Berlin war, the end of the Cold War and various economic crises (such as the 1979 olil crisis) and were most likely to be the children of divorced parents.
Generation Y (the Millenial generation): 1980 – 2000. This is the culturally liberal generation that witnessed the start and wide-spread adoption of the internet and are the children of baby-boomers. This is the generation that owns, and is most comfortable with using, most computers, mobile phones and MP3 players.

So what is the next generation born during the last 10 years and possibly the next 10 to be called? The obvious name would be "Generation Z" although this would mean we will have run out of letters already so will have problems naming the post-2020 generation. Rather than following the obvious trend therefore how about naming this upcoming generation who will be entering the higher education system and workforce during the next 10 years "Generation V", the versatilist generation? These are the people, more than any others, who will need to adopt a whole new set of skills if they are to survive and prosper during their lifetimes. These are the ones who will be suffering the after-shocks of the baby-boom, X and Y generations and who will need to fix the wicked problems those generations have left in their wake. This is the generation that will probably have more jobs, in their lifetime, than the other three generations put together and who will, as Daniel Pink has suggested have to survive in a world dominated by the three A's:

Automation - Jobs can be done faster and more efficiently by computers.
Abundance - We have more stuff than we know what to do with and it is increasingly being produced at cheaper and cheaper rates.
Asia (or Africa) - More and more work is outsourced to these low cost economies.

The skills that this generation will need to adopt will be many and varied and include:

Objectively viewing experiences and roles, learning from these (failures as well as successes) and using this knowledge to gain new roles.
Looking outside the confines of current roles, regions, employers or business units. The more informed a professional is about a company, its industry segment and the forces that affect it, the greater chance will the person have to predict and survive economic downturns.
Laying out opportunities and assignments methodically. Focusing on the areas and challenges that fall outside the comfort zone; those areas generally will be the areas of greatest growth.
Exploring possibilities outside the world of large, corporate business. Charities, startup companies, government agencies, even your own web-startup offer new and interesting ways to build experiences, learn new skills and maybe even modify behaviours.
Enrolling in advanced education courses to expand perspective, preferably outside your current discipline and area of expertise.
Targeting companies, projects, assignments, education and training courses that will increase professional value and make you more marketable.

Sadly Gartner seem to have coined the use of "Generation V" already, where V is for virtual. Pity, as they also coined the term "virtualist", missed opportunity I reckon.

Is Agile Architecture an Oxymoron?

2011-03-09T16:35:00.003Z

Much has been written by many great minds on agile development processes and how (or indeed whether) architecture fits into such processes. People like:

Scott Ambler (Architecture Envisioning: An Agile Best Practice). "Some people will tell you that you don’t need to do any initial architecture modeling at all. However, my experience is that doing some initial architectural modeling in an agile manner offers several benefits".
Mike Cohn (Succeeding with Agile). "On an architecturally complicated or risky project, the architect will need to work closely with the product owner to educate the product owner about the architectural implications of items on the product backlog".
Walker Royce (Top 10 Management Principles of Agile Software Delivery) : "Reduce uncertainties by addressing architecturally significant decisions first".
Andrew Johnston (Role of the Agile Architect): "In an agile development the architect has the main responsibility to consider change and complexity while the other developers focus on the next delivery".
Martin Fowler (Is Design Dead?): "XP does give us a new way to think about effective design because it has made evolutionary design a plausible strategy again".

I've been contemplating how the discipline of architecture, as well as the role of the architect, fits with the agile approach to developing systems whilst reviewing the systems development lifecycle (SDLC) for a number of clients of late. In my experience most people have an "either-or" approach when it comes to SDLC's. They either do waterfall or do agile and have some criteria which they use to decide between the two approaches on a project by project basis. Unfortunately these selection criteria are often biased toward the prejudices of the person writing the criteria and will push their favourite approach.

Rather than treating agile and waterfall as mutually exclusive I would prefer to adopt a layered approach to defining SDLC's as shown here.

The three layers have the following characteristics:

Basic Process. Assume all projects adopt the simplest approach to delivery as possible (but no simpler). For most software product development projects this will amount to an agile approach like Scrum which uses iterations (sprints) and a simplified set of roles, namely: Product Manager, Scrum Master and Team where Team is made up of people adopting multiple roles (architect, programmer, tester etc). On such projects decide up front which artefacts you want to adopt. These don't need to be heavy-weight documents but could be contained in tools or as sketches. Here the team member performing the architect role needs to manage an "emergent architecture". The role of architect maybe shared or not dedicated to a single individual.
Complex Process. At the next level of complexity where multiple-products need to be built as part of a single program of work and all these have dependencies some level of governance usually needs to be in place that ensures everything comes together at the right time and is of a consistent level of quality. At a micro-level this can be done using a scrum-of-scrums approach where a twice or thrice weekly scrum that brings together all the Scrum Masters happens. Here the architect role is cross-product as it needs to ensure all products fit together (including maybe third party products and packages). This may still be a shared role but is more likely to be a dedicated individual. This may involve some program level checkpoints that at least ensure all iterations have created a shippable product that is ready to integrate or deploy. The architecture is not just emergent any more but may also needs to be "envisioned" up-front so everyone understands where their product fits with others.
Complex Integration Process. The final level of complexity is caused when not only multiple products are being developed but also existing systems need to be incorporated which have complex (or poorly understood) interfaces. Here the role of the architect is not only cross-product but cross-system as she has to deal with the complexity of multiple systems, some of which may need to be changed by people other than the core development team. Here the level of ceremony as well as the number of artefacts to control and manage the decisions around the complexity will increase. The architecture is certainly not emergent any more but also needs to be "envisioned" up-front so everyone understands where their product fits and also what interfaces they need to work with. This is something Scott Ambler suggests happens during "iteration zero".

Each of these layers is built on a common architectural as well as process "language" so everyone has a common understanding of terms used in the project.

I'm much in agreement with Mike Cohn's comment on his blog recently where, in reflecting on the tenth anniversary of the Agile Manifesto he says: "The next change I’d like to see (and predict will occur) over the next ten years also occurred in the OO world: We stop talking about agile" and goes on to say "Rather than “agile software development” it is just “software development”—and of course it’s agile".

I would like to see an agile or lean based approach as the de-facto standard that only adds additional artefacts or project checkpoints as needed rather than thinking that every time we need to either adopt an agile approach or a waterfall approach.

Forget T-Shaped, We Need V-Shaped Architects

2011-02-28T23:19:00.002Z

A recent blog from the Open Group discusses the benefits of so called "T-shaped people". According to this blog, T-shaped people are what HR are looking for these days. To quote from the blog a T-shaped person is someone who: "combines the broad level of skills and knowledge (the top horizontal part of the T) with specialist skills in a specific functional area (the bottom, vertical part of the T). They are not generalists because they have a specific core area of expertise but are often also referred to as generalizing specialists as well as T-shaped people". The picture below shows this.

Traditionally for software architects the specialism that T-shaped people usually have has come from their entry-level skills or the ones that got them into the profession in the first place. This is usually a skill in a particular programming language, development approach (agile, scrum or whatever) or other areas related to software development such as test or configuration management. As you progress through your career and begin to build on your skills (learning more programming languages, understanding more about design etc) you may add to the verticals in your T's with these other specialisms. This, at least, has traditionally been the approach. The problem is that in some organisations in order to "progress" (i.e. earn more money) you almost need to know more about less. You need to generalise more and more quickly. No one is going to employ you to be a Java programmer if your salary is ten times that of what a Java programmer in India or China earns. This is not meant to be a criticism against software professionals in India or China by the way. It's just the way of things. Soon people in India and China will be out-sourcing to lower cost regions and so the cycle will go on. It does however raise an interesting problem of how those core specialisms will be developed in people just entering the profession. I spent a good 15 years as a programmer before I moved into architecture and would like to think that what I learnt there gave me a good set of core, fundamental skills that I can still apply as an architect. I firmly believe that the fundamentals I learnt from programming (encapsulation, design by contract, the importance of loose coupling etc) never go out of fashion.

As I have blogged before, I believe that whilst good "generalizing specialists" can also make good architects there is another dimension to what makes a true architect who has the skills necessary to solve the really hard business as well as socio-political (e.g. global warming, global terrorism, resource shortages etc) problems that the world faces today. Gartner coined the term "versatilist" back in 2005 and whilst this does not seem to have really taken off (there is a versatilist web site but it seems to be little used) I like the fact that the 'V' of versatilist makes a nice paradigm for what 21st century IT architects need to be. V-shaped people are not just ones who have deep skills in specific functional areas but also have skills in other disciplines. Further a good V-shaped person is one who has skills not just in technical disciplines but also business and artistic disciplines. So why does this matter?

The concept of bringing interdisciplinary teams together to break down boundaries in solving difficult or wicked problems is not a new one. It is recognised that pooling different academic schools of thought can often throw up solutions to problems that any of the individual disciplines could not. It follows therefore that if an individual can be well rounded and at least have some level of knowledge in an area completely outside his or her core discipliines then they to may be able to shed new light on difficult problems. This is what being a versatilist is about. As shown below its not just about specialising in different functional areas within a discipline but also across disciplnes. If these disciplines can be a mix of the arts as well as the sciences that exercise both right and left brains then so much the better.

So how should versatilists develop their skills? Here are some suggestions I give to IT students when discussing how they might survive as professionals in the 21st century world of work:

Objectively view experiences and roles - When you have finished an assignment note down what you learnt from it, what you could have done better and maybe ask others what they thought of your performance.
Look further than current roles. Today you are working on a particular project however always have in mind what you want to do next and an idea of what you want to do after that. Don't become stereotyped, prepare to move on even if you are in an area you know well.
Plan opportunities and assignments - This follows on from the last one. make sure each assignment really builds on and develops your skills. Step out of your comfort zone in each new assignment.
Explore other possibilities. Never assume there is only one option. Think differently and look at alternatives. Like Paul Arden said, "Whatever You Think, Think The Opposite".
Pursue lifelong learning - What it says. never stop exploring!
Identify companies that will increase professional value. Companies are out to get what they can from you. make sure you do the same with them.

So as we enter the second decade of the 21st century can we not look for more T-shaped people but start the search for V-shaped people instead? These are the ones who will really make a difference and be able to address the really wicked problems that are out there.

Watson, Turing and Clarke

2011-02-17T23:30:00.003Z

So what do these three have in common?

Thomas J. Watson Sr, CEO and founder of IBM (100 years old this year). Currently has a computer named after him.
Alan Turing, mathematician and computer scientist (100 years old next year). Has a famous test named after him.
Aurthur C. Clarke, scientist and writer (100 years old in 1917). Has a set of laws named after him (and is also the creator of the fictional HAL computer in 2001: A Space Odyssey).

Unless you have moved into a hut, deep in the Amazon rain forest you cannot have missed the publicity over IBM's 'Watson' computer having competed in, and won, the American TV quiz show Jeopardy. I have to confess that until last week I'd not heard of Jeopardy, possibly because a) I'm not a fan of quizzes, b) I'm not American and c) I don't watch that much television. To those as ignorant as me on these matters the unique thing about Jeopardy is that contestants are presented with clues in the form of answers, and must phrase their responses in the form of a question.

This, it turns out, is what makes this particular quiz such a hard nut for a computer to crack. The clues in the 'question' rely on subtle meanings, puns, and riddles; something humans excel at and computers do not. Unlike IBM's previous game challenger Deep Blue, which defeated chess world champion Gary Kasparov, it's not sufficient to rely on raw computing 'brute force' but this time the computer has to interpret meaning and the nuances of the human language. So has Watson achieved, met or passed the Turing test (which is basically a measure of whether computer can demonstrate intelligence)?

The answer is almost certainly 'no'. Turing's test is a measure of a machines ability to exhibit human intelligence. The test, as originally proposed by Turing was that a questioner should ask a series of questions of both a human being and a machine and see whether he can tell which is which through the answers they give. The idea being that if the two were indistinguishable then the machine and the human must both appear to be as intelligent as each other.

As far as I know Turing never stipulated any constraint on the range or type of questions that could be answered which leads us to the nub of the problem. Watson is supremely good at answering Jeopardy type questions just as Deep Blue was good at playing chess. However neither could do what the other does (at least as well). They have been programmed for that given task. Given that Watson is actually a cluster of POWER7 servers any suitably general purpose computer that could win at Jeopardy, play chess as well as exhibit the full range of human emotions and frailties that would be needed to fool a questioner would presumably occupy the area of several football pitches and consume the power of a small city.

That however misses the point completely. The ability of a computer to almost flawlessly answer a range of questions, phrased in a particular way on a range of different subject areas, blindingly fast has enormous potential in fields of medicine, law and other disciplines where questions based on a huge foundation of knowledge built up over decades need to be answered quickly (for example in accident and emergency where quick diagnoses may literally be a matter of life and death). This indeed is one of IBM's Smarter Planet goals.

Which brings us to Clarke's third law which states that "any sufficiently advanced technology is indistinguishable from magic". This is surely something that is attributable to Watson. The other creation of Clarke of course is HAL the computer aboard the spaceship Discovery One on a trip to Saturn that becomes overwhelmed by guilt at having to keep secret the true nature of the spaceships mission and starts killing members of the crew. The point of Clarke's story (or one of them) being that the downside to a computer that is indistinguishable from a human being is that the computer may also end up mimicking human frailties and weaknesses. Maybe it's a good job Watson hasn't passed Turing's test then?

Think Like An Architect

2011-02-14T16:01:00.000Z

A previous entry suggested hiring an architect was a good idea because architects take existing components and assemble them in interesting and important ways.

So how should you "think architecturally" in order to create things that are not only interesting but also solve practical, real-world problems? Architectural thinking is about balancing three opposing “forces”: what people want (desirability), what technology can provide (feasibility) and what can actually be built given the constraints of cost, resource and time (viability).

It is basically the role of the architect to help resolve these forces by assembling components "in interesting ways". There is however a fourth aspect which is often overlooked but which is what separates great architecture from merely good architecture. That is the aesthetics of the architecture.

Aesthetics is what separates a MacBook from a Dell, the Millau Viaduct in France from the Yamba Dam Bridge in Japan and the St Mary Axe from the Ryugyong Hotel in North Korea. Aesthetics is about good design which is what you get when you add 'significance' (aesthetic appeal) to 'utility' (something that does the job). IBM, the company I work for, is 100 years old this year (check out the centennial video here) and Thomas Watson, IBM's founder, famously said that "good design is good business". Watson knew what Steve Jobs, Tim Brown and many other creative designers know; aesthetics is not only good for the people that use or acquire these computers/buildings/systems it's also good for the businesses that create them. In a world of over-abundance good design/architecture both differentiates companies as well as giving them a competitive advantage.

How Much Does Your Software Weigh, Mr Architect?

2011-02-03T23:32:00.000Z

Three apparently unrelated events actually have a serendipitous connection which have led to the title of this weeks blog.

First off, Norman Foster (he of the "Gherkin" and "Wobbly Bridge" fame) has had a film released about his life and work called How Much Does You Building Weigh, Mr Foster. As a result there have been a slew of articles about both Foster and the film including this one in the Financial Times. One of the things that comes across from both the interviews and the articles about Foster is the passion he has for his work. After all, if you are still working at 75 then you must like you job a little bit! One of the quotes that stands out for me is this one from the FT article:

“The architect has no power, he is simply an advocate for the client. To be really effective as an architect or as a designer, you have to be a good listener.”

How true. Too often we sit down with clients and a jump in with solutions before we have really got to the bottom of what the problem is. It's not just about listening to what the client says but also what she doesn't say. Sometimes people only say what they think you want them to hear not what they really feel, So, it's not just about listening but developing empathy with the person you are architecting for. Related to this is not closing down discussions too early before making sure everything has been said which brings me to the second event.

I'm currently reading Resonate by Nancy Duarte which is about how to put together presentations that really connect with your audience using techniques adopted by professional story tellers (like film makers for example). In Duarte's book I came across the diagram below which Tim Brown also uses in his book Change by Design.

For me the architects sits above the dotted line in this picture ensuring as many choices as possible get made and then making decisions (or compromises) that are the right balance of the sometimes opposing "forces" of the requirements that come from multiple choices.

One of the big compromises that often needs to be made is how much can I deliver in the time I have available and, if its not everything, what is dropped? Unless the time can change then its usually the odd bit of functionality (good if these functions can be deferred to the next release) or quality (not good under any circumstances). This leads me to the third serendipitous event of the week: discovering "technical debt".

Slightly embarrassingly I had not heard of the concept of technical technical debt before and it's been around for a long time. It was originally proposed by Ward Cunningham in 1992 who said the following:

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation".

Technical debt is a topic that has been taken up by the Software Engineering Institute (SEI) who are organising a workshop on the topic this year. One way of understanding technical debt is to see it as the gap between the current state of the system and what was originally envisaged by the architecture. Here, debt can be "measured" by the number of known defects and features that have not yet been implemented. Another aspect to debt however is the amount of entropy that has set in because the system has decayed over time (changes have been made that were not in line with the specified architecture). This is a more difficult thing to measure but has a definite cost in terms of ease of maintenance and general understandibility of the system.

Which leads to the title of this weeks blog. Clearly software (being 'soft') carries no weight (the machines it runs on do not count) but nonetheless can have a huge, and potentially damaging weight in terms of the debt it may be carrying in unstructured, incorrect or hard to maintain code. Understanding the weight of this debt, and how to deal with it, should be part of the role of the architect. The weight of your software may not be measurable in terms of kilograms but it surely has a weight in terms of the "debt owed".

Learning Architecture (Or Anything really)

2011-01-31T19:47:00.000Z

I spent most of 2010 travelling the world teaching Architectural Thinking for a client. (Here is a reasonable description of some of what this covers. It's the best publicly available description I can find but please contact me if you would like more information on this class).

I always reckon that you learn just as much as a teacher as you do as a student (or should do) so here's some stuff I learnt myself. This is not rocket science and many people may consider this obvious but for those for whom this is not the case I hope you find it useful.

People learn best when they have some fun. This doesn't mean you have to be a great comedian to deliver an effective training class however it does help if you can arrange some fun activities as part of the learning. Quizzes (that also inject an element of competition) work well as a way of re-enforcing peoples learning.
Ensure that at least half the time (and preferably two thirds of it) are spent on getting the attendees to do something. This does not have to be a full-blown case study (though you certainly need one of those) but should at least include plentiful opportunities for discussions and Q&A sessions (where the questions are not just asked by the students).
Less really is more. When delivering a lecture, or a complete class, especially one you are very familiar with. It is tempting to cram more and more information in as you deliver more classes. People ask a question, you answer it and think "hey, why don't I create a slide for that for next time". Don't. Slide-creep is one of the great evils of our time. Rather thank thinking "what can I add" think "what can I remove". Hand out detail as additional reading. Keep the main-deal brief.
Try, whenever you can, to tell stories rather than deliver dry facts. For me a teacher is, above all else, an experienced practitioner. Introducing your own "war stories" at appropriate points is what makes a great and teacher.
Great public speakers (Richard Feynman, Steve Jobs, Banjamin Zander) inject passion into what they have to say. If you are not passionate about what you are saying then maybe you should not be standing up in front of others saying it! Think about what first made you interested in the topic you are delivering and weave that into the storyline. Injecting some of your personal self into a subject helps engage the audience and make them believe in what you have to say.

Finally take a look at this great advice from Seth Godin on organising a retreat. It may not be a full blown retreat you are organising but it contains great advice for just about any learning event where you want to get the best out of people.

2011 Architecture Survival Guide

2011-01-21T01:05:00.001Z

An article in last Sundays Observer newspaper about Facebook has set me thinking about how we architects can not only survive in today's rapidly changing technological environment but also actually make a positive difference to the world (even if it's not on the scale of Facebook, assuming you think that has made a positive impact on the world).

The article by John Naughton examines the claim by the Winklevoss twins that they were ripped off when they reached a settlement with Mark Zuckerburg in 2008 after they claimed it was they who had invented Facebook. Their claim is that the number of Facebook shares they acquired was based on a false valuation. For an entertaining view of this see, or rent, The Social Network which goes into the history of how Facebook came into being. The article goes on to pose the question: would we now be looking at a social networking service with 600 million users if the Winklevoss twins had been the ones to develop Facebook?

Naughton thinks not and goes on to explain that although the Winklevoss twins were not stupid they probably "laboured under two crippling disadvantages":

They were, and probably still are, conventional people who may have been good at "creating businesses in established sectors but who find it hard to operate in arenas where there are no rules".
The twins weren't techies and so had no real insight into the technology they were creating and its possibilities. They were therefore less likely to "spot the importance of allowing Facebook to become a software platform on which other people could run applications".

Here's my takeaway from this if you want to come up with new ideas, at whatever scale, no one else has thought of.

Don't think conventionally.Conventional thinking will end up creating conventional business models. Conventional means doing what you've been told or what your peers do. Someone once said "fear of our peers makes us conservative in our thinking". Zuckerburg was not only fearless of his peers (the Winklevoss twins) but had no qualms about using (some would say stealing) their ideas and using them for his own ends. I guess it poses an interesting moral dilemma about when it is right to steal someone elses idea because you think you can do more with it. Facebook paid for this by handing over cash and shares to the Winklevoss twins but have benefited from this 'investment' many times over.
Don't think like everyone else. Walter Lippmann (a writer and political commentator) once said "where we all think alike, no one thinks very much." Some people claim that Zuckeburg (if you believe the movie at any rate) exhibits characteristics that place him on the autistic spectrum. (actually as having Asperger syndrome). One of the characteristics of someone with Aspergers is that they display behavior, interests, and activities that are restricted and repetitive and are sometimes abnormally intense or focused. Zuckeburg not only thought differently to everyone else but took an idea and focused on it intensely (many, many hours of programming) until Facebook was created.
Think visually. Interesting related to number 2. People on the autistic spectrum are often more visual thinkers than those who are not. We often joke about "back of an envelope" or "back of a fag packet" designs but setting aside the medium the ability to visualise your thoughts quickly and succinctly is a key characteristic it's worth fostering. One of my more memorable ad-hoc design sessions took place over a meal in a restaurant where we used the table cloth as a our drawing canvas. Luckily it was a paper table cloth!
Don't get out of touch with technology. One of the dangers of becoming an architect in order to make yourself "more valuable" (see Dilbert below) is you not only lose touch with technology but you lose the ability to exploit it in ways others may not see. Making Facebook an open platform has been one of the key factors in its runaway success. I've discussed before the importance of being a versatilist (broad in several disciplines and deep in a few specialisms) and this ones all about picking your technology (we can't all be good at everything) and specialising yourself in it!

Software Developments Best Kept Secret

2011-01-13T17:11:00.000Z

A few people have asked what I meant in my previous entry when a said we should be "killing off the endless debates of agile versus waterfall." Don't get me wrong, I'm a big fan of doing development in as efficient a way as possible, after all why would you want to be doing things in a 'non-agile' way! However I think that the agile versus waterfall debate really does miss the point. If you have ever worked on anything but the most trivial of software development projects you will quickly realise that there is no such thing as a 'one size fits all' software delivery lifecycle (SDLC) process. Each project is different and each brings its own challenges in terms of the best way to specify, develop, deliver and run it. Which brings me to the topic of this entry, the snappily titled Software and Systems Process Engineering Metamodel or 'SPEM' (but not SSPEM).

SPEM is a standard owned by the Object Management Group (OMG), the body that also owns the Unified Modeling Language (UML), the Systems Modeling Language (SysML) and a number of other open standards. Essentially SPEM gives you the language (the metamodel) for defining software and system processes in a consistent and repeatable way. SPEM also allows vendors to build tools that automate the way processes are defined and delivered. Just like vendors have built system and software modeling tools based around UML so too can vendors build delivery process modeling tools built around SPEM.

So what exactly does SPEM define and why should you be interested in it? For me there are two reasons why you should look at adopting SPEM on your next project.

SPEM separates out what you create (i.e. the content) from how you create it (i.e. the process) whilst at the same time providing instructions for how to do these two things (i.e. guidance).
SPEM (or at least tools that implement SPEM) allows you to create a customised process by varying what you create and when you create it.

Here's a diagram to explain the first of these.

SPEM Method Framework

The SPEM Method Framework represents a consistent and repeatable approach to accomplishing a set of objectives based on a collection of well-defined techniques and best practices. The framework consists of three parts:

Content: represents the primary reusable building blocks of the method that exist outside of any predefined lifecycle. These are the work products that are created as a result of roles performing tasks.
Process: assembles method content into a sequence or workflow (represented by a work breakdown structure) used to organise the project and develop a solution. Process includes the phases that make up an end-to-end SDLC, the activities that phases are broken down into as well as reusable chunks of process referred to as 'capability patterns'.
Guidance: is the ‘glue’ which supports content development and process execution. It describes techniques and best-practice for developing content or 'executing' a process.

As well as giving us the 'language' for building our own processes SPEM also defines the rules for building those processes. For example phases consist of other phases or activities, activities group tasks, tasks take work products as input and output other work products and so on.

This is all well and good you might say but I don't want to have to laboriously build a whole process every time I want to run a project. This is where the second advantage of using SPEM comes in. A number of vendors (IBM and Sparx to name two) have built tools that not only automate the process for building a process but which also contain one or more 'ready-rolled' processes to get you started. You can either use those 'out of the box', extend them by adding your own content or start from scratch (not recommended for novices). What's more the Eclipse foundation have developed an open software tool, called the Eclipse Process Framework (EPF) that not only gives you a tool for building processes but also comes with a number of existing processes, including OpenUP (open version of the Rational Unified Process) as well as Scrum and DSDM.

If you download and install EPF together with the appropriate method libraries you can use these as the basis for creating your own processes. Here's what EPF looks like when you open the OpenUP SDLC.

EPF and OpenUP

The above view shows the browsing perspective of EPF, however there is also an authoring perspective which allows you to not only reconfigure a process to suit your own project but also add and remove content (i.e. roles, tasks and work products). Once you have made your changes you can republish the new process (as HTML) and anyone with a browser can then view the process together with all of it work products and, most crucially, associated guidance (i.e. examples, templates, guidelines etc) that allow you to use the process in an effective way.

This is, I believe, the true power of using a tool like EPF (or IBM's Rational Method Composer which comes preloaded with the Rational Unified Process). You can take an existing SDLC (one you have created or one you have obtained from elsewhere) and customise it to meet the needs of your project. The amount of agility and number of iterations etc that you want to run will depend on the intricacies of your project and not what some method guru tells you that you should be using!

By the way for an excellent introduction and overview of EPF see here and here. The Eclipse web site also contains a wealth of information on EPF. You can also download the complete SPEM 2 specification from the OMG web site here.

Architecture is Architecture?

2011-01-06T20:44:00.002Z

At OT 99 (that's Object Technology 1999, now known as SPA for Software Process Advancement) I attended a session by Kent Beck called Software is Software - Beyond the Horseless Carriage. The basic premise of Kent's talk was that it was about time the software business "grew up" and its practitioners recognise it for what it is, a discipline in its own right which no longer needs to continuously borrow terms and techniques from other industries and disciplines. The title of the session refers to the time when the automobile was first invented and people called them horseless carriages because horse-drawn carriages were the only frame of reference they had. Unfortunately, 12 years later, I don't think we have quite got around to jettisoning our horseless carriages, especially in the upfront work that is done in trying to map out the major system components and their relationships, sometime referred to as architecture (a word which itself is borrowed from another profession of course). On the face of it this may not seem to be a problem; after all those other industries (civil engineering, auto-engineering even film making) have been around a lot longer and so must be able to offer good advice and guidance to the business of software mustn't they? Actually, I think there is a problem and Kent Beck was, and still is, right.

The business of 'making' software is fundamentally different from any other human endeavor. Software is infinitely malleable and potentially changeable right up to (and sometimes after) it has gone into production. No other engineering discipline has that flexibility. At some point drawings and blueprints have to be signed off, factories and production lines have to be built, building sites prepared and production begun. After this any change becomes prohibitively expensive. With software the perception (and sometimes the reality) is that code changes can be made right up to the moment the software ships.
Most other engineering disciplines have fairly well defined job roles, often with their own professional organisations, training programmes and qualifications and well understood and mature tools. These roles are usually carried out by separate individuals (in the construction industry it's unlikely the architect will roll her sleeves up and start laying bricks).
The engineering and manufacturing approach, or process, is by and large pretty well understood and has been refined over a long period of time (sometimes hundreds of years). The approaches can be taught and are an integral part of the role of being an architect or aero-engineer. Further, these approaches are built around a common language which is also taught and well understood by its practitioners.

A rigorous approach to the field of software architecture needs to recognise the differences whilst at the same time understanding its constraints and build a solid, engineering based approach to its development. This should include killing off the endless debates of agile versus waterfall or structured versus object-oriented and any of the other interminable 'religious wars' that we seem to love embarking on and focus in on what matters: applying IT in a reasoned and structured way to solving real-world (and sometimes complex) business problems.

As we enter the new year lets celebrate the field of software development for what it is and help forge the right amount of rigor and discipline in creating a 'proper' profession that finally loses the shackles of all those other industries. After all as this guy says (far more eloquently than me) "the processor is an expression of human potential" and is "akin to a painter’s blank canvas" (see this great drawing). I'd like to think of us architects as the painters ready to fill that canvas with great art. Oh heck, but that means we are now comparing architecture with art and that would never do.

On Being a Software Architect

2010-12-22T21:33:00.001Z

Thanks to a wonderful bits of "webendipity" (something unexpected and useful found from surfing the web, a conjunction of web-serendipity) in this case a blog causing me to follow that blogger on twitter whose tweet pointed me to another blog, I came across An Overly Long Guide to Being a Software Architect by David Ing today which nicely parallels my previous effort on how not to be a (Software) Architect.

I particularly like Ing's number 11:

Finally my last tip is to never take advice from Top 11 tip lists. In nearly all cases there was only about 3 good points and with about 8 padding.

Definitely a lesson for me there I think. Maybe my New Years resolution should be to publish fewer lists!

You Can No Longer Call Yourself an Architect When...

2010-12-21T12:00:00.001Z

Ten behaviours that might mean you can no longer call yourself an Architect...

The majority of your output is created using Microsoft's Office suite.
Your days are spent fighting the system rather than creating a system.
You're fitting business to technology rather than the other way around.
You think reuse is what you do with your shirt when you unexpectedly have to spend one extra day with the client (possibly wasting your time doing 2 above).
The only stakeholders you deal with are your non-vegetarian colleagues during your evening meals at the Angus Steakhouse.
You can no longer remember the difference between a For loop and a While loop.
You think a view is something you don't normally get from your room in the tourist class hotels your company puts you up in.
Your definition of a non-functional requirement is a functional requirement that isn't.
You spend more time in the box than out of it.
Add your favourite reason below.

This is probably my last post of the year and most certainly the last one before Christmas. Merry Christmas to everyone out there and, as it used to say on the front of The Beano at this time of year:

Happy New Year to All My Readers!

Interprise Architecture and Ultra-Large-Scale Systems

2010-12-07T22:01:00.001Z

In a previous post I introduced the term “Interprise Architecture” to describe how the internet is breaking down the traditional boundaries of the enterprise and thus requires a new approach to Enterprise Architecture that's not just about describing what's inside the enterprise but also what's on the outside. No longer can Enterprise Architects create blueprints for some future state that the enterprise will one day reach with roadmaps for how that state will be achieved. There are too many disruptive influences and new technologies that are impinging on the enterprise that will not only mean the roadmap is sending you in the wrong direction but that you are probably using the wrong mode of transport to get there as well.

I received a few comments on this from folk at the Software Engineering Institute (SEI)as well as Gartner. The work on Ultra-Large-Scale (ULS) Systems from the SEI particularly drew my attention and resonates nicely with some of my own thoughts. Here are some of the key ideas from the SEI report Ultra-Large-Scale Systems - The Software Challenge of the Future plus some additional musings of my own on what constitutes Interprise Architecture. First, ULS:

The SEI report on ULS systems was funded by the United States Department of Defence (DoD) which asked the SEI to consider future systems that could not only contain of billions of lines of code but also exhibit some, possibly all, of the following characteristics: decentralisation; conflicting, unknowable, and diverse requirements; continuous evolution and deployment; heterogeneous and changing elements; erosion of the people/system boundary; and normal failures of parts of the system.
ULS systems are likely to mean that traditional software and systems engineering approaches will no longer be adequate or can be the primary means by which such systems are designed (architected) or built.
ULS systems can be compared with cities whereas traditional systems can be compared with buildings. Buildings can be designed and built to a blueprint whereas cities emerge and are continuously adapting over time.
ULS systems are comprised of a dynamic community of interdependent and competing organisms (in this case, people, computing devices, and organizations) in a complex and changing environment. These are referred to as socio-technical ecosystems.
ULS systems are ones that are continuously evolving with new behaviour constantly emerging. In this respect they have the attributes of wicked problems where the problem is never definitively solved (or indeed understood).
ULS systems expect failure to be the norm and that unusual situations and boundary conditions will occur often enough that something will always be failing.

The SEI report is primarily aimed at allowing the US military to develop new systems however I believe the key ideas that challenge the development of such systems also have wide applicability in business systems, the sort I'm most interested in. I see that what I have characterised as Interprise Architecture could therefore be applied to developing ULS business systems. Here are three examples of ULS business systems that might benefit from an Interprise Architecture approach:

Electronic Trading Systems. These are systems that trade securities (such as stocks, and bonds), foreign currency, and exchange traded derivatives electronically. They use IT to bring together buyers and sellers through electronic media and create a virtual market place. Such systems are typically built using proprietary software that has grown and evolved over many years. Investment banks have extremely complex technology requirements, as they have to interface with multiple exchanges, brokers and multi-dealer platforms, as well as their own pricing, profit and loss (P&L), trade processing and position-keeping systems. The challenge here then is not only the large numbers of systems but also the increasing complicated regulatory environment.
Electricity Generation and Metering. The generation and consumption of electricity faces a number of unique challenges including improved and more efficient use of green technologies as well as smart metering. Traditional electrical meters only measure total consumption and as such, provide no information of when the energy was consumed. Smart meters provide an economical way of measuring this information, allowing price setting agencies to introduce different prices for consumption based on the time of day and the season.
Retail Systems. As retailers look for ever more cunning ways to get consumers to part with their hard-earned cash, traditional (i.e. high street) and electronic retail will merge more and more. For example not only can I use my 3G enabled smart-phone from the store I happen to be in to quickly compare prices in other stores in the area, the store itself can potentially detect I am shopping there using location based services and make me an enticing offer to shop there.

So here are the seven challenges that I see Interprise Architecture must deal with in developing a ULS business system:

Requirements are unknowable. Sometimes the very act of capturing a requirement (in whatever form) changes the nature of that requirement. Interprise Architecture must not only allow for continuously changing requirements but must also recognise that some uses of the system cannot be known up-front; hence the need to build more adaptable systems.
The boundary between people and systems is at best blurred and at worst never established. Sometimes people will be users of the system, sometimes they (or at least the devices they own) will be part of the system.
Development never stops but is a continuous cycle. Development processes as well as the projects that deliver such systems must therefore support this never-ending cycle.
Systems continuously adapt and exhibit emergent behaviour. As new uses of the system are “discovered' by users the components that make up the system need to be able to adapt to satisfy those new behaviours.
Failure (of parts of the system) is inevitable. Just like a fire in a building in a city can be localised and extinguished without by and large affecting the whole of a city then so to must Interprise Architecture allow for partial failure and reconfiguration of some components.
Development tools and languages need to take account of the unpredictable and maybe even unspecifiable aspects of systems development. Traditional development tools favour left-brain thinkers where logic and reasoning can be applied to develop systems that move from abstract ideas to physical implementations (from models to code if you like). New tools for developing and describing Interprise Architectures need to be able to inject a bit of right-brain thinking by allowing creative multi-disciplinary elements to be added.
Governance needs to be de-centralised. Strong, top-down governance (the sort favoured by Enterprise Architects) cannot work in a system where all the parts may not even be known. Interprise Architecture needs to recognise that some components are outside its control or immediate sphere of influence and have policies in place that allow new components to be added which don't harm or damage the whole system.

As an interesting post-script to this the Financial Times recently published an article on Facebook and the plans that CEO Mark Zuckerberg has for advancing his brainchild. Zuckerberg had just announced a new feature on Facebook called Deals which allows smartphone users who have downloaded the Facebook application to check in at a physical location such as a coffee shop and get a reward. Zuckerberg says:

If you look five years out, every industry is going to be rethought in a social way. You can remake whole industries. That’s the big thing.

Facebook is one example of how external applications that allow users to impinge on the enterprise are changing how Enterprise Architects must think.

Next, a story for what a ULS business system might look like and how it might work.

A Tale of Two Cities

2010-12-04T03:58:00.001Z

I've recently been travelling in Asia working for a client delivering architectural training and was struck by the amazing contrast between the last two cities I visited, Singapore and Bangalore (or Bengaluru as it is now known). The contrast between these two cities set me thinking about Enterprise Architecture and how the approach to city planning can make or break how a city functions. For those not familiar with these two cities here are my fleeting observations (based on a few days spent in each).

Singapore is a city state with a population of 5 million people. The predominant industries are shipping, financial services, manufacturing and tourism. Singapore's airport (Changi) is a modern airport which is the international hub for Singapore Airlines with good connections via the metro (known as MRT) to the city. The airport offers free wi-fi in all areas (I have a theory that the amount of free wi-fi you can get in a city is an indicator of the economic vitality of a place). Architecturally the city is a mix of old colonial style buildings (Raffles Hotel) and ultra-modern new buildings (the Marina Bay Sands hotel for example). Walking around the city you are struck how there is no graffiti, virtually no litter and no begging as well as by the large number of malls with designer shopping on offer and the usual Western outlets (Starbucks, Marks and Spencers, DKNY etc). There is very little serious crime (there being the mandatory death penalty for murder, rape and dealing in drugs). Whilst there is a lot of traffic the roads are well laid out with no significant traffic delays (at least whilst I was there). See here for another view of this city/state.

By contrast Bengaluru is the third most populous city in India with an estimated population of 8 milllion and has seen rapid growth over the last 10 years due to it being the centre for outsourcing (especially IT with nearly all the large IT companies like Infosys, WiPro, HP and IBM having large development centres there). There is an international airport but with no good quality connections to the city. Virtually all visitors are business travellers with very little tourism. There is 15 minutes free wi-fi available in the business lounge only and even then only once you have surrendered your email and mobile phone number. A rapid transport system is being built (which was meant to be operational this month). Architecturally there are some modern buildings (mainly in the technology parks) together with large numbers of shanty towns and hastily constructed, low-cost apartments. Walking around the city you are struck by the vast amount of rubbish with dogs and cows wondering around. Despite it being a “high-tech” city there is still very obvious poverty with begging and homeless people sleeping on benches and in doorways. There are very few Western style shops and virtually no designer outlets.

So what Enterprise Architecture conclusions are to be drawn by comparing these two cities given we often compare Enterprise Architects with city planners and Solution Architects with building architects?

Enterprise Architects have a clear vision (captured as blueprints) of what IT systems the enterprise has and how they need to evolve to support the business strategy, maybe over a one, three and five year outlook. Walking around Singapore (and talking to people that live there) you get the impression there is a “master plan” being enacted. To some extent Singapore only exists because of the efficiency of its infrastructure and the quality of living it can provide to its citizens. This naturally pulls in people and businesses that can take advantage of that infrastructure.
Enterprise Architects define roadmaps showing how the enterprise will get from where it is today to where it needs to be (recognising that changes will be happening all the time). Singapore has clear plans for how the state will grow over the coming years. For example there are plans in place for various extensions of the MRT, some of which are currently under construction. It is expected that by the network will have of 540 km of track by 2050 which will be more than London's 408 km tube system.
Enterprise Architects need to be aware of both what functionality is required but also what qualities and constraints these functions will be delivered to.
Enterprise Architects define clear principles that should be followed by Solution Architects architecting the individual buildings. Whilst there are several old colonial buildings as well as regional styles (China Town has some of the best Chinese architecture I have seen) Singapore has some of the most cutting edge modern architecture around. Despite this there is a strong sense of “harmony” amongst the styles and the feeling there are underlying principles that are in place to help achieve this harmony.
Enterprise Architects enforce strong governance to enforce the blueprints, roadmaps and principles and ensure they are being followed. Singapore has strong (and severe) governance that enforces its laws. There have been very few recorded murder cases over the last decade and those there have been have nearly always ended in the guilty person being executed.

Both cities are great places to visit, I'm sure Bengaluru will get to where Singapore is eventually, after all India is experiencing 8% growth which economists reckon will continue for some years to come. The Indian people have a tremendous attitude to work, what is needed is the good and honest governance of their leaders to turn cities like Bengaluru into a true, modern 21st century city.

Architecture Drill Down in the UML

2010-11-22T19:54:00.001Z

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.

Five Inspirational Videos

2010-11-15T13:33:00.000Z

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!

Hire an Architect

2010-11-14T22:18:00.000Z

Seth Godin has a great definition of what an architect is in his blog here. Here's the description:

Architects don't manufacture nails, assemble windows or chop down trees. Instead, they take existing components and assemble them in interesting and important ways.

He goes on to say that:

...intentionally building a structure and a strategy and a position, not focusing your energy on the mechanics, because mechanics alone are insufficient. Just as you can't build a class A office building with nothing but a skilled carpenter, you can't build a business for the ages that merely puts widgets into boxes.

I like this because for me this is absolutely the essence of what an architect does, take existing components and put them together in new and interesting ways. That's exactly what Tim Berners-Lee did when he created the web. The key skill is not to get bogged down in the detail but to maintain the big picture of whatever it is you are doing. It applies equally to IT systems just as much as it does to buildings.

When a Bridge Falls Down is the Architect to Blame?

2010-11-11T23:59:00.002Z

Here's a question. When a bridge or building falls down whose "fault" is it. Is it the architect who designed the bridge or building in the first place, is it the the builders and construction workers who did not build it to spec, the testers for not testing the worst-case scenario or the people that maintain or operate the building or bridge? How might we use disasters from the world of civil engineering to learn about better ways of architecting software systems?

Here are four well known examples of architectural disasters (resulting in increasing loss of life) from the world of civil engineering:

The Millenium Bridge in London, a steel suspension bridge for pedestrians across the Thames. Construction of the bridge began in 1998, with the opening on 10 June 2000. Two days after the bridge opened the participants in a charity walk felt an unexpected swaying motion. The bridge was closed for almost two years while modifications were made to eliminate the "wobble" which was caused by a positive feedback phenomenon, known as Synchronous Lateral Excitation. The natural sway motion of people walking caused small sideways oscillations which in turn caused people on the bridge to sway in step increasing the amplitude of the bridge oscillations and continually reinforcing the effect. Engineers added dampers to the bridge to prevent the horizontal and vertical movement. No people or animals were injured in this incident.
The Tacoma Narrows Bridge was opened to traffic on July 1st 1940 and collapsed four months later. At the time of its construction the bridge was the third longest suspension bridge in the world. Even from the time the deck was built, it began to move vertically in windy conditions, which led to it being given the nickname Galloping Gertie. Several measures aimed at stopping the motion were ineffective, and the bridge's main span finally collapsed under 40 mph wind conditions on November 7, 1940. No people were injured in this incident but a dog was killed.
On 28 January 2006, the roof of one of the buildings at the Katowice International Fair collapsed in Katowice, Poland. There were 700 people in the hall at the time. The collapse was due to the weight of the snow on the roof. A later inquiry found numerous design and construction flaws that contributed to the speed of collapse. 65 people were killed when the roof collapsed.
The twin towers of the World Trade Center (WTC) in downtown Manhattan collapsed on September 11 2001when al-Qaeda terrorists hijacked two commercial passenger jets and flew them into the skyscrapers. A government report that looked at the collapse declared that the WTC design had been sound and attributed the collapses to "extraordinary factors beyond the control of the builders". 2,752 people died, including all 157 passengers and crew aboard the two airplanes.

In at least one of these cases (the Katowice International Fair building) various people (including the designers) have been indicted for "directly endangering lives of other people” and face up to 12 years of prison. They are also charging the buildings operator for "gross negligence" in not removing snow quickly enough.

So what can we learn from these natural and man made disasters and apply to the world of software architecture? In each of these cases the constructions were based on well known "patterns" (suspension bridges, trade halls and skyscrapers have all successfully been built before and have not collapsed). What was different in each of these cases was that the non-functional characteristics were not taken into account. In the case of the bridges, oscillations caused by external factors (people and winds) were not adequately catered for. In the case of the trade hall in Katowice the building's roof was not engineered to handle the additional weight caused by snow. Finally, in the case of the WTC, the impact of a modern passenger jet, fully laden with fuel, crashing into the building was simply not conceived of (although interestingly an "aircraft-impact analysis", involving the impact of a Boeing 707 at 600 mph was actually done which concluded that although there would "a horrendous fire" and "a lot of people would be killed," the building itself would not collapse. Here are some lessons I would draw from these incidents and how we might relate them to the field of software architecture:

Architects need to take into account all non-functional requirements. Obviously this is easier said than done. Who would have thought of such an unexpected event as a passenger jet crashing into a skyscraper? Actually, to their credit, the buildings architects did but what they lacked was the ability to properly model the effect of such impacts on the structures, especially the effects of the fires.
For complex systems, architects should build models to model all aspects of the architecture. Tools appropriate to the task should be deployed and the right "level" of modelling needs to be done. Prototyping as a means of testing new or interesting technical challenges should also be adopted.
Designers should faithfully implement the architectural blueprints and the architect should remain on the project during the design and implementation phases to check their blueprints are implemented as expected.
Testing should be taken into account early and thought given to how the non-functional characteristics can be tested. Real limits should be applied taking into account the worst case (but realistic) scenario.
Operations and maintenance should be involved from an early stage to make sure they are aware of the impact of unexpected events (for example a complete loss of all systems because of an aircraft crashing on the data centre) and have operational procedures in place to address such events.

As a final, and sobering, footnote to the above here's a quote from a report produced by the British Computer Society and Royal Academy of Engineers called The Challenges of Complex IT Projects.

"Compared with other branches of engineering in their formative years, not enough people (are known to) die from software errors. It is much easier to hide a failed software project than a collapsing bridge or an exploding chemical plant."

The implications of this statement would seem to be that it's only when software has major, and very public, failures that people will really take note and maybe start to address problems before they occur. There are plenty of learning points (anti-patterns) in other industries that we can learn from and should probably do so before we start having major software errors that cause loss of life.

You may be interested in the follow up to the above report which describes some success stories and why they worked (just in case you thought it was all bad).

On Being a Versatilist

2010-11-05T09:57:00.000Z

The world is full of wicked problems. As stated previously a wicked problem is one that is:

Unique
Difficult to define
Linked to other problems
Not always clear when its been solved

Some wicked problems can benefit from the reasoned application of information technology to help in solving them. Solving wicked problems needs an innovative approach and the use of design thinking. A versatilist is someone who knows how to apply design thinking and can orchestrate the skills of multiple disciplines in solving wicked problems. A versatilist is also someone who:

Applies both left (logical) and right (artistic) brain thinking to the problem.
Uses rapid prototyping to test out solutions.
Understands that everything is connected to everything else and that sometimes solving one problem results in many more.
Is not afraid to disrupt the status quo and risk ridicule from his peers.
Is not afraid to propose a solution to a problem before the problem is completely understood.
Iterates (maybe many times) rather than expecting to arrive at a solution following a (simple-minded) analysis of the problem.

The world needs more versatilists if we are to solve the truly wicked problems. Solving wicked problems is one of the things we must do if we are to build a Smarter Planet.

Five Things Not To Say When Presenting

2010-10-31T10:52:00.000Z

Whilst I cannot confess to have never said any of these myself here are five phrases that you should avoid at all costs when delivering a technical (or indeed any) presentation.

I'm sorry you can't see this at the back. Are you really sorry? I suspect not otherwise you will have made sure everyone could see what you are presenting before showing the slide. Know how big your room is and how big the screen is. As a matter of course never make any font size less than 24 point. Better still avoid words altogether and use pictures or diagrams instead.
I'm just going to skip over the next few slides. Why? Either the slides are relevant to what you have to say or they are not. If they are not then they should not be there. There is always a great temptation to include extra slides "just in case". Don't! You should include only that which is relevant to what you have to say and discard everything else.
Sorry but the colours on this slide don't show up very well. Using colour in presentations is a great way of getting across information. When used properly colour can be used for emphasis as well as categorising data or information. However, be aware that the way colour can appear on a computer screen and how it can appear on a data projector can be very different. Always use bold colours and, if possible, check out the projector you are going to use before starting your presentation.
You probably can't hear this but I'll play it anyway. Use of sound and video can be a great way of getting information across and also helps to keep your audiences attention. However if you are using sound make sure you have an effective sound system and don't, what ever you do, rely on the speakers on your laptop. If you are using sound or video make sure there is adequate kit in the room. As a standby carry a set of portable speakers with you but these will only have limited reach.
I've only got 30 minutes and we need t get through 75 slides. Or any other large number that will be impossible in the given time. Actually there is no golden rule for how many slides you can present in a given amount of time. If each slide has only a single word or picture then 75 slides in 30 minutes is entirely reasonable. However most times those 75 slides are densely packed with information which is impossible to assimilate in the amount of time allotted. As I've said elsewhere don't pack too much information into your presentation. Instead just focus on the key points and use handouts for detailed stuff.

Why Didn't I Do That?

2010-10-23T22:49:00.000+01:00

You know how annoying it is when someone does something that is so blindingly obvious in retrospect you ask yourself the question “why didn't I do that”? I'm convinced that the next big thing is not going to be the invention of something radically new but rather a new use of some of the tools we already have. When Tim Berners-Lee invented the world-wide web he didn't create anything new. Internet protocols, mark-up languages and the idea of hypertext already existed. He just took them and put them together in a radically new way. What was the flash of inspiration that led to this and why did he do it and not someone else? After all that is basically the job of a Solution Architect, to apply technology in new and innovative ways that address business problems. So why did Tim Berners-Lee invent the world-wide web and not you, I or any of the companies we work for? Here are some observations thoughts.

Tim had a clear idea of what he was trying to do. If you look at the paper Berners-Lee wrote, proposing what became the world-wide web, the first thing you'll see it has a very clear statement of what it is he's trying to do. Here is his statement of the problem he's trying to solve together with an idea for the solution: Many of the discussions of the future at CERN and the LHC era end with the questions - “Yes, but how will we ever keep track of such a large project?” This proposal provides an answer to such questions. Firstly, it discusses the problem of information access at CERN. Then, it introduces the idea of linked information systems, and compares them with less flexible ways of finding information. It then summarise my short experience with non-linear text systems known as “hypertext”, describes what CERN needs from such a system, and what industry may provide. Finally, it suggests steps we should take to involve ourselves with hypertext now, so that individually and collectively we may understand what we are creating. Conclusion: Having a very idea or vision of what it is you are trying do helps focus the mind wonderfully and also helps to avoid woolly thinking. Even better is to give yourself a (realistic but aggressive) timescale in which to come up with a solution.
Tim knew how to write a mean architecture document. The paper describing the idea behind what we now call “the web” (Information Management: A Proposal) is a masterpiece in understated simplicity. As well as the clear statement on what the problem is the paper goes on to describe the requirements that such an information management system should have as well as the solution, captured in a few beautifully simple architecture overview diagrams. I think this paper is a lesson to all of us in what a good architectural deliverable should be.
Tim didn't give up. In his book Weaving the Web Berners-Lee describes how he had a couple of abortive attempts at convincing his superiors of the need for his proposal for an information management system. Conclusion: Having a great idea is one thing. If you can't explain that idea to others who, for example have the money to fund it, then you may as well not have that idea. Sometimes getting your explanation right takes time and a few attempts. The moral here is don't give up. Learn from your failures and try again. It will test your perseverance and the faith you have in your idea but that is probably what you need to convince yourself it's worth doing.
Tim prototyped. Part of how Tim convinced people of the worth of what he was doing was to build a credible prototype of what it was he wanted to do. Tim was a C programmer and used his NeXT computer to build a working system of what it was he wanted to do. He actively encouraged his colleagues to use his prototype to get them to buy into his idea. Having a set of users already in place who are convinced by what you are doing, is one sure fire way of promoting the worth of your new system.
Tim gave it all away. In may ways this is the most incredible thing of all about what Tim Berners-Lee did with the web; he gave it all away. Imagine if he patented his idea and took a 'cut' which gave him 0.00001¢ every time someone did a search or hit a page (I don't know if this is legally possible, I'm no lawyer, but you get the idea). He would be fabulously rich beyond any of our most wildest dreams! And yet he (and indeed CERN) decided not to go down this path. This has surely got to be one of the all time most altruistic actions that anyone has ever taken.

Architecting Out of the Box

2010-10-15T03:07:00.002+01:00

I got this from a blog by Seth Godin. He was thinking about it in respect of marketers but it so applies to what we do as well.

Most of the time, we (IT architects or anyone else) think of our job as a set of tasks that take place in a box. We take inputs from upstream, add some value(hopefully) and create some outputs that we send downstream.

It turns out, though (according to Seth), that if we go upstream and alter the stuff that comes to us, it's a lot easier to do great work. And if we go downstream and teach people how to work with what we created, the final (work) product is better as well.

Seth gives as an example how a medical doctor can consider her work in the box of the examining room. But if she figures out how to get people to quit smoking before they come in, her results are better. If she figures out how to get people to take their pills after they leave, same thing.

As Seth says “the challenge lies in spending a lot of time and money on the upstream and downstream parts of the work, instead of always assuming that your [box] is just what happens inside your cubicle, or as a direct result of your actions”.

So here's how I would translate this for the humble IT architect:

Visit your business sponsors by walking over to their desk (or calling them up on the phone if they happen to be on a different continent). Talk to them. Ask them what is troubling them today and see how you can help.
Take a long hard look at those requirements and make a point to go back to the person that wrote them if you don't understand them. Don't just assume stuff.
One persons architecture is another ones requirements. What you create will be used by designers and coders to build systems from. Make sure they really understand what you want. Go and visit them (possibly virtually) to see what makes them tick.
Here's a really revolutionary idea. Write some code to a) convince youreself you can remember how to do it and b) show your downstream designers/implementers that you know what you are doing and have some empathy.

Most of what we do all day, intentionally or not, is aimed at keeping us in our boxes. Buck the trend and make an effort to get out of that box and make a difference.

Challenging What Architects Do

2010-10-11T20:24:00.000+01:00

For most of this year I've been fortunate (sic) enough to travel around several countries (and indeed continents) delivering a series of architecture workshops to a client. These workshops aim to teach, through the use of instructor led case studies, best practice approaches to building solution architectures. The workshops take a holistic approach to developing architecture by ensuring both the application as well as infrastructure aspects are considered together and both the functional and non-functional requirements are taken into account.

An enjoyable side-effect of these workshops is I get to meet lots of different people who like to challenge the approach and test my understanding (I sometimes think I'm learning more than the workshop participants). Here's one such challenge (paraphrased) I received recently: “The problem with architects and the work products they produce (for example models built using the Unified Modeling Language) is that the work products become an end in their own right and we can easily lose track of the fact that actually what we want to build is a system with running code on real hardware”. The clear implications behind this challenge could be described via three architecture anti-patterns:

Antipattern: Architecture Overkill. Symptoms: Architects create work that no one understands or cares about. Multiple artefacts with overlapping content get created that no one actually reads. They are too large, too complex and may even be delivered too late.

Antipattern: Ivory Tower Architecture. Symptoms: Architects are out of touch with real-world technical aspects. Instead they just sit in their ivory-towers making their pronouncements (which most of the time no one listens to).

Antipattern: Work Creation. Symptoms: The role of the architect becomes self-fulfilling. They create work products which only they understand and therefore need more architects to help create these work products.

Here's my response:

Any architectural work product needs to have either an up-stream (e.g. to the business) or down-stream (e.g. to the implementers) justification. Each of these groups of stakeholders needs to be able to recognise how the architecture, as encompassed in the work products, addresses their particular concerns otherwise the work product really is only for its own sake. There are other stakeholders who will have interests or concerns in the architecture but I just focus on these to illustrate my point.

The role of the architect needs to be clearly defined and work produced around that role. The role may change as business needs etc evolve but the work created should be in tune with that role and ultimately fulfil the needs of the business. This does not, of course, mean that part of what architects do is research new technology or try out new ideas. Indeed if they don't do this the next point will be tricky to fulfil.

One of the difficulties with the role of the architect is that it can mean the architect easily becomes out of touch with the latest trends etc in programming. This can be caused by a number of things including: architects are paid too much to do programming, architects are too senior to do programming, architects are too busy to do programming etc. This particular problem is particularly endemic in many services organisations where architects may be charged out at premium rates and where the role of programming is seen as almost too “menial”. What to do? It's vital that this is not the case. There must always be time allowed in any software architects work day to stay in touch with the stuff that gives him his reason for being.

Enterprise Architecture is Dead. Long Live Interprise Architecture

2010-10-01T02:37:00.002+01:00

ZapThink have recently been drip-feeding a series of ZapFlashes predicting the end of Enterprise Architecture (possibly allowing them to derive some further consulting/education business by creating a little fear, uncertainty and doubt). Here are some of their predictions and my thoughts. Comments welcome.

The secret to 21st century software innovation. Is, according to ZapThink, in harnessing the power of complex systems (i.e. rather than just enterprise-wide systems). A complex system is one that shows some form of emergent behaviour where the properties of the system as a whole exhibit behaviour that the individual components do not. Most people don't get this confusing systems that are just complicated with ones that are complex. For me this is spot on. As the enterprise morphs into basically the whole of the internet traditional governance models breakdown. The boundaries of the enterprise can no longer be nicely defined and who is in the enterprise and who is not becomes harder to pin down. People who get this and who can successfully harness the “interprise” (my new word of the month) by using the positive effects of social networking etc will win out over the next few years. Of course this involves huge risks not least of which around how will enterprises keep control of their data and intellectual capital.
RIP enterprise software. Enterprise software as provided by the large package providers is seen as large and inflexible and not delivering on the benefits promised by SOA. Companies are finding themselves encumbered with expensive and hard to maintain software they can't “bend” to do what they want. ZapThink's take is that whilst enterprise software may have failed SOA has also failed to deliver on its promise of providing flexible business processes that can be quickly adopted to new needs. My take is that like everything else in our industry nothing is given chance to bed in before the next wave comes and sweeps everyone along with it. Many clients I see are still grappling with getting an effective process in place for developing traditional systems let alone service-based ones and definitely cannot deal with complex systems properly.
The beginning of the end for Enterprise Architecture frameworks. Architecture frameworks (especially enterprise ones like Zachman and DoDAF) are counterproductive to developing an effective EA strategy. These frameworks are inflexible, sometimes encouraging what ZapThink refer to as checklist architecture. Checklist architecture focuses on achieving goals laid down by the architecture framework rather than the changing needs of the business. True but having no framework at all leads to even greater chaos in my experience. A framework is a structure which is meant to contain relevant guidance and work products to deliver real-world solutions. Frameworks that become too theoretical are always doomed to fail as they should. I hope this forms the basis of something more relevant to the real world.

So how would I characterise “interprise architecture”?

Interprise architecture recognises that it is not enterprise architecture that is dead but trying to constrain architecture by the bounds of the enterprise that is no longer achievable. The 'architecture' bit still applies, but not the 'enterprise' bit.
Governance models need to recognise that this extended enterprise includes people and other systems that are not controlled by the IT department (people using social networking software who will periodically 'overlap' with the enterprises systems).
The 'architecture' bit needs to take into account the fact that systems are complex (in the emergent sense of the word) and it's not always possible to tie down the requirements in a nice orderly way. Indeed fully defining the requirements may be counter-productive and not allow emergent behaviour. Processes for developing such complex systems need to take this into account.

To be sure this is not a complete list. This idea is not yet fully-formed in my own mind and needs a bit more time to 'emerge' properly. Watch this space as they say.

Social Networking and All That Jazz

2010-09-27T10:47:00.000+01:00

I was recently asked what I thought the impact of Web 2.0 and social networking has had or is about to have, on our profession. Here is my take:

The current generation of students going through secondary school and university (that will be hitting the employment market over the next few years) have spent most of their formative years using Web 2.0. For these people instant messaging, having huge groups of “friends” and organising events online is as second nature as sending emails and using computers to write documents is to us. How will this change the way we do our jobs and software and services companies do business?

Instant and informal networks (via Twitter, Facebook etc) will set up, share information and disappear again. This will allow vendors and customers to work together in new ways and more quickly than ever before.D
Devices like advanced smart phones and tablets which can be carried anywhere and are always connected will speed up even more how quickly information gets disseminated and used.
Whilst the current generation berates the upcoming one for the time wasted sending pointless messages to friends and creating blog entries hardly anyone reads they at least are doing something different and liberating, creating as opposed to simply consuming content. So what if 99.99% of that content is rubbish? 0.01 or even 0.001 amongst a population of several billion is still a lot of potentially good and innovative thoughts and ideas. The challenge is of course finding the good stuff.

Email as an effective communication aid is coming to its natural end. The new generation who have grown up on blogs, Twitter and Facebook will laugh at the amount of time we spend sweating over mountains of email. New tools will need to be available that provide effective ways of quickly and accurately searching the content that is published via Web 2.0 to find the good stuff (and also to detect early potential good stuff).
More 20th century content distributors (newspapers, TV companies, book and magazine publishers) will go the way of the music industry if they cannot find a new business model to earn money. This is both an opportunity (we can help them create the new opportunities) and a threat (loss of a large customer base if they go under) to IT professionals and service companies.
The upcoming generation will not have loyalties to their employers but only to the network they happen to be a part of at the time. This is the natural progression from outsourcing of labour, destruction of company pension schemes and everyone being treated as freelancers. Whilst this has been hard for the people who have gone through that shift, for the new workers in their late teens and early 20's they will know nothing else and forge new relationships and ways of working using the new tools at their disposal. Employee turnover and the rate at which people change jobs will increase 10 fold according to some pundits (google 'Shift Happens' for some examples).
Formal classroom type teaching is essentially dead. New devices with small cameras will allow virtual classrooms to spring up anywhere. Plus the speed with which information changes will mean material will be out of date anyway by the time a formal course is prepared. This coupled with further education institutions having to keep raising fees to support increasing numbers of students will lead to a collapse in the traditional ways of delivering learning.
The real value of networks comes from sharing information between as diverse a group of people as possible. Given that companies will be relying less on permanent employees and more on freelancers these networks will increasingly use the internet. This provides some interesting challenges around security of information and managing intellectual capital. The domain of enterprise architecture has therefore just increased exponentially as the enterprise has just become the internet. How will companies manage and govern a network most of which they have no or little control over?
The new models for distributing software and services (e.g. application stores, cloud providers) as well as existing ones such as open source will mark the end of the traditional package and product software vendors. Apple overtook Microsoft earlier this year in terms of size as measured by market capitalisation and is now second only to Exxon. Much of this revenue was, I suspect, driven by the innovative ways Apple have devised to create and distribute software (i.e. third parties, sometimes individuals create it and Apple distribute it through their App store).

For two good opposing views on what the internet is doing to our brains read the latest books by Clay Shirky and Nicholas Carr.

Six Non-IT Books for IT Architects

2010-09-20T16:23:00.001+01:00

There are now several myriad books out there on the topic of software architecture, including this one I have contributed to. There are other skills an architect needs to do their job which are not just to be found in IT books however. Here are six books which have helped me in my job together with a few reasons why I think they are useful:

Change by Design by Tim Brown. Tim Brown is the CEO of IDEO a design company based in Palo Alto, California. Introduces the concepts of "design thinking" that can be applied to any problem and shows how empathy, play, storytelling and prototyping can all be bought together in coming up with new and innovative designs. Top tip: Deploy interdisciplinary teams of multi-talented people (i.e. true versatilists) to solve hard design problems. Even if you don't get the book at least visit the link I've given to view the wonderful mid map.
Presentation Zen by Garr Reynolds. Garr is the master of giving advice on how to create simple, clear and relevant presentations. Here he applies the zen principles of simplicity that will change how you think about creating presentations using PowerPoint or Keynote. Top tip: Picture superiority effect. Pictures are remembered better than words. Humans are hardwired for using images to communicate. Go visual wherever and whenever you can.
A Whole New Mind by Dan Pink. Dan describe how, if we are to survive in the 21st century world of work, we must make more use of the left side, the creative side, of our brain rather than the traditional right (logical thinking) side. Top tip: Use stories to help illustrate your ideas. Stories represent a pathway to understanding that doesn't run through the left side of the brain.
Notes on the Synthesis of Form by Christopher Alexander. Alexander recognises that problems come with multiple, poorly understood requirements that interact with each other, creating conflicts and contradictions. Something we in IT have known for years. This book describes an approach for dealing with often multiple conflicting requirements to come up with the "best fit" solution. Top tip: It is difficult to specify a complete set of requirements that need to be met to achieve a "best fit". A practical approach is to define 'good fit' as the absence of 'misfits', since these are usually what makes the problem obvious and can be ascertained through inspection of prior designs. Although designers may argue over the importance of a particular misfit, they are less likely to disagree on whether the misfit exists.
Ignore Everybody by Hugh MacLeod. Hugh is an artist that makes a living creating art on the back of business cards, selling wine and running an extremely insightful web site on applying creativity to help you improve your job as well as your life. Top tip: Don't try to stand out from the crowd, avoid crowds altogether.
The Presentation Secrets of Steve Jobs by Carmine Gallo. Great book with lots of example on how Steve Jobs creates, prepares for and delivers his presentations to introduce new Apple gadgetry on the world. Top tip from book: Use plain English and photographs rather than techno mumbo-jumbo and slides densely packed with indecipherable text and bullet points.

When Systems Fail

2010-09-16T08:14:00.001+01:00

This week I was a direct victim of a systems failure that set me thinking about how even mundane activities that we have been doing for several tens, if not hundreds, of years, like checking into a hotel in this case, rely on systems that we take for granted and which, when they fail, throw everything into complete chaos.

It's a long and not particularly interesting story but in summary I checked into one of the large chain hotels, which I use a lot, only to find when I opened my room door that the room was in a state of complete chaos and had clearly not been visited by housekeeping that day. On trying to change to another room I was told the system had been down since 4am (it was now 8pm) that morning and the staff could not tell what state rooms were in. Clearly not a great state of affairs and not great for client relations (there were a lot of grumpy people queueing in reception, some of whom I would guess would not be going back to that hotel). So what would an architect of such a system do to mitigate against such a system failure?

I don't profess to know too much about how hotel management systems work and whether they are provided centrally or locally however I would have thought one of the basic non-functional characteristics of such systems would have been a less than one hour recovery following a system failure (not 16 hours and counting). Learning point: Clarify your availability non-functional requirements (NFRs) and realise them in the relevant parts of the system. Maybe not all components need to be highly available (checking in a customer maybe more important then checking her out for example) but those that are need to be suitable 'placed' on high-availability platforms.
There was a clear and apparent need for a disaster recovery plan that involved more than the staff apologising to customers. Learning point: Have a disaster recovery policy and test it regularly.
A system is about more than just the technology; the people that use the system are a part of it as well. Learning point: The architecture of the system should include how the people that use that system interact with it during both normal and abnormal operating conditions.
Often NFRs are not quantified in terms of their business value (or cost). When a problem occurs is the impact to the business (in terms of lost revenue, irate customers who won't come back etc) really understood? Learning point: Risk associated with not meeting NFRs needs to be quantified so the right amount of engineering can be deployed to address problems that may occur when NFRs are not met.

Formal approaches to handling non-functional requirements in a systems architecture are a little thin on the ground. One approach suggested by the Software Engineering Institute is through the use of architectural tactics. An architectural tactic is a way of satisfying a desired system quality (such as performance) by considering the parameters involved (for example desired execution time), applying one or more standard approaches or patterns (such as scheduling theory or queuing theory) to address potential combinations of parameters and arriving at a reasoned (as opposed to random) architectural decision. Put another way an architectural tactic is a way of putting a bit of “science” behind the sometime arbitrary approach to making architectural decisions around satisfying non-functional requirements.

I think this is a field that is ripe for more work with some practical examples required. Maybe a future hotel management system that adopts such an approach to during its development will allow a smoother check-in process as well.

New Dog, Old Tricks

2010-09-13T22:55:00.000+01:00

I can't believe this but today I have observed no less than three people using the latest wonder-gadget from Apple (the iPad) to play solitaire, Tetris and some other game which seemed to involve nothing more than poking the screen at moving shapes! Having just bought my own iPad and being convinced it conforms to Aurthur C. Clarke's third law (any sufficiently advanced technology is indistinguishable from magic) I am aghast that such a technological wonder is being used for such mind numbing activities; just dust off your ZX Spectrums guys!

The Three C's of IT Architects

2010-08-30T11:04:00.001+01:00

This is a completely unscientific observation but over the years of being an architect I have observed the following characteristics in people that claim to be members of this profession. I refer to these as the three C's of being an IT architect. Some people have only one of these but most have a mix of all three, with maybe one being dominant. The three C's are:

Creatives – These are the ideas people, that are keen to do new stuff. They are the people that build the solutions that address the business requirements. They have an intimate knowledge of technology (in their particular area of interest or concern) and want to use that technology. If you don't have these people in your project/team/organisation then nothing will actually get done. The downside of having too much of this attribute is that eventually you have to stop creating and ship something so you need to know when to stop.
Consumers – These are the people that use what the creatives create. Whilst they may not create anything new this type of architect is not without merit. They often combine what others have done in new and innovative ways. We sometimes refer to this activity as reuse, one of the Holy Grails of IT so it is not to be underestimated. If you don't have these people in your project/team/organisation then chances are the ideas from the creatives will not get fully realised. The downside of having too much of this attribute is that there is a limit to what you can build out of reusing stuff and eventually someone has to come up with some new ideas.
Connectors – These are the people that don't create or reuse but know people that can do these things and join the two together. Again this is not to be an underestimated skill. After all if a seller cannot find a buyer what's the point! If you don't have these people in your project/team/organisation then the two previous types won't find each other. The downside of having too much of this attribute is that you ain't going to do anything if all you do is push ideas of others around without creating or reusing things.

From my observations I reckon a ratio of Creatives to Consumers to Connectors needs to be something like 4:2:1.
Incidentally, my guess is that these actually apply to other professions as well but I have even less scientific evidence about those.

10 Things I (Should Have) Learned in (IT) Architecture School

2010-08-27T22:04:00.000+01:00

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.

Default Architecture

2010-08-18T11:22:00.000+01:00

One of the attributes that many (if not all) complex systems have is the ability to change (customise) them in controlled ways. Indeed this, by definition, is why some systems are complex (that is exhibit emergent behaviour) because sometimes the users of those systems select options or make choices that enable unexpected behaviour to occur. Giving users such choices clearly has a number of implications on the architecture of a system.

Users have to make a choice, no choice is actually a choice itself as it means they are choosing the default.
Making systems customisable assumes users have the will (and the time) to decide which options they want to change. Many times they don't so the default becomes very important as it will dictate how the users actually use the system, possibly forever.
The more options that are built into a system the more difficult it becomes to test each potential combination of those options. Indeed there comes a point at which it becomes impossible to test every combination (at least in a reasonable amount of time), hence the importance of beta software (let the users do the testing).

In his blog entry Triumph of the Default Kevin Kelly points out how “the influence of a default is so powerful that one single default can act as a very tiny nudge that can sway extremely large and complex networks”. The oft quoted example of how defaults can influence behaviour is that of organ donation. If you make the donation of organs upon death automatically an "opt out" choice (it happens unless you refuse beforehand) versus "opt in" (it does not happen unless you sign up). A opt out donor system greatly increases the number of organs donated.

For complex systems then, the default architecture of the system becomes very important. The choices the architect makes on behalf of the users of that system will not only dictate how the users will actually use the system but may also influence their behaviour (in both positive and negative ways). Defining the defaults is as important an architectural decision as to what technologies should be used and sufficient time should always be planned in to allow such decisions to be made in a sensible way. The system architecture that results can profoundly affect how that system will be used.

Evolutionary Systems Development Process

2010-08-05T21:57:00.000+01:00

As I'm now into my second year I reckon I can become more experimental in my blogs. This entry is therefore completely off the scale and will either not go any further or be the start of something much bigger. Comments suggesting which it is are welcome.

If we want to be able to build real complex systems (see previous entry for what these are) what might we do differently to ensure we allow truly emergent properties to appear? Is there a development process that we could adopt that both ensured something was delivered in a timely fashion but that also allowed sufficient 'flex' such that emergent behaviour was not prevented from happening? In other words is it possible to allow systems to evolve in a managed way where those properties that we value are allowed to grow and thrive but those that are of no use can be prevented from appearing or stopped early on?

Here are some properties I think any such a development process (an evolutionary systems development process) should have if we are to build truly complex systems

The process needs to be independent of any project. Normally we use processes to derive some kind of work breakdown structure which is used to plan the project that will deliver the system. In other words there is a well defined start and end point with clear steps stating who does what by when in between. However for a complex system there is by definition no stopping point; just a number of evolutions where each introduces new (and possible unpredictable) behaviour.
The process should be driven not so much by what users want but by what users do. Most processes start with a list of requirements, possibly expressed as use cases, which describe scenarios for how the system will be used. The problem with this approach is that use cases only describe what a user can envisage doing with the system and will not capture what they actually end up doing with the system. In other words the system is deemed to be 'complete' once all the use cases have been realised. However what if the act of delivering the system itself results in new use cases emerging. Ones that were not planned for? How do they get realised?
The process must be both flexible enough to allow users to experiment and envisage doing new things whilst at the same time being robust enough not to allow negative emergent behaviour that will prevent any system being delivered or lead to the system deteriorating over time.
If new behaviour is to be adopted this must be of overall benefit to the majority and must still meet (a possibly changed) set of business objectives. The process must therefore allow for some kind of voting system where the majorities behaviour is allowed to dominate. The trick is not allow new and innovative behaviour to be crushed early on.
The underlying rules that control how the systems responds to external stimuli must themselves be easily adaptable. The process must therefore treat as peers the rules that govern (allowable) behaviour together with the description of the behaviour itself. Rules set some kind of constraint on what is allowable and not allowable by the system.

Of course not all systems that we build will or should be complex ones. As noted previously safety-critical systems need to behave in entirely predictable ways and users should not be allowed to change the behaviour of these where lives could be put at risk. So what type of systems might benefit from an evolutionary approach to development?

Social networking systems where the users are intimately bound up with the system itself.
Commerce systems where the buying behaviour of users might change how and when certain products are sold and at what price.
Financial systems where money markets may affect what users do and how they respond.
Government systems where responses to new legislation or the behaviour of citizens needs fast responses.
Other, you decide?

My next step is to think about what the elements (process phases, work products etc) of an evolutionary systems development process might be.

One Year Old Today

2010-07-28T09:00:00.004+01:00

Hey I'm one year old today, well my blog is. Here's a wordle image of what I've been talking about after the last year. Interesting that 'design' is bigger (i.e. discussed more) than 'architecture'.

Software Architecture Zen

Its Pretty Interactive, Yeah

You're Building Me A What?

On Being a Versatilist

What Now for Internet Piracy?

Architecting Out Complexity

Architecting and Social Media

Computing: The Human Experience

Social Objects as Instruments of Architecture

Educating an IT Workforce for the 21st Century

Parkinson's Law of Triviality (Applied to Architecture)

What Can Architects Learn from Steve Jobs

Creativity at Scale

Five IT Trends for Architects to Ponder

Blackberry's Perfect Storm

Steve Jobs 1955 - 2011

Reusable Assets for Architects

Plus Two More

Five Architectures That Changed The World

Emergent Architectures

What Would Google Do?

Creative Leaps and the Importance of Domain Knowledge

On Being an Effective Architect

Happy Birthday WWW

The Tools We Use

Oh Dear, Here We Go Again!

The Innovation Conundrum and Why Architecture Matters

A Service Based Development Process - Part 4

A Service Based Development Process - Part 3

A Service Based Development Process - Part 2

A Service Based Development Process - Part 1

Keeping Your Creative Mojo

How to Avoid the Teflon Architecture Syndrome

Is Designing an Architecture an Oxymoron?

The Legacy Issue

Ethics and Architecture

The Essence of Being an Architect

Sketching with the UML

Change Cases and the Limits of Testing

Architectural Granularity

EA Wars

Applying Architectural Tactics

Oops There Goes Our Reputation

Open vs. Closed Architectures

It's Only Television But I Like It

On Lego, Granularity, Jamie Oliver and Architecture

Skills for Building a Smarter Planet

The Next Generation?

Is Agile Architecture an Oxymoron?

Forget T-Shaped, We Need V-Shaped Architects

Watson, Turing and Clarke

Think Like An Architect

How Much Does Your Software Weigh, Mr Architect?

Learning Architecture (Or Anything really)

2011 Architecture Survival Guide

Software Developments Best Kept Secret

Architecture is Architecture?

On Being a Software Architect

You Can No Longer Call Yourself an Architect When...

More Presentation Tips from the Frontline

Interprise Architecture and Ultra-Large-Scale Systems

A Tale of Two Cities

Architecture Drill Down in the UML

Five Inspirational Videos

Hire an Architect

When a Bridge Falls Down is the Architect to Blame?

On Being a Versatilist

Five Things Not To Say When Presenting

Why Didn't I Do That?

Architecting Out of the Box

Challenging What Architects Do

Enterprise Architecture is Dead. Long Live Interprise Architecture

Social Networking and All That Jazz

Six Non-IT Books for IT Architects

When Systems Fail

New Dog, Old Tricks

The Three C's of IT Architects

10 Things I (Should Have) Learned in (IT) Architecture School

Default Architecture

Evolutionary Systems Development Process