How SaaS, S+S impact an Enterprise Architect

Mike Walker wrote a great thought-provoking blog post on the implications SaaS has on Enterprise Architecture. Although he noted some very interesting points, I thought I’d extend this a bit and describe the impact of my life as it pertains to SaaS because coincidentally, I'm an Enterprise Architect and am personally tasked in an initiative to help solve how Microsoft IT is involved with SaaS. So, I'm in the throes of the interesting implications of how I do my job as I address this challenge.

I posted some of the thoughts on how I address business analysis as part of defining the Business Architecture. I break up the problem space into two very different areas: Business Analysis for Consuming SaaS and Business Analysis for Providing SaaS. Here are the blogs respectively.

· http://blogs.msdn.com/gabriel_morgan/archive/2007/07/18/business-analysis-for-consuming-saas-services.aspx

· http://blogs.msdn.com/gabriel_morgan/archive/2007/07/18/business-analysis-for-providing-saas-services.aspx

Because I'm short on time let me blurt out some comments in the area of "EA implications for consuming SaaS software":

• The distinction between business capability and applications is very important. This will get clearer as I describe the Business Architecture implications below. Btw, I wrote a blog about these concepts to put them in an information model view to help describe how they relate. See here http://blogs.msdn.com/gabriel_morgan/archive/2007/07/31/traceability-from-biz-strategy-to-application.aspx.
• Application Portfolio Management is still in the picture. Although the SaaS service means that the software and infrastructure is in the cloud, they are still a part of our application portfolio and must be rationalized to avoid redundancy and managed to ensure we make informed decisions how to position it over time.
• With regard to the Business Architecture domain, things get interesting with consuming SaaS services because:
• There needs to be attention paid on consuming SaaS services which are ‘Supporting’ business capabilities rather than focusing on those business capabilities which are ‘Core’ to a business. Why only the Supporting business capabilities? Well, because we don’t want to be locked into the dangers of our businesses struggling to be innovative and agile with their business process and them being constrained by a SaaS software that automate them. Remember, that the majority of SaaS provider software out there is built to be supported by several companies simultaneously using the same code base.
• There needs to be attention paid to the 'connectdness' of business capabilities and look for business capabilities that are relatively independent of one another. That is, look for business capabilities that have relatively little dependency on other business capabilities especially as it pertains to business process and information.
• Business process integration. We need to still model the SaaS software in relation to business processes to ensure we are optimizing the value of the SaaS software investment.
• With regard to System Architecture domain, things get interesting:
• When desigin system integration for both business process workflows as well as the data integration needs via system-to-system data integration. There are some interesting innovations happening in this space as system and data integration themselves can be SaaS services but I digress. Anyway, think of the challenges of supporting systems in your local IT shop that must, and I repeat, must integrate with services in the cloud. Such challenges and being responsible for the Quality of Services requirements your business has as it relates to their system, which they may not even be aware depends on clous services, such as system reliability, system maintainability, system supportability, and system testability. Yes, these issues fall on the shoulders of the local IT shop and they are not simple to solve. In our experience, which is quite young, requires an astonishing close relationship with our SaaS providers to the point that sometimes it looks like they are merely an extension of our IT shop. I'm sure that this will change as SaaS providers and the consumers (aka us) work out the kinks of working better together and streamline the basic delivery activities but for now, we are still learning.
• Presentation mash-ups. As an EA, we love the concept of the business being able to build their own applications using readily available software services via presenation applications and workflows. Nick wrote more about this on this blog entry so I won't cover it here. The point I want to make is that we promote those SaaS services which enable this type of situation.
• With regard to Information Architecture domain:
• Like Mike noted, attention must be paid to the information that can legally be stored in the cloud. Think financial information in Europe. This is not always legal for this type of information to leave the country.
• Data integration needs are very important. We are very weary of storing data in the cloud if we have Quality of Service requirements such as Data Staleness of less than 1 hour (or thereabouts). This is just an observation and probably a result of a lack of maturity of system integration abilities and think that we will overcome this in due time.
• Data Masters are left on-premise at the moment. We are very weary of storing master data outside of our control. In fact, I'm not aware of any such situation. Instead, I'm seeing more interest in SaaS software that stores anciliary or extended information that is readily retrievable to a master data store.

In short, SaaS provides a lot of potential cost savings that are of high interest BUT they do bring with them some interesting challenges to an Enterprise Architect to make sure that SaaS sofware is optimized for the business investment.