As mentioned in my previous post, I spent a fantastic week in Brazil.
Yes, the food was great (Fogo de Chao, Feijoada, Marius Crustaceos....), yes, the weather was amazing, but what made this week fantastic was the people:
If I was a Twitter fan I would have posted my activities in real time, but since I am not (yet?!), for those interested, here is a breakdown of my activities in Brazil: (for those you are not, feel free to jump to "Topics of discussion" below)
Day 1: Arrived in Sao Paulo, slept and had 3pm lunch with Marcelo a friend, ex-Microsoft now an entrepreneur in Brazil.
Day 2: Meeting with local Microsoft team and discuss SaaS in Brazil ; meeting with the Brazilian SaaS SIG (special interest group)
Day 3: General session at RAF (Regional Architect Forum): slides here; just after a video of Bill Gates welcoming the attendees and sharing some of thoughts about Brazilian opportunities ; SaaS Roundtable #1 with a dozen RAF attendees (see topic discussed below)
Day 4: SaaS Roundtable #2 with another dozen RAF attendees ; SaaS Roundtable #3 with yet another dozen RAF attendees ; flight to Rio
Day 5: Presentation and discussion with IT group of large utility company with offices throughout Brazil as well as Argentina, Chile, Spain ; Presentation and discussion with Petrobras the biggest (or one of the biggest) Brazilian company in a cool building whose architecture was inspired by a offshore oil platform.
Day 6: Good Friday, bank holiday in Brazil no customer visits, spent a couple of hours walking on copacabana and ipanema beach (one word: WOW!); packed and flew home. Good bye Brazil, I will come back! :)
Topics of discussion:
As you can imagine many topics were discussed in a full week of presentations and customer visits, below a list of the most discussed topics during my visit: (I did not include Futebol, how can an Italian not talk about Futebol in Brazil, a lot of discussions during lunch/dinner were about it :)
How to get started:
Most likely the most common question/discussion was around moving from "traditional" to "SaaS". Interestingly, it was more about HOW than WHY; questions were around first steps, the resources available, the common pitfalls, the technologies and/or framework available etc. Our architecture msdn site, LitwareHR sample app as well as the recently released workshop material hit the mark here. It was quite amazing to learn that quite a few people had already downloaded LitwareHR and even more knew about the "three headed monster" :)
Not too surprisingly, another common topic, mainly driven by the architects working in enterprises, was integration, i.e. how to incorporate a SaaS solution into an existing IT environment; not as a silo (that, they knew how to do :) but as an integral part of the IT portfolio. A few people framed the questions as: what would a "extended" IT portfolio look like. As mentioned a few times in this blog already, the integration problem is, in my opinion, a more general "SOA" problem, i.e. a "SOA" spanning across the corporate boundaries, introducing additional challenges in terms of flowing security context across firewalls, managing data islands across the Internet etc.. Again, not surprisingly, the 2 main integration areas of interest were Identity (single sign on) and data. Business process integration did not come as often, I don't know whether it was because SSO and Data was complex enough and took most of our discussion time or whether there was generally less interest (to be verified). My takeaway is that more pragmatic guidance is needed here. Identifying the issues is one thing, providing clear paths to solve them is another. Some good pieces of guidance are available for identity and data here and here but I'd love to offer a LitwareHR-like sample showing best practices around software in the cloud and software on premise integration and composition. (added to TODO list :)
Performance and SLA:
Performance and SLAs (service level agreement) came up several times. A common question around performance was the performance impact of a metadata driven architecture (accommodating extension field, parameterized workflow etc.). There is clearly an impact on performance as workflows are instantiated on the fly, additional table joins are needed, but I don't have the exact numbers. We could use LitewareHR and perform some load/stress testing, but this is something we have not done yet. Note that you could actually do it yourself as the code is available. If you do, please share the numbers! Interestingly, the SLA discussions were not only about how to measure an SLA through performance counters, management events etc. but also how to properly define an SLA. Let's not forget that offering an SLA is a fairly new concept for ISVs who are generally used to "throw the software over the fence". "Technical" SLAs such as machine uptime or average response time are easier to define, but do not mean as much as "business" SLAs that would define end-user usage metrics. We spent some time defining what type of business SLAs could be defined but I am not sure we ended up being very successful here. SLAs around data led to quite a few discussions; typically around how to properly define data protection (backup and recovery) SLAs and penalties for data loss or data leakage (another tenant seeing the data). Another common discussion around SLAs was: where should the SLA be measured? Most commonly, SLAs are measured at the edge of the provider's datacenter, but it does not really reflect the actual experience of the user (what if the Internet is slow?). The impact of a smart client on the SLA was also discussed. As you can see, a very prolific topic. This is very good example where an ISV/hoster relationship can be very beneficial as hosters are quite familiar with the SLAs aspects.
The notion of Trust was often touched. Trusting the provider with the data of course, but another interesting aspect that came out is trusting the metering/billing of the provider. If the customers are charged by usage or per transaction, how can I (customer) make sure I am billed for what I am actually using? Of course, it is mainly about trust, but we also discussed the notion of non repudiation systems as part of the architecture and/or dual metering systems, one on the provider side, one on the consumer side and then re-concile. It would be a little bit like bringing your own meter in a taxi and compare the fare at the end of the run :)
Sales and Marketing:
Sales and marketing aspects came up a few times. The 2 main questions were (a) how to successfully "distribute" a SaaS solution i.e. how to create strong channels and (b) how to promote/create awareness around a new SaaS solution. For the channel discussion we discussed the notions of marketplaces and aggregators; for the promotion aspects we often ended up discussing "try before you buy", telemarketing approaches and search engine optimization.
OLTP vs. OLAP:
A very interesting topic raised by a Business Intelligence ISV and a few enterprise customers was BI as a service (one could easily include reporting). With the rich visualization requirement, the multiple data sources as well as the huge amount of data to be manipulated/transferred over the web, the question was how suitable are BI type solutions for a "as a service" delivery. To be perfectly honest, I don't know; I would need to spend more time thinking about this, but it is clear to me that OLTP type of applications have an architecture that is slightly less in dissonance with service delivery than an OLAP architecture. This said, OLAP will end up being offered as a service (some are already doing it); but my guess is that it will be done more as an hybrid architecture with a lot of rich capabilities on the client mixed with services in the cloud.
Finally, a topic that was not discussed very often, that I think will come soon, once the maturity of SaaS will grow in Brazil (and worldwide) is Composition; how to combine through a unified UI multiple services and how to make events of one service feed the other ones. This is the "mashup" concept; this can be done client side of course, but more interestingly, it should be done server side, so some sort of SLA on the mashed-up service could be offered.
Anyway, as you can see a lot of great discussions and a lot of questions left opened. Architecture guidance around SaaS is very far from being done... Cool! lots of fun months ahead of me. :)