Monday, April 1, 2013

Software as a Service

Advancements in stabilization in software development techniques as it led to companies being able to sell or give away a programmatic interface that allows developers to use their services.  Application interfaces (API) have created a World Wide Web that is programmable.  This programmable Web allows other companies access to a wide variety of tools. 
Companies who are able to use Web services and APIs are seeing a reduction in cost, quicker time-to-market, and a competitive advantage over their competition.
Not every company gains a competitive advantage to using APIs.  IT managers looking APIs must look at many factors to determine whether or not these types of services will benefit their company. 

Before the programmable Web revolution companies had to develop software often from basic building blocks into the finalize project.  This software was often tied down to the operating system it was built on.  If a company wanted to make a geographic information system they would need to start with the basic building blocks and work up from there.  These tasks could take months or years.  If they wanted to correlate their system with crime statistics they would have to make sure that there geographic information system was compatible with crime data provided by the government.  If the crime to a database was an Oracle database and the geographic information system was a MySQL database then the two databases often would have a great deal of trouble communicating with each other.  Today with readily available APIs from companies such as Google and from the government this type of data is no longer tied to a specific system.  Websites such as can be built in weeks and not years at very low costs.

Microsoft recently with the release of Windows 7 has moved many of the services that were traditionally on a computer to the Internet (“Clash of the clouds; Cloud computing“, 2009).  For services such as e-mail, and social networking Microsoft provides via an API that the operating system can use.  This API, however, is not limited to the Windows 7 platform.  The same information is accessible to a desktop computer can be accessed through a smart phone or a video game console.  Any device that has Web access can potentially use these services.  This frees the user from the computer and allows them to choose to use programs on number devices.  They can even log into other computers and have their information available to them.

Microsoft is launching a new platform for companies to develop APIs (Microsoft, n.d.).  Microsoft's new platform called Azure allows companies to run virtualized servers.  In the same way that the Windows 7 operating system allows people to access their systems remotely, Azure allows companies to host their programs remotely in a way that is accessible to a large number of people. 

Amazon has become a leader in the sale of APIs (Amazon, n.d.).  Companies can now build entire websites in which everything is hosted on the Amazon platform.  Amazon's SimpleDB allows companies to store their data remotely on Amazon's servers.  Amazon's Simple Storage Solutions (S3) allows companies to store a large amount of data.  Amazon provides low cost or free API services to many companies.  The reduction in cost coupled with the speed of delivery and low maintenance makes the Amazon API solutions desirable for many new companies.

Google has developed Google App Engine which is a hosting service for API systems (Arnold, 2009).  That combined with the dozens of API systems that Google gives away for free makes Google a leader in API delivery systems.

Many websites have integrated Google Map’s freely available API.  Websites called mash-ups combine information from several APIs.  Google maps have been a popular API because it allows people to visualize data.  For example, combines Google maps with real estate data to create a map of available homes for sale.

Google also offers a search service that allows companies to make a custom Google search on their website.  Google’s search API allows companies to customize the look and feel of the results.
Google offers programmatic access to its Google Docs program.  This allows companies to programmatically create web forms and spreadsheets easily.  Google is using this API to allow people access to their database API Google Base.  Through Google base people are able to manage other Google products such as Google’s Image storage system Picasa.

The Google Merchant API allows companies the ability to submit items for Google shopping.  Through the API merchants can set post products that they want represented in the Google product search.

The World Wide Web became popular in the 1990s.  It's only been in the past 10 years that we have seen companies offering programmatic interfaces.  Unlike many internet based products API’s are not the idea of one organization.  They have been developed slowly by many organizations that have found a need that they could fill.  Literature on the subject of APIs usually focuses around cost-benefit versus risk analysis.  Companies that use APIs typically have a competitive and it over traditional companies.  APIs, however, are not for every company.  Organizational structure, privacy concerns, and disaster planning are things to consider when thinking about using APIs.

