Interprise Architecture and Ultra-Large-Scale Systems

December 7, 2010April 4, 2014 Peter Cripps architecture gartner, interprise architecture, mark zuckerburg, sei

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

December 4, 2010April 4, 2014 Peter Cripps architecture bengalaru, enterprise architecture, singapore

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

November 22, 2010April 5, 2014 Peter Cripps architecture grady booch, ibm, rational, sparx, uml

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

November 15, 2010April 5, 2014 Peter Cripps comment david eustace, five things, grady booch, ken robinson, lady gaga, steve jobs

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

November 14, 2010April 5, 2014 Peter Cripps architecture seth godin, tim berners-lee

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?

November 11, 2010April 5, 2014 Peter Cripps architecture non functional requirements

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).

Versatilism and Wicked Problems

November 5, 2010April 5, 2014 Peter Cripps architecture, creativity versatilist, wicked problems

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

October 31, 2010April 5, 2014 Peter Cripps presenting five things

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?

October 23, 2010April 5, 2014 Peter Cripps architecture, creativity five things, tim berners-lee

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.

Software Architecture Zen

The musings of a technorealist

More Presentation Tips from the Frontline