May 18, 2012
The value of Enterprise Architecture is that its utility does not diminish with the relentless evolution of information technology. Indeed, it provides an indispensable framework in which to analyze a wide-variety of information-oriented processing systems. For example, let’s leverage a modified, 5-domain enterprise architectural framework to highlight the tradeoffs associated with using the cloud for a business application. Let’s assume that we’re considering a SaaS deployment model for a personal automobile claims insurance solution (aka application).
Domain #1: Business Architecture
First, let’s consider the “business” and its “needs.” Business solution architecture is a discipline that is superior in eliciting and articulating proverbial business needs. In essence, it stipulates the key business goals, user-focused goals, organizational variables (e.g., people, culture, etc…), business processes and business rules. The key tradeoff in this architectural layer is typically, speed to deployment vis-à-vis degree of customization. Although, cloud computing can facilitate increased agility, it inherently lacks a deep degree of customization. Should a business need to quickly implement a new business service, a cloud-oriented solution could facilitate a rapid time to market. However, if this is a claims business service that is considered a competitive differentiator, a SaaS model might not be an appropriate one.
Domain #2: Data Architecture
Although cloud computing adds complexity to data security (i.e., location, transport, leakage, etc…) it adds increased scalability, recoverability (i.e., both disaster recovery and archiving)and processing capacity to our data architecture. In our particular case example, we would need to evaluate the nature of potential claims data and any regulatory factors associated with it.
Domain #3: Technology (Infrastructure) Architecture
Cloud computing enables increased elasticity for our solution. This pliability allows us to more accurately match the applications services (resources) to the demand without overpaying for excess capacity or losing an opportunity to address market demand. A key consideration here is the degree to which application services that are “bursty” or “spiky” are amenable to the cloud. Those that are less variable need not pay the cloud premium. In our example, the insurance carrier would need to consider the statistical probabilities of abnormal, large scale “tail” claim events.
Domain #4: Security Architecture
Security is usually portrayed as a challenge for cloud computing. All of the traditional on-premise security issues (e.g., data privacy, data compliance, intellectual property risk, etc…) apply. However, there are several benefits that the cloud may offer with respect to security (e.g., professional audits of providers). Many SaaS vendor providers have security analysts that are significantly more experienced than what their clients have in house. Hence, one could argue that a SaaS model would have enhanced security. Once again, considering the specific nature of our usage scenario would be required to best understand the cloud versus on-premises deployment tradeoff. For example, if the insurance carrier’s target audience was the ultra-high net worth category, then security (e.g., authorization, authentication, data masking, etc…) would probably play a significant role.
Domain #5: Financial Architecture*
Companies are often challenged to increase functionality of IT while minimizing capital expenditures. By purchasing “just the right amount” of IT application services on demand, an enterprise can avoid purchasing superfluous computing assets. It’s commonly understood that cloud computing technologies and business models offer compelling economic benefits, particularly in reducing capital expenses. The shift to operating expense however could be a cause for concern. The cost rises linearly with the business which, if the insurance carrier intends on serving a large market and capturing a large share of it, the operational expense nature of cloud computing could be a disadvantage.
Are there other “architectural” sub-domains that should also be considered in our analysis? Perhaps the ‘integration’ architecture layer would be useful to ruminate?
*note: a system’s financial architecture is a lens that is underutilized in the discipline of enterprise/solution architecture analysis.