How to Architect For Web 2.0 – 3 Postulates and 10 Must Dos

Web 2.0 may not have a clear-cut definition but irrespective of which way you look at it (there are 3 different ways of looking at web 2.0), it is about the behavior of complex system, it is about collective intelligence and it is about emergence. The fundamental principles governing such systems are that the whole is much more than the sum of its parts – the behavior of the system cannot be derived or understood by analyzing individual elements.

Traditional approach to architecting and problem solving is to…

  • Look at the problem as a whole
  • Break it down to multiple sub-problems
  • Solve each sub problem separately
  • Put individual solutions together
  • Expect the whole problem to be resolved

This approach does not work for complex systems

and

Web 2.0 always deals with complex systems

So when dealing with such systems, as an architect, you need to modify your approach.

Postulate [1] – Any Web 2.0 success will always be unexpected

If you look at all the big web 2.0 success you will find that all of them (Google, Wikipedia, Facebook, Twitter …) have defied conventional wisdom. The chances are high that your web 2.0 success will happen in an unexpected way.

Must Do #1 – Let the Architecture Evolve

It is impossible to design for the unexpected. Only thing you can do is to move forward incrementally – always adjusting your architecture to the new reality – paying your technical debts regularly.

Must Do #2 – Adopt Agile Methodology

Agile methodology intimately connected to emergence – if you are not into agile don’t even come near web 2.0.

Must Do #3 – Opt for Loose Coupling and Simplicity of Interface

Only loosely coupled system can quickly evolve – only simple interfaces get widely used.

Must Do #4 – Implement Bottom-Up

The trick is to identify small successes – nurture them – adapt your system to help them proliferate.

Must Do #5 – Resist Temptation to Control

We have the inherent urge to control event which does not go according to our plan – but for web 2.0, such events may be the seeds of success.

Postulate [2] – Web 2.0 – more often than not – is about customer

Chances are high that as an architect you would want to distance yourself from selling & marketing. Unfortunately, web 2.0 is intimately connected with customer (existing & prospective) behavior – and the money for such project is likely to come out of marketing budget.

Must Do #6 – Think Customer Centric

There is clear evidence that improving customer experience can improve customer loyalty – therefore you need to tune the architecture keeping the customer at the centre (not the organization).

Must Do #7 – Learn Marketing Terminology

Marketers have spent their whole carrier trying to understand customer behavior – to architect for web 2.0, not only do you need to understand how traditional marketing works – you also need to understand and speak marketing language.

Postulate [3] – Underlying technologies of Web 2.0 is changing fast

There always will be hype around new technologies – not all of them will live up to that hype. However, once in a while, a new technology comes in and creates a paradigm shift in how & what we do. When such a thing happens, we call it an Inflection Point – there is a good chance that we are just about to reach one.

Must Do #8 – Design for Multiple Channels

Customers expect logically consistent (not necessarily identical) experience across multiple channels. BTW – Multi-channel is not just smart phone, many other types of devices and appliances are evolving (have you looked at Sixth Sense?). In fact even web is no longer a single channel – you need to look separately at Aggregators, Social Networking Sites, Micro Blogging…

Must Do #9 – Understand Cloud – Especially Google App Engine

In one sense, cloud is just an extension of virtualized hosting solution but 3 distinct cloud strategies are in vogue. However, do look at Google App Engine – though it is still work in progress – it has the potential of altering the economics of IT.

Must Do #10 – Think Beyond RDBMS

Have you heard of No SQL movement? Check it out – have a look at Big Table.

Brain cells are in billions but the interconnections are in trillions – our intelligence – collective intelligence of any complex system is derived from the number and quality of interconnections. So, architecting for interconnections is the key to success!

Advertisements

Architecture World’09 – Pune

Good arrangements – I liked it more than the Bangalore event. Let me highlight 3 points from this event which can provide you with some food for thought.

1. Look at the list of speakers & panelists – you notice anything interesting?

If we discount the people from IT/Consulting companies (17-7=10) – Telecom accounts for 30% (3/10) of the remaining speakers. No other industry segment had more than one.

Sunil Dutt Jha – iCMG, Shirish Patwardhan – KPIT Cummins, Upal Chakraborty – DLF Limited, Amar Kumar Pandey – IG Police, Manish Gupta – Healthcare Global. Manoj Deshmukh – Fiserv Global Services, N Nataraj – Hexaware Technologies, Parag Matapurkar – Capgemini, Sanjay Marathe – Zensar Technologies, Manoj Shrivastava – Reliance ADA Group, Hiren Shah – CRISIL, Meenakshi Vajpai – Bharti Airtel, Steve Towers – BP Group, Tamal Chakravorty – Ericsson India, Abhay Chitnis – L&T Infotech, Suryanarayanan – NSR Centre for Entrepreneurial Learning, Udayan Banerjee – NIIT Technologies

It is not really surprising because Indian Telecom industry …

  • …is among the largest in the world
  • …is also the fastest growing in terms of absolute numbers
  • …because of the size and rate of change has to deal with a level of operational scale and complexity not seen anywhere else in the world except China
  • …has to depend on IT to operate effectively
  • …needs an IT infrastructure with a scalable architecture capable of handling the scale and the growth
  • …has architectural experience to share with other industry

Therefore – other industries have a lot to learn for Telecom.

2. The panel discussion – “Are Indian Software Architects as competent as the western counterparts?” had an interesting twist.

There were five of us of Indian origin and Steve was the lone person of non-Indian origin. All five of us kept pointing out our shortcomings but Steve compared current Indian IT scene with that on Japanese car manufacturing industry of the sixties – how they started with imitation but went on to become world beater.

Therefore – question is how can we learn for Japanese auto industry?

3. Finally, in spite of what Sunil and Manoj had to say, comparison between IT architecture and civil architecture is both inaccurate and misleading.

Though this topic will need a separate post – here are some of the points.

  • Look at the definition of Civil Architecture (…design and construction…) and Software Architecture (…externally visible properties of those components, and the relationships …) from Wikipedia – they are not comparable.
  • Civil Architect, using past knowledge, creates a blue print or model of what needs to be constructed – in software that activity is called design
  • The rate of change of this knowledge and the underlying technology for Civil Architects is measured in terms of decade – but similar change happens in software in years –significantly reducing the possibility of reusability (see this – When Is Reuse Feasible?)
  • Civil Architects deals mostly with static characteristics – but any IT or software design is mostly about dynamic behavior
  • Once constructed the buildings, roads, bridges do not change much – but any IT system evolves and may become unrecognizable from its original version after a few years

Therefore – we need to look at biological systems for inspiration which grows and evolves.