次の方法で共有

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

  • [アーティクル]

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.

Comments

  • Anonymous
    December 06, 2008
    PingBack from http://itquestions.info/architecting-cloud-applications-for-the-enterprise-part-i-introducing-the-actors/

  • Anonymous
    December 07, 2008
    Hi, Nice post. Will help in building a complex cloud applications. Eager to see the next part if the series. Thanks, Thani

  • Anonymous
    December 07, 2008
    Excellent strt.. waiting for the rest...

  • Anonymous
    December 08, 2008
    I liked it very much. I'm looking forward for the next episode! Great Job.

  • Anonymous
    December 08, 2008
    Good Start. But, would be great if you have a little bigger posts than this one (like Scott Gu). Waiting for the next post...

  • Anonymous
    March 03, 2009
    This is a great program and all the players involved deserve credit for a job well done. There is a huge need for information management software. Im glad that there are people working on this type of software.

  • Anonymous
    March 05, 2009
    I wanted to provide pointers and credit to the detail behind the ‘Architectural Impact’ portion of the