Review: Learning From Five Years as a Skype Architect

There is an excellent presentation Andres Kutt recorded at QCon London 2010 about lessons learned from working for fives years as an architect within Skype. Here's the link and full description:

http://www.infoq.com/presentations/Learning-from-Five-Years-Skype

"Andres Kutt discusses his experience as architect at Skype for five years, sharing some of the lessons learned: rules of thumb do not always apply, functionality is important, use simple solutions, buzzwords are dangerous, the architecture needs to fit into the organization, and communication is important.

Bio
Andres Kutt has been with Skype since 2005, leading a growing team of architects. Before that, he worked as IT Deputy Director General for the Estonian Tax and Customs Board, and as a free consultant for financial institutions."

Review
I love his comment at 36 minutes that "80% of what an architect does is communicate". This is so true and important to realize, but not all architects excel at communication. This can cause significant problems on projects. As a steward of the conceptual and functional integrity of a system, the architect must strive to understand and distill the core standards, interfaces, components, connectors, and unifying concepts of the system to the rest of the technical team. They also must be able to speak to business people and other stakeholders using non-jargon language that speaks to the underlying concerns of budgets, ROI, risk management, etc.

Key Points

•  Rules of Thumb Do Not Apply
• His example is that he joined Skype with the belief that "You do not put business logic in the database", but he learned about the Postgre database Skype uses and the distributed cluster and how the team there actually modified the Postgre source code to suit their needs. As a result, he no longer worries about business logic in the database.
• Functional Architecture is Important
• He says that at least every nine months he gets the whole team together to sit down and all diagram the architecture together and find the problems and fix those problems by analysis and refactoring.
• Usually the architecture remains the same, but they fix problems and remove single points of failure.
• Unfortunately, he says, many times architects get caught up in the finer grained details of technical implementation architecture.
• In his experience, ugly functional architecture always leads to ugly technical architecture.
• Simple things work.
• "When something takes more than three sentences to explain, it usually doesn't work"
• "Always remove all the functionality that is not necessary"
• "Always chop things up"
• He gives the example of SOAP being bloated and overly complicated. Instead of SOAP, Skype uses REST.
• Complicated things do not work well.
• He says if you're architecture is getting too complicated you are doing something wrong.
• Buzzwords are dangerous.
• His example is "Cloud Computing"
• Instead of resorting to "buzzwords" or being either awed or fearful of them, seek to understand the motivations behind buzzwords when people use them. What benefits are they interested and what about that buzzword makes them think it will deliver those benefits?
• You are there to solve business problems, not the most beautiful, perfect system ever.
• He says to not take on technical debt that will cripple the business.
• Talk to people in order to understand and discover requirements
• Don't expect them to trust you or your team without you trusting them and the business goals they have.
• Also do not expect teams to magically understand requirements if they are not also talking with product folks.
• UML diagrams do not help much

Comments
The observations Andres makes are right on the money. I've been on so many projects, or went through periods of time on projects, where it seemed like too much management was going on. Managers, by their nature, desire to control and predict everything. They often feel that by limiting the time that one "role" of person, be they BA, QA, TA, DEV, PO, etc need to talk to each other the better the results "should be" and the faster functions "should" get delivered. These managers tend toward thinking of a "pipeline" mentality, such as:

1. Product Owners and Business Analysts, with the assistance of Technical Architects define functional requirements
2. Developers and QA then create tasks and test cases to implement these.
3. And, while the Developers and QA are working, the PO, BA, and TA continue to work on "what's coming next".

While it is a natural and admirable goal that the firsts step above should produce requirements documents and wireframes that are perfectly defined and perfectly refined state of readiness for Developers and QA to implement, it seldom happens this well.

Scott Ambler has a great chart about communications in software projects in this article: http://www.agilemodeling.com/essays/communication.htm.

For me personally, I saw this recently in a project. We were facing several "unknowns" in our requirements that were effecting me and other developers. We quickly gathered several developers, QA folks, and business analysts together. We had started with a whiteboard, getting everyone to focus on shaping the common language and understanding of the problems at hand, but quickly moved to a notepad instance and simple bullet lists. Everyone quickly reached consensus within five minutes of discussion. We all walked away with a common understanding and greater confidence in the requirements.