What is the Role of EA in a Dominated SaaS World?

A colleague of mine Gianpaolo asked me about what is the role of EA in a heavily SaaS oriented enterprise. The hypothetical case would be of and IT shop being extremely (80%) of the enterprise IT “operations” being run by 3^rd parties (SaaS, vendors, hosters, apex like exchanges…) does the need of EA increase or decrease?

I thought that this was an interesting question and made to think about it for a moment. So the specific questions are:

• If it increases EA effort, are the current “framework” any good in this new model?
• If it decreases it EA effort, (and assuming we believe in a world where IT will “shrink its perimeter”) how much do we need to invest in EA?

This is a "loaded" topic so I will only be addressing the question directly and not what I think EA's should do about this in their practices. That may come later :) 

So this is a difficult prediction, it really depends what the specific circumstances were with each particular organization. However, we can generalize and create a assumptions based on what we see today.

• Assumption 1 - SaaS architectures will be isolated to the application (the more likely of the two) or business capability (ideally) level 
• Assumption 2 - There is no one vendor fits all
• Assumption 3 - SaaS providers will use open standards such as web services, however the technology implementation, XML payloads and underlining technologies will be different
• Assumption 4 - Regulatory scrutiny for items such as information protection, auditing, and reporting will still exist
• Assumption 5 - There will still be a mixture of implementations of SaaS applications such as Composite Applications (Rich or Smart Clients) and web based solutions.
• Assumption 6 - Integration will not go away as existing applications in the enterprise and specific business capabilities exposed by SaaS vendors will need to interact with each other.

Based on these assumptions it is safe to say that the role of EA will still be intact. However the specific architecture decisions that will need to be made will vary a bit.

Basically what we have done is pushed all the applications to the cloud. Now, instead of provisioning a new HP server and installing Windows Server you use the "cloud" for your application platform. What this does do is it reduces the amount of work needed to manage, operate and support of a server environment. However, this still doesn't change the larger issue with software applications we have today with Commercial Off The Shelf (COTS) applications. These COTS applications need to be wired together because out of the box they only cover a fraction of the business process they will still need to be wired together.

EA's will still have to tie together the following architecture concerns:

• Business Architecture – Just because the application moves to the cloud it doesn't mean that business architecture will not occur. With more applications in the cloud there will be new business models emerging as well.
• Information Architecture – Depending on how these solutions are outsourced you can run into the same challenges enterprises face today but pushed further out to the cloud. As shown below the composite SaaS applications will still need to intercommunicate with each other. I would venture to say that the control of this integration will either be orchestrated solely from the enterprise or will be a hybrid model (which is the most likely) in which based on the specifics of the problem the integration will either occur on the SaaS side or the Enterprise side.

• Communications Architecture – More emphasis will be on communications hardware and the resiliency of it will occur. This will span across into areas such as Operational Management. This will basically tie all the SaaS together for the end user (this greatly depends on what components are pushed out). We can't assume that there will be only a few SaaS providers but many. So it will be ever important to control this. Devices such as: Network Load Balancers, Web Service and Encryption Acceleration Devices, Security Devices, and the obvious routers and switching hardware. There will be some other opportunities that SaaS providers will be able to provide and that is decentralized access of these applications via many different mechanisms such as wireless.

• Operational Management – With this component it involves architects doing more architecture review types of activities of the SaaS players. PMO activities can perform the standard "check it off the items" but there will still need to be verification of these architectures. Additionally, since these applications will be intercommunicating there needs to be assurance that desired architecture solution fits in a multi-SaaS environment.
• Security and Risk Management - This will be a big one as shown in all the diagrams there is no guarantee that the authentication and authorization mechanisms will be built in a composite manner. Ideally they will be but the facts are that the far majority of COTS solutions today have proprietary identity stores. It will require architects to figure out the right solutions for identity management, data at rest security, transactional security, and physical security. At the end of the day the enterprise is ultimately accountable for the data stored in a SaaS data center (refer to the Financial Services legislation where FSI's are legally bound to the implications of an offsite breach no matter what type of contract was defined with the SaaS provider ).

To summarize, these are a few areas on the top of my mind where EA's are affected by this type of SaaS scenario. As shown below in a very simplistic view we have extended the enterprise to the cloud but complexities still remain. I see no reason why an EA's role would be greatly different. 

Now that I went on this rant let's address the questions directly.

• If it increases EA effort, are the current “framework” any good in this new model?
  • It increases activities in the domains listed above. Like all frameworks they are a good guide, the good frameworks do not explicitly tell you if the solution should be built, bought or outsourced.
• If it decreases it EA effort, (and assuming we believe in a world where IT will “shrink its perimeter”) how much do we need to invest in EA?
  • Likewise with the answer above, other domains such as Infrastructure, Development and Database diminish to a smaller degree. But you will still have to worry about the 20%.

 

 

Tags: Enterprise Architecture SaaS

Comments

• Anonymous
  August 29, 2007
  Mike Walker wrote a great thought-provoking blog post on the implications SaaS has on Enterprise Architecture