Architecting Cloud Applications for the Enterprise - Part I - Introducing the Actors

  • Article

I will start this series by introducing the main characters of our scenario.

First, we have VeryBigCorp. VBC is a large corporation, with multiple branches and subsidiaries, thousands of employees, etc. VBC is the typical organization with a rather complex business environment: multiple business units, complex rules, regulations, etc.  

image

VBC IT department is a reflection of this complexity: they have lots of legacy components, multiple networking stacks and a rich myriad of technologies coexist in its data centers. VBC develops custom applications for some of their business units, but they also buy packages from specialized vendors.

VBC IT has multiple processes in place to deal with all these challenges: there are architecture and development guidelines that everyone is supposed to follow, there are software development lifecycle processes, standards, naming conventions, etc. All these are there for good reasons, but sometimes creates a perception of lack of agility and excessive bureaucracy.

Most technology acquisitions in VBC are handled by the IT department following strict steps.

The second character in our story is SuperCloudySoftware, a service provider (a "cloud ISV" if you want)

SCS has embraced the web since its foundation. SCS innovates very quickly, pushes updates on its service regularly based on customer feedback, focuses on user experience, etc. They are the ultimate "agilists".

SCS focused initially on smaller businesses, even some consumers. Their flagship service is IssueTracker a task tracking service.

IssueTracker is only available as a service. That means that you can't buy a license of it and deploy it in your own data center.

From the beginning SCS made the strategic decision of making IssueTracker available through "multiple heads":

  1. There is a Web Client that only requires a browser
  2. There's a Smart Client that provides a richer UX and enhanced connectivity options (e.g. working offline) and
  3. There's also a Web Services API for all functions, that allows anybody to create their own clients or want to integrate with other client environments such as Microsoft Office.

IssueTracker itself relies on cloud building blocks. For example, the persistence of the application is based on SQL Data Services. This of course is completely opaque to their customers.

Next chapter will cover IssueTracker acquisition process in VeryBigCorp.