InfoQ Video – Learnings From Five Years As Skype Architect

I came through this interesting video where Andres Kutt as a architect at Skype talks about his learnings while being a part of the architecture team. His presentation is categorized in two sections – technical and non technical learnings. He starts off mentioning that non-technical learnings are more important then technical ones :). Some of the highlights are

Technical Learnings

1. Rules of thumb do not apply always – Here he mentions an example about a pattern of not putting business logic in database. This being a commonly known pattern but it should not be applied always. Business logic can be added into the database provided you have a right DBA (database base administrator’s) and right tools. He details on this point by talking about Postgre database.

2. Functional architecture is important – A poor functional architecture always leads to poor technical architecture.

3. Simple things work – Here Andres takes an example of SOAP. Because SOAP is too complex, the architecture decided to use REST instead.

Non technical learnings

1. Buzzwords are dangerous – The architect is responsible to understand the problem and see if the buzzword (like cloud computing, SOA, agile etc) spoken off by anyone (for e.g. the management team) actually solves this problem. The architect should think what the buzzword means in the context of your organization. SOA at facebook would mean completely different to SOA at eBay.

2. Architecture needs to fit your organization – The peer-to-peer architecture used by Skype is preety complex, it needs very skilled developers to develop it and has various other problems but because it fits the business model, the architects at Skype chose it. For example, the volume of the video calls our users make is in the same order of magnitude as YouTube video traffic. Due to the peer to peer architecture, none of it ever touches a single piece of hardware paid for by Skype. Changing that would most certainly mean an end to free video calls on Skype which in turn would effectively mean an end to our non-subsidizing premium business model. In summary, all of your architectural decisions need to be made in the context of your organization and not in the context of your own preferences.

3. Communication is important – In addition to thinking about the software’s architecture, scalability, performance etc an architect have a couple of more responsibilities. It’s an architects job to communicate the software’s architecture to the developers. If it’s not communicated, one cannot hope to have it implemented. An architect should also act as a middle layer between the business analysts and the development team.

At the end Andres details on a good point – Your architecture should be such that it fits the developers in your organization. An architecture which works with one team may not work with another team and because of this he stress on the point that communication is very important.

Hope you too enjoy this video/article.

Advertisement