Architectural Considerations for SaaS Adoption in Federated Organizations
The recent inclusion of “Cloud computing and Cloud/Web platforms” by Gartner in the list of top 10 disruptive technologies for 2008–2012 will continue to increase awareness of Cloud and SaaS computing solutions and offerings among enterprise IT decision makers. As James Staten, principal analyst at Forrester Research, puts it, “If you’re a large enterprise, somebody in your organization is using Cloud computing, but they’re not telling you.” The same applies to SaaS. To define, very succinctly and loosely, Cloud computing means Hardware as a Service (HaaS), while SaaS means Application Functionality/Software as a Service.
There are different reasons, extent, and ways in which organizations adopt SaaS depending on the size of organization, nature of business, and IT culture. The striking similarity across this adoption can be best seen in the nature of the applications. Web conferencing is equally adopted by a large number of small and large organizations while adoption of e-learning services is typically seen only in large enterprises. One of the commonly missed reasons for SaaS becoming a part of the IT portfolio is the increasing nature of federation among organizations and their partners, such as an airline company providing its customers with the capability to book rental car or hotel accommodations online. What are some of the architectural implications of SaaS within the IT portfolio of large organizations and related architectural considerations?
The architectural considerations for SaaS adoption essentially fall into three categories:
- Governance
- Data and Application Integration
- Identity and Access Management
The extent to which these considerations play a role, depend on the nature of the applications. Some applications demand simple data and application integration solutions—for example, when EDI translation hosted service provided by companies like Sterling Commerce or GXS is used as a service by an enterprise or an enterprise integrating with carriers such as FEDEX or UPS to enable its customers to track shipments without making customers leave its Web site. However, the adoption of SaaS becomes most challenging when:
- Processes cross enterprise boundaries.
- Master data needs to be shared across enterprises.
- Real-time integration is needed.
- Applications are invoked using multiple access channels.
- Multiple technologies are involved.
An example of this is when an enterprise retains Level 1 (help desk) and Level 2 (after sales support), but outsources Level 3 and that the outsourcing organization provides its Web-based tools to the help desk team to create service requests. In this case, it’s not just the process crossing organizational boundaries, the customer data is required to be entered in the vendors’ application, thus leading to the sharing of master data. Another example is when order entry and billing and accounts receivables systems are managed by two different organizations, meaning that customer master data is required to be shared across the applications and the organizations.
GOVERNANCE
Governance challenges increase when organizations, which are required to share application capabilities, compete in the marketplace for some other business or have the same customer base. Challenges are particularly big when the application capabilities are required to be made available to the customers of either of the partnering organizations. While the partnering enterprises may not have much issue sharing master data, sharing customer behavior, which is typically built using Web analytics, commonly becomes a contentious issue. It is, therefore, important for the business stakeholders of the partnering organizations to discuss data ownership. Similarly, if customer master data across organizations is needed to be created, it should be discussed before the features to be provided to the users of the shared application are finalized. Failure to arrive at an agreement leads to inability to deliver the finalized features.
This is an area that needs the most consideration when adopting SaaS. In the initial stages of SaaS adoption, the business is normally involved. It is recommended that business participation should be maintained throughout the life cycle of the SaaS application. The enterprise architect should always obtain a business sponsor for the relationship thereby having executive attention when governance issues crop up. Business can also help resolve issues quickly by providing inputs on elements of data that your organizations really need to own. When data ownership issues crop up, it is advisable to consult the enterprise architect on what and how much of the data is really needed. In my experience, two partners had a long drawn-out argument when one partner was asking for “all the data,” while the other was refusing to give “all the data.”
DATA AND APPLICATION INTEGRATION
This is an area where the enterprise architects are most experienced and, therefore, leads to the least issues when it comes to SaaS adoption. Practices like keeping the business rules that are used for processing data, with the partner that owns the data, are quite standard. In EDI outsourcing situations, for example, the business rules should not be sent across to the EDI translator hosting provider. Most of the times the only area that needs consideration when the data/application integration needs are real-time is that the architect needs to ensure that the partnering organization can provide for the necessary tools and technology and would support anticipated volume. One of the best practices here is to validate the possibility of using a canonical data model in case your organization already is using one.
As an enterprise architect, you should always assess the need to have knowledge of the data architecture that is being deployed by the partner. Though the partner may have good data architecture to start with, it usually deteriorates over a period of time. If people with knowledge of the initial data architecture leave, it could be a very costly affair to get necessary data from the partner application when your organization needs it at a later point in time. If the partner is unable to provide details of the data architecture, the other option is to get dumps of data on a periodic basis. However, this dump is required to be checked for accuracy by building a cross-checking application capability in your own organization. One of the last CRM applications that I helped migrate had a situation where the data architects who had developed the application 10 years back were all gone and no other IT resource from the partner had knowledge of the data. This led to a risky and costly migration.
IDENTITY AND ACCESS MANAGEMENT
Apart from governance, identity and access management (IAM) needs are the ones that are seen to evolve the most during the lifetime of a SaaS application. They are also the ones that require considerable collaboration since the infrastructure and resources required to enable and sustain IAM can be considerable depending on the volume of users. This is also an area when complications increase if end customers are using the SaaS application.
Since application access needs are required to be met increasingly in real time after the application user is created, use of SAML for exchanging authentication and authorization information is increasing in SaaS. Native support by Microsoft .NET and most of the J2EE application server platforms makes it easy to for SAML to be used independent of the technology used for the SaaS application by each of the enterprises. Essentially, all of the considerations that come into play while planning, designing, and implementing federated identity management come into play with SaaS applications.
In many situations, and across industry verticals, the architectural considerations mentioned above come to the fore as the business realizes the need for more integration after a period of application use. In most cases, these challenges are unattended in the initial phase of SaaS adoption. However, as the use of SaaS matures, these challenges become more evident. It then becomes a costly affair to mitigate the architectural limitations of the supporting application infrastructure. Maturity of SaaS integration across federated enterprises usually evolves over a period of time. Enterprise architects should therefore do business scenario planning for a few levels of SaaS maturity beyond the stage at which it is being adopted and articulate the need for the right kind of technology and governance policies. The considerations outlined in this article can help architects cover all possible technical scenarios. This also helps enterprise architects set the expectations of business that SaaS adoption is going to need investments over a period of time. Since the shared application capabilities keep increasing as the business needs evolve and partnerships mature, enterprise architects also must revisit these considerations over a period of time.
Last but not least, as your organization is evaluating SaaS adoption, formulate a high-level exit strategy along with the business sponsors. It is important to have the assumptions within the exit strategy validated by your partner before signing a contract.
by Nitin Shingne, CSC, a principal/architectural expert at CSC with 17 years of experience in technology and business consulting. He is certified in enterprise architecture (TOGAF) and supply chain (CSCP by APICS). He can be reached at nshingne@csc.com.
