World Famous Architectures : Facebook, WhatsApp, Amazon, Twitter, YouTube, Google, ESPN, Salesforce, FarmVille and other world famous architectures

Experience is the biggest teacher, and no books or coaches can be a better teacher than learning from experience. We often hear from various sources in the professional world around us, regarding different architecture designs and practices, and still most of us would have inevitably attended a performance optimization training at least once in the past 2-3 years.

In my opinion, if you want to really learn scalability and performance, just take a look at the below mentioned top architectures of the world. I bet, if you can follow and implement even any two of them to the extent they have been by these organizations, you are set to build a new world famous architecture.

1) WhatsApp Architecture

2) Flickr Architecture

3) Amazon Architecture

4) Stack Overflow Architecture

5) Google Architecture

6) YouTube Architecture

7) Pinterest Architecture

8) Twitter Architecture

9) Instagram Architecture

10) Facebook Architecture

11) Akamai Network Architecture with 100K servers

12) TripAdvisor Architecture

13) Prismatic Architecture

14) Salesforce Architecture

15) Mailbox Architecture

16) Cinchcast Architecture

17) Stubhub Architecture

18) ESPN Architecture

19) AOL Architecture

20) Netflix Architecture

21) DataSift Architecture

• DataSift Big Data Architecture Diagram
• Big Data Architecture Details

22) Justin.tv Architecture

23) Playfish Architecture

24) FarmVille Architecture

25) Klout Architecture

SSRS reports on iPhone, iPad, Android, Windows Mobile for Mobile UI

Viewing applications on mobile devices might sound like a small problem statement, but the actual solution requirement is much broader than just resolution adjustment. Some of the major challenges involved in the solution architecture are:

1) Single codebase for the model and controller layer, and using the same for creating different view layers for different devices and platforms.

2) Whether to create a webapp optimized for devices or whether to create a native application that calls webservices / displays web content.

3) HTML5 is supported in different capacities by different browsers, and most of the microsoft frameworks do not emit HTML5 by default. In fact features like local storage is not supported below IE8+. Also its quite heavier to use as the data exchange format for devices, compared to JSON.

4) Whichever framework is used, cross-browser compatibility is always an implicit / explicit business mandate.

5) Using same navigation design, for different sized devices like iPhone, iPad, Tablets and Desktops, would not be admired by users from a usability and user experience perspective.

6) REST based services are more faster and lighter to use compared to WCF based webservices. But WCF has got a very wide support, features and integration with .NET.

Below are some pointers that can be kept in mind while designing the solution / technology architecture:

1) HTML5 is supported by most modern browsers used on different devices. Creating a web application with HTML5, CSS3 and JavaScript is the most advisable step if you are completely inexperienced in mobile application development.

2) Web-based frameworks like jQueryMobile, Sencha, and Dojo can leverage the existing web based SDKs / codebase to build more sharper mobile applications in faster, easier and efficient manner. These frameworks have built-in libraries to use REST and JSON too for client-server communication. Even if web application is converted native application in the future, http/rest/json based communication protocol is supported by platforms like android, iOS and others.

3) To take your web application development framework to the next level, use frameworks like appMobi, Appcelerator, PhoneGap, ApplicationCraft and others to build native applications using JavaScript.

4) More about how to build iOS application from scratch can be read from here.

I have implemented architectures, where we create .NET user controls that makes programmatic calls to SSRS webservice for reports execution. The HTML output returned by SSRS report is collected and rendered in the control. These controls are hosted in .NET pages, which are hosted on Sharepoint. Finally when server leaves control, entire web content gets transmitted as HTML. By introducing HTML5 conversion wrappers at different layers depending upon the design of the solution, not only SSRS reports but any web application can be optimized for mobile devices.

There is lot more to consider like performance, navigation design, user experience, local data storage and others such points. Feel free to share your thoughts and experiences by commenting on this post.

iOS integration with MS BI Solution Architecture

In my career experience, reporting has been the biggest piece of any solution. Mobile applications owns a large stake these days as an end-client application. Web is thought to be the ultimate platform for exposing your applications, but native applications that sits on mobile computing platforms like Android and iOS are huge stakeholders in the reporting consumers ecosystem. Benefits of web applications versus mobile platform native applications is a huge topic in itself, and demands a dedicated post.

As an architect, recently I have been given the helm of delivering an MS BI solution. The application has to be delivered as an iOS / OS X native application and the end clients have iPad and this application should be available as a native application on the same. Generally professionals with an architect cap, try to escape from the intrinsics of technology but in most of the cases I have seen that such professionals are not the dark horses of this game. If you give an attitude that I am an Architect (thou not an enterprise architect but just architect of your 2-3 applications) so I don't know anything about technology stack and nor can I analyze the skeleton of different technologies, then any business would want such professionals only on contract for the shortest time possible.

