Gabriel Morgan

Sharing experience as I help manage Microsoft Corp as an Enterprise Architect, Business Strategist, Business Performance Manager, Business Architect and Solution Architect. Twitter:@Gabriel_Morgan

How SaaS, S+S impact an Enterprise Architect

How SaaS, S+S impact an Enterprise Architect

  • Comments 2

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.

Leave a Comment
  • Please add 4 and 7 and type the answer here:
  • Post
  • Gabriel, great extension of my scenario of dealing with SaaS dominated enterprises. I specificly like the extension of the ideas around business architecture and APM.

    -Mike

  • Gabriel's comments about cloud computing and integration are key to the future of enterprise architecture.  SaaS, S+S and cloud structured and unstructured information archiving are here now in the form of integration engines.

    I have long wondered why it was so difficult to move unstructured information between different applications, devices and locations.  It wasn't easy but we created something to perform this task.

    Our first product is adapted to Documentum repositories but others will follow quickly.

    This changes much of the enterprise architectural thinking about unstructured information, integration and cloud computing.

    One of the big issues of cloud computing is the "what if" scenario of the cloud going away.  What if there is a network failure, what if the Internet as we know it collapses under the combined weight of larger content file downloads, advertising, spam and commercial use, what happens of a competitor buys that cloud, what happens if someone accidently pulls the plug, etc., what if the cloud owner goes under?

    In the case of a vulnerable cloud the enterprise cannot be vendor dependent, cannot be slow to adapt to new cloud vendors and needs to be very agile with its structured and unstructured information.

    By agile I mean that the enterprise needs to be able to one day see that the cloud is vulnerable and the next day be pointing to a different cloud or simultaneously be using two different ones, perhaps mirrored to provide fail-over or quick disaster recovery.  The also need portable information.  The information, and massive amounts of it, may need to moved from one application, cloud or organization to another on short notice or even as the result of an automated business process.

    Not only do they need to be agile but they need to compliant and manage the information according to rules in order to be compliant with regulatory compliance legislation.  They can't just "chuck stuff over the wall" and forget about it.

    With today's technology they just can't do all of this without massive expenditure.  Sorry can't be done.  Our vision is pointing to exactly that.

Page 1 of 1 (2 items)