Using APIs has become a cost-effective means for many startup Internet companies.  Paid APIs are done by a pay-as-you-go system this means that companies are able to start up at very low cost and grow as the revenue comes in.  In traditional Internet company would need:  servers, a server facility, licenses, and support staff just to get the website up and running.  This capital expense without any revenue coming in can be a barrier to entry for many entrepreneurs (O’Sullivan, 2009). 
Using APIs companies can host their websites remotely, use a database such as SimpleDB to house their database and use pre-existing services that allow them to build their websites faster.  Products such as he Amazon’s S3 allow companies to use store large amount of files without having to worry about bandwidth limitations and server storage space. (Smith, 2009)

Cost of Maintenance
Companies that house their products on the Web can do so without having to hire the traditional support staff as traditional companies do (Smith, 2009).  For example, database administrators are responsible for backing up the data, indexing data for faster delivery, replicating the data to other servers; maintain the hardware and many other tasks.  With Amazon's SimpleDB this is handled by Amazon itself.  Systems backups, indexing, and other tasks that visual database administrators do are done automatically by Amazon's database.

In 2007 Carbonite a storage provider lost the data it housed for 7500 customers.  Failures like these while rare still happen.  When a customer is looking at a potential API service provider they need to look at the level they are paying for. The document that specifies what the service provider is responsible for his called the service level agreement (SLA) (Zielinski, 2009).
  An API provider should have a SLA outlines their responsibilities.  When choosing an API provider business people need to look at factors that then would care about in their own organization (Zielinski, 2009).

Service level agreements should spell out exactly what the API is providing in terms of security, auditing, and disaster recovery.  In a service provider should fail to meet their responsibilities as outlined the contract they should be liable for losses (Ria & Chukwua, 2009).
Developing software and WebPages that use APIs require developers architected their software in a way that is compatible with APIs.  This usually means writing up their software into logical parts and then componentizing their software developer efforts. 
There are two ways that API services providers generally use to allow others to interface with their system.  The first is an XML-based cross platform Web communication standard called Simple Object Access Protocol (SOAP).  This allows developers working in different offering systems in different programming languages to share components easily.  A second way is for servers providers that cater to web pages using a technology called Ajax which is a client-side browser specific technology.  These API providers use the Web standard JavaScript Object Notation (JSON). SOAP is used primarily to transfer data from server to server; while JSON is used to transfer data from server to webpage. 

IT Architecture
Companies that use APIs are forcing themselves to take a modular approach to software development (Luthria & Rabhi, 2009).  While this can lead to delivery of their products quicker to market they can also lead to some other issues.  Service oriented architecture, for example, does not allow programmers to integrate their software as a whole.  Each functional part of the program must a broken down into components that then can indicate with each other via SOAP.  SOA transitions can happen both within the organization and externally to an API provider SOA fee uses XML protocols to send data back and forth between the different functional parts of the program.  XML can be very verbose in its transition of data.  This extra information that is passing through the company’s internal and external network can cause problems with network latency.  Latency can lead to software freeze ups and web pages that take too long to load.  Working with APIs, developers need to be mindful of the amount of data is transferred between systems and the capacity of the network.

Support staff at company providing APIs perform all the maintenance and updates necessary to keep their systems secure and running at peak performance (O’Sullivan, 2009).  In a traditional company is to be handled by the IT staff.  Offloading this task and reduce the number of IT staff that a company needs.
Versioning of APIs can be a difficult issue for API providers.  Over the years and API provider can have several different versions of their service available.  Issuing updates can break existing client’s software.  Many API providers force software developers to choose a version that they wish to use.  This prevents version conflicts and allows projects to target one statistic set of services offered by a API provider.  Because new versions are not forced upon API clients, when a new version comes out it is up to the client to choose whether or not they wish to upgrade their current version.  New versions of an API may contain bug fixes and new features but they also could destabilize a company’s current software product or webpage.  Because the client does not control when new versions come out there may be no development budget to implement and test the new versions.  Because there are some writers and clients are often out of sync with versioning and software development efforts clients need to be flexible enough to make changes whenever the need arises.   