If you understand the entire different kinds of technology stack skeleton, you would be able to integrate your solution with joints of steel, and that is your job as an architect. Quick points that an architect would be interested in knowing about iOS world are listed below, which would help any architect to get a quick launchpad about iOS world of native applications. 

1) If you have made up mind to develop web applications that can target a variety of mobile devices, you can use native wrapper classes using frameworks like Adobe PhoneGap.

2) App Store and iTunes are great examples of native applications displaying web content inside it.

3) XCode is the SDK from Apple used to develop applications for iOS platform.

4) Most of the iOS applications are implemented using MVC design pattern.

5) Objective-C is the programming language used to develop applications, and its quite similar to C# too.

6) Interface Builder is the IDE that is used to develop application user interface and associate code with the UI. A simulator designer is provided inside this IDE.

7) Automatic Reference Counting (ARC) is the garbage collection mechanism of the iOS platform.

8) TableViews can be thought of synonymous to .NET configurable data grids.

9) Depending upon the complexity of the screen there are different kind of projects template available in XCode. For single screen apps one can use project types like "Utility Application" and for more complex apps that require different screens can use "Tabbed Application".

10) Different applications are targeted for different devices like iPhone and iPad. "Master-Detail Application" is a project type that would work seamlessly on iPhone as well as iPad.

11) Its possible to embed web content inside the application. UIWebView class would be a quick starting point to begin your base technical framework.

12) View Controllers can be considered synonymous to specialized controls that are aimed at specific tasks.

13) API to make calls to webservices synchronously and asynchronously is available in XCode SDK.

14) JSON (JavaScript Object Notation) is advisable to use for data exchange instead of XML. JSON is data exchange format, that is light-weighted, partly human readable, and consumes almost half the bandwidth compared to XML for the same size.

15) SQLite is the database management library and also supported by iOS SDK to store data on the device. Apple Mail itself uses the same.

16) iPad screen have 1024 * 768 pixel resolution at 132 pixels per inch, which is a good screen resolution to develop interactive applications.

17) iOS apps can use iCloud to enable different instances of their application to interchange data. Entire user data that sits in the "Documents" directory of the device, is backed up on iCloud daily.

18) iCloud has two types of storage: key-value storage for small amounts of data and document storage for larger volumes of data.

19) iOS applications are packaged as iOS App Store Package (.ipa) file. For internal beta distribution, applications can be distributed via ad-hoc method or ad-hoc (OTA) over-the-air method. Others third-party methods like TestFlight and BetaBuilder for iOS can also be used. Generally enterprises develop internal Enterprise Application Catalog (EAC) for mobile application distributions for company provided devices to download and install these applications. So this is also a good medium to publish your mobile applications.

20) Finally you have to submit your application to App Store team, if you intend to publish your application for iOS devices globally. It goes through a review and approval process from the same team, and they have their own set of standards for approving the application.

21) Important Apple Websites:

• iOS Dev Center
• iOS Provisioning Portal
• iTunes Connect
• Developer Support Center
• App Store Resource Center 

Architecture Design Tools for MS BI

I got married last month, just returned from my honeymoon and catching up with the workload and routine life. Visual Studio 2012 got RTM and can be downloaded from here. Some of the new enhancements introduced in VS 2012 caught my attention and I find it really impressive.

One of the famous tools for architecture design modeling has been Enterprise Architect. Generally the gap between an architect and design (physical and/or logical) and development team is created by the tooling platform they use for their own set of works. Out-of-box you don't find an integrated platform that bridges deliverables of an

• Architect i.e. Layered Architecture Diagram(s)
• Design Team i.e. Class / Entity / Workflow Diagram(s)
• Development Team i.e. Code modules

Lineage tracking across these artifacts using an integarted tool can keep the solution totally in place. VS 2012 diagramming features provides exactly the same. Check out the following videos to get a quick overview of those features.

1) Visual Studio Premium and Ultimate 2012: Improving architecture through modeling

2) Visual Studio Ultimate 2012: Using layer diagrams to design and validate your architecture

3) Visual Studio Premium and Ultimate 2012: Understand your code dependencies through visualization

Only thing that feels disappointing is the extent to which these can be applied in the database / MS BI world. Once you move out of the application world and enter the world of data, I wish same could be applied to data warehouse architecture designs. As of now these features can be used to a limited scope for DW architecture blueprints.

It depends upon the eye and mind that knows how to use a piece of paper as a disposable glass !!