Archetecting with SaaS

“Is it hard? Not if you have the right attitudes. Its having the right attitudes thats hard.” 

Robert M. Pirsig Zen and the Art of Motorcycle Maintenance: An Inquiry into Values

The problem with SaaS

Software as a Service (SaaS) is the development paradigm of the cloud computing. Research shows that working with traditional application program interfaces (APIs) cause a great deal of problems for software developers (Robillard, 2009). APIs can be hard to learn, have incomplete documentation, and use different development paradigms. SaaS can have predefined limits, network latency issues, and represent a different programming paradigm (Microsoft Exchange Online, 2012; Salesforce, 2012).

Software development teams are finding that working with SaaS can be difficult. Project managers need to know the contractual obligations of the SaaS provider, plan for upgrades of the providers system, and deal with the additional risk of an changing unknown factor to their project(Karakostas, 2009). Software developers face the challanges of learning new sets of APIs, dealing with limitations, and working with different language and software development paradigms (Lawton, 2008; Salesforce, 2012). Software testers learn to deal with systems that can be in consistent such as some cloud based systems eventually concurrent data model.

Archetecting SaaS

Category	Quality Attribute	Description
Design Qualities
	Maintainability	Ability to efficiently maintain system.
	Reusability	Reusable code reduces waste and promotes faster development times.
Runtime Quality
	Performance	How responsive the application is to changes.
	Efficiency	The amount of resources a system uses.
	Scalability	The ability of a system to add handle large amounts of requests.
Consumer Quality
	Usability	Ease of use and learnability
	Security	How secure the system is.
	Cost Effectiveness	The monetary return on the cost of the system.
	Interoperability	The ability of the system to interact with other systems within the organization.

Architecting software solutions let developers achieve some measure of quality. There are different schools of thought on software architecture. Microsoft in their Architecture Guidelines primarily recommend 3-tier/n-tier architecture for most applications and client/server architecture for systems that have high performance needs such as websites or applications that deal with large amounts of data. Using design patterns is another school of thought. The concept of design patterns is that design patters (which are conceptual programming abstractions) allow programmers to rise above the details of implementation and discuss applications in broader forms. Another school of thought with architecting is using different programming languages to achieve efficiently. A software developer might use a functional language such as F# with scientific applications, an object orientated programming language such as C# for business applications, and a set based language such as SQL to handle data sets. Also there is service orientated architecture (SOA) and web services, which are web based and platform agnostic.

Architecture choices are generally based on perceived quality. One organization who values interoperability of their systems may choose SOA while another that favors high performing websites may choose client/server architecture. An organization that values extensibility and security may favor n-tier architecture. Software developers that want an easily testable application may choose a simple 3-tier application over a design pattern application.

Architecture may also be part of an overall business or IT strategy. Companies that wish to collaborate with other companies may choose to use a web service architecture. Companies wishing to build in their systems the ability to reuse systems in other systems may choose SOA.

Cloud providers also have needs that can address by architecture. The first is to follow a familiar SOA type of system. SOA systems generally do not deal with bulk data well. They are can be slow over an intranet over the internet they perform even worse. Second a cloud provider may need to account for a very large amount of traffic. They may choose a distributed database systems that may not be always concurrent across all servers. Finally, a service provider may need to protect itself from over use by customers.

Some providers such as Salesforce (2012) allow users of their APIs a choice of using their traditional API which supports one by one transactions and a bulk API that supports bulk transactions. Traditional APIs allow developers to easily develop software with such architecture as design patterns, n-tier, and object orientated programming. Bulk APIs are better suited for architecture where data is already represented in sets such as programming and client/server programming.

For the cloud provider the choice on what type of API to provide may be a function of the business needs. They may need all of these systems to be concurrent before allowing another transaction. A bulk API would allow clients to send data over and wait till it has been fully processed before allowing them to proceeded.

When working with SaaS, it helps to know the architecture of the provider. Does it have performance governors? Performance governors can be set by the cloud provider or just a byproduct of using the internet. Does the architecture of the cloud provider play well with the architecture of the current systems in place? A company that is using a work flow system is using a procedural programming architecture. This type of system is good for individual transactions but not bulk transactions. In the end the right architecture is one that works will with the needs of the company and the SaaS API.

References

Karakostas. B. (2009). Restructuring the IS curriculum around the theme of service orientation. IT Professional Magazine, 11, 59-63.  Retrieved from ABI/INFORM Global database.

Microsoft Exchange Online. (2012) Retrieved May 11, 2012 from http://download.microsoft.com/download/0/9/6/096C9441-8089-4655-ABB3-DC0ABA01A98D/Microsoft%20Exchange%20Online%20for%20Enterprises%20Service%20Description.docx

Robillard, M. P. (2009). What makes APIs hard to learn? Answers from developers. IEEE Software, 26(6), 27. Retrieved from ProQuest/UMI Database.

Salesforce.com (Feburary, 2012) Salesforce limits quick reference guide. Retrieved from https://login.salesf