Traditional software is constrained to an operating system and a set of hardware (O’Sullivan, 2009).  APIs, however, often defy these constraints so they can gain more clients.   Many APIs use the SOAP portal format which means that they are able to transmit not only work on websites and PC software but other devices such as smart phones and game consoles. 

Whether a company uses an API that is free or a paid subscription support of the product should be considered.  Many companies offering free APIs such as Flickr did not offer prompt support.  Rather they offer a wiki and a problem reporting form (O’Sullivan, 2009).

Implications for IT
Using APIs can be a strategic advantage for any companies.  Using APIs requires that the entire IT staff from management to testers must learn a different way of doing business.  APIs rely on outside parties to do their work.  IT teams must learn how to form a relationship with API providers.

Leadership among companies that use APIs must keep a portfolio of APIs that is able to help the company gain a strategic advantage over the competition.  Leaders at these organizations need to know the factors that make a strong API portfolio.  Factors such as cost, latency, security, and contracts are important factors in having a strong API portfolio. 

Using APIs can have a large cost advantage over traditional software developer efforts (Truitt, 2009).  Paid APIs are generally built on a pay-as-you-go.  This type of system can be a great benefit for companies that are starting out.  Traditionally a company that is starting what they to purchase servers, server space, IT staff to mention servers, user licenses, and a number of other capital intensive products.
Using APIs allows companies to pay for their systems as money comes at.  By paying for only what they need companies are able to better evaluate the costs effectiveness of the API.  Many API companies offer a no-cost trial of their product.  This allows companies to develop software risk and cost free.  By eliminating the large amount of capital needed to start a project companies are putting themselves better able to implement projects and pay for them with operational costs. 

API providers typically have a server farm that allows them to scale their products rapidly.  For many companies there is a cost barrier to implementing a server farm. 

Internet companies especially can have a large amount of fluctuating data (Waxer, 2009).  For these companies to remain operational during spikes in traffic they traditionally needed excess server capacity.  It is not uncommon for websites to receive 10 times the traffic they receive due to a front page story on a site like  Company that do not use APIs would need 10 times the amount of excess capacity that they experience on a daily basis.  This may mean that they have 10 times the amount of servers and 10 times the server space.  This can be incredibly cost ineffective for these types of companies.  APIs provide a solution to this problem.  APIs automatically scale when may be too and the client is only charged for what they use.  This allows companies to seamlessly handle 10 times their typical traffic without incurring performance issues and costs concerns. 

One important factor to businesses that APIs provide is the ability to integrate their products offering with other websites.  E-commerce websites are able to post their products on Google shopping and Amazon through APIs (McCreary, 2009).  Companies are finding that developing relationships collaborative relationships with API providers can help them increase their revenues.

Legal Ramifications
While using APIs can give companies a strategic advantage, APIs are not suitable for every organization.  When using an API that is involved with records management companies must look at regulatory laws that govern the control of information.  The health and financial industries are wrought with regulatory laws that may make it impractical to use APIs.
Companies looking into using APIs for data storage should make sure that the service provider has a plan for backup, replication, and disaster recovery.  Audit controls are another important factor in choosing a company to store data.  Internal theft happens at many companies.  Audit control can help companies track potential embezzlement.

FRCP Related to Discovery
The US Federal Rules Regulatory Procedures (FRCP) states that companies that are in civil trials must be able to provide all electronically stored information (Gatewood, 2009).  Companies that store their data in the cloud with services such as Amazons SimpleDB must look at whether or not they are able to quickly get a copy of all of their data.  Amazons SimpleDB does allow quering of its database but has a row limit of 5000 results (Amazon n.d.). This could create a large burden for a company trying to retrieve all the data from its databases stored in SimpleDB.  A company that is expecting it may face civil trials may wish to think about storing data in a more traditional database. 

Regulatory Requirements
Personally Identifiable Information (PII) is subject to regulations on how it is stored and delivered to people.  These regulations vary by country. The place that hosts the server and where the data is stored is usually subject to the laws within that country (Gatewood, 2009).  API  distributors often have several data centers around the world.  These data centers help prevent against regional disasters and also can be used for increased demand within a certain region.  Companies that send PII to API servers are subject to laws in the countries that those servers are housed.

 The Sarbanes-Oxley act of 2002 made transparency in accounting mandatory for many organizations.  These companies must provide a way of locking share holders out of financial information during certain times (Gatewood, 2009).  Many APIs rely on a single user name and password to access the data.  For companies that need to lock down access during certain times this may not be possible with API providers.  Sarbanes-Oxley also requires that companies audit the access of data by people.  Companies also need to be able to remove people’s access that no longer works at the company.  With its username password combination data housed in the cloud may not have the capacity.         

Research Opportunities
Current research in the area of APIs has been limited to cost benefit analysis and risk reward analysis.  Most of these analyses are done through qualitative methodologies.  There exist research opportunities in this field for quantitative analysis.  Researchers could, for example, analyze the cost savings of companies that have switched from traditional software development is to cut getting.  Researchers can also look at the overall development time it takes companies to develop standard projects and project using APIs.

Using APIs as part of a software development project comes with risks and benefits.  Understanding the benefits and risks are key to making API use decisions.  APIs come with the promise of faster software development and decreased development cost and time.  APIs can also help companies integrate with partners more easily.  In today's business world partnerships and synergy can make or break a company.  APIs allows a company to easily port its software to many other platforms such as smart phones and game consoles. 

There are risks also associated with using APIs.  Companies that wish to store PII or financial data using an API may be at risk of violating laws and having an insecure website.  Companies using APIs must be able to quantify the risks and keep an API portfolio.  Company should understand the contracts for APIs when choosing a API provider.  These contracts should have the same requirements that a business would need internally if it were developing a project.  Backups and disaster recovery must be considered before deciding on a API provider.

Companies must also look at their own internal architecture to see if having an external API would cause slowdowns on their network.  APIs require that companies send data across the Internet.  If the company does not have a fast internal network this may cause an unacceptable level of delay when running applications. 
Amazon (n.d.). Amazon SimpleDB. Retrieved November 13 2009, from
Arnold, S. (2009, July). Google’s App Engine: getting serious about the enterprise market. KM World, 26.
Clash of the clouds; Cloud computing (2009, October 7). The Economist, 393(8653), 80.
Luthria, H., & Rabhi, F. (2009). Service Oriented Computing in Practice – An Agenda forResearch into the Factors Influencing the OrganizationalAdoption of Service Oriented Architectures. Journal of Theoretical and Applied Electronic Commerce Research, 4(1), 39-56.
McCreary, B. (2009). Web collaboration - How it is impacting business. American Journal of Business, 24(9), 7-9.
Microsoft (n.d.). Windows Azure platform. Retrieved November 5, 2009, from
O’Sullivan, D. (2009). The Internet cloud with a silver lining. The British Journal of Administrative Management: manager, (), 20-21.
Ria, S., & Chukwua, P. (2009). Security in a Cloud. Internal Auditor, 66(4), 21-23.
Smith, R. (2009). Computing in the cloud. Research Technology Management, 52(5), 65-68.
Truitt, M. (2009). Editorial: Computing in the “Cloud”. Information Technology and Libraries, 28(3), 107-108.
Waxer, C. (2009, Feburary). Supercomputers For Hire. Fortune Small Business, 19(37), 37.

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
Quality Attribute
Design Qualities
Ability to efficiently maintain system.
Reusable code reduces waste and promotes faster development times.
Runtime Quality
How responsive the application is to changes.
The amount of resources a system uses.
The ability of a system to add handle large amounts of requests.
Ease of use and learnability
How secure the system is.
Cost Effectiveness
The monetary return on the cost of the system.
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.

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

Robillard, M. P. (2009). What makes APIs hard to learn? Answers from developers. IEEE Software, 26(6), 27. Retrieved from ProQuest/UMI Database. (Feburary, 2012) Salesforce limits quick reference guide. Retrieved from https://login.salesf