Gianpaolo's blog : SOA

Build - Run - Consume - Monetize

gianpaolo — Mon, 21 May 2007 21:24:52 GMT

Build - Run - Consume - Monetize a.k.a BRCM (pronounced "breekam"?!) is a simple model that I am experimenting with to explain the primary concerns of each of the "actors" involved in software delivered as a service as well as understanding the multiple angles of platform support required by this fast growing trend. Below a high level description of this model. Being early thinking, do not hesitate to provide feedback and/or leave comments!

Build

The primary task of build is to encapsulate domain knowledge into code. The main concerns are around Application Architecture. There are 3 aspects of build: The creation of the features, the internal optimization, the designed for * (pronounced: "designed for star"). Let's briefly go through these 3 aspects.

Creation of the features:
This is of course the core value of the application: the business logic, the rules, the data model etc. This should be minimally impacted by the delivery or monetization model of the application. It is quite clear to me that the features you create for helping, for example, an enterprise better manage its supply chain, has little to do with whether it is monetized as a subscription, a perpetual license, delivered on the web or on premise. A "business logic" feature is a "business logic" feature. Besides, you might want to monetize the features in multi ways so separating the two, at least conceptually is good.
Internal optimization:
I call internal optimization the elements introduced into the architecture that benefit the service creator, but will be, at least in theory, unknown to the consumer of the application. My canonical example for this is multi-tenancy support. Deciding the level of support of multi-tenancy is an internal optimization of your architecture. (This post can help understand some of the implications.) The buyers might benefit from your multi-tenant optimization since you might decide to pass the saving to them but you could, assuming that the competitive landscape allows it, use this internal optimization for higher margins. Or you could be completely multi-tenant unaware and still have a great value proposition for your customers.
Another possible optimization is the use of "cloud services" as part of the application architecture. For example, if the reading patterns of your data are not uniformly distributed (i.e. you have 20% of the data that is read very often and the rest is read very rarely); you could imagine to only store the 20% "hot data" in your local hosting environment and for the "long tail" of data, use some utility storage a la S3. This would allow you to be in control of your most important data and tap into beneficial cost structures for data that you need to store but do not need to serve often. The relative cost of storage vs. computation vs. network was discussed here. There are many other examples of internal optimizations.
Designed for *:
Designed for * (note that * "star" here is used as the wildcard identifier we all have learned to love in our Unix,dos etc. days) is a term I have started using in my conversations with service builders. It encapsulates all the specific design decisions and additional elements added in the architecture for "facilitating someone else's life". An example of this would be "designed for hosting" (dfh). Designed for hosting would be all the things that a service creator would add in the architecture to "play well" in a hosting environment. For example not use absolute file paths, no need of elevated privileges, no assemblies in the GAC, implementation of halting interfaces (Pause/Stop/Restart) etc. Designed for composition (dfc) would be the things added to the architecture facilitating compositions (mash-up/aggregation), for example single sign on support, multi-protocols (REST, SOAP), multi-format (XML, JSON, ATOM) support... Like with internal optimizations, there are many instances of designed for *

These three aspects are neither sequential nor separate, all three have to be taken into account when making design choices, but separating the concerns I think is helpful. When developing your code, you could compare and prioritize the efforts you are putting into facilitating others vs. optimizing your code vs. creating the appropriate feature set. With LitwareHR and a couple of whitepapers (here and here) we have covered how to use the Microsoft platform for the creation of features delivered as a service and touched upon some internal optimizations aspects, in the future expect more guidance around design for *.

Run

The #1 goal of run is to provide a hosting model. The same way the Windows OS is the hosting model for a .exe, or IIS is the hosting model for ASP.NET or SQL for store procedures, a Service Delivery Platform is the hosting model for software delivered as a service. The objective of an SDP is to deliver the software at the lowest cost possible for a agreed upon service level agreement (SLA). The concerns are therefore around Delivery Architecture. The aspects of run are:

The depth and breadth of support for software delivered as a service
The processes in place to maintain an efficient, reliable, available, scalable, high performance service delivery platform (SDP)
The SDP SDK. (how to expose the SDP as a programming model)

Eugenio provided some information about SDPs here (a must read) and as mentioned previously, this is the topic of our next whitepaper which should hit the shelves early June. So stay tuned on this one.

Consume

Consuming software as a service is a very different discipline than building or running it, I would go as far as saying that they have pretty much nothing in common. From an architecture perspective, consuming cloud services is mainly about integration and aggregation as mentioned in this August 2006 post. The canonical example I use for illustrating the need of integration is to think about how to retrieve the opportunity pipeline stored in the cloud (e.g. CRM live) and feed, with this information, the revenue forecasting system running in the mainframe so that the CFO can prepare for the analyst call she is having the next day. Since this scenario crossed corporate boundaries, "internal tokens" such as Kerberos have little value; a new set of protocols and tokens (e.g. SAML tokens) as well as the notions of claims and secure token services need to be embraced. But this is only about Identity and single sign on (SSO). What about data management and canonical schemas? What about business process integration? Governance? As you can see, consuming services in a many-to-1 fashion requires some deep architectural thoughts and additional support from the underlying platform. Initiatives such as Biztalk Labs as commented by Clemens here are very important components for such future platforms. More established products such as AD-FS are also great enablers. The goal here, I would say, is to be able to "platformize" a lot of common requirements, instead of treating all the integration projects as "ad-hoc".

For those who have not read it, the SaaS: an enterprise perspective whitepaper provides some additional information about this. But additional guidance is required around:

Integration and aggregation:
How to mix and match on premise and cloud services regardless of the cross boundaries aspects: identity, data, business processes, UX, tools and governance. (hey, that sounds awfully similar to the pillars of SOA and this old post can always help.)
Procurement strategy (buy/rent/build):
Enterprises used to have a buy vs. build choice. Now they have a buy vs. build vs. rent choice. Understanding the right decision factors (when to buy, when to build, when to rent) so that the most optimized IT environment can be created is key.
Vendor / SLA management:
With increased dependency on software suppliers, the discipline of business continuity, supplier relationship management as well as SLA management will evolve. Another key area where a platform can provide great support.

Monetize

I have to confess that I have not spend too much time in trying to generalize the architectural challenges related to the monetization aspects. This said, as mentioned in previous posts, monetization can be put into 3 main categories: subscription, usage based (a.k.a transaction based) and ad-funded. Below a few comments based on my only superficial investigation.

Subscription:
A "per user, per month" scheme, which happens to be, at least currently, the most popular option, can be implemented mostly "out of band". (is this why it is the most popular option?) What I mean is that the billing/invoicing can be mostly separated from the application itself. A business contract is established for say 50 users, a monthly bill of 50 x cost per month is sent to the buyer.
Of course, there are multiple areas where a provider could benefit from a tighter linkage between the order system and the application. Automatic/self provisioning comes to mind, but also more accurate monetization. A non paying customer could be cut out of the system earlier, a customer using more than the allocated seats could be billed for the additional used seats at the end of each cycle... The provider of the service delivery platform can play an important role here.
Usage / Transaction based:
A usage based monetization scheme (by definition) requires the application to know about how it is used. Metering and raising monetization events becomes a key piece of the architecture. Dynamic pricing modules might be needed if a specific usage depends of external variables such as time of day or simply who the user is. Non repudiation might be required based on the trust levels and/or the cost of a specific transaction. Usage reporting becomes critical allowing customers to monitor in real time their usage and therefore their cost. Tools allowing to cap the expense or simply being notify when the cost goes beyond a certain threshold would be a good service to provide. All this is clearly not dissimilar to cellular phone usage where I can monitor how many minutes I have used in my plan, how much the SMS I sent cost me etc. However, it is not something that has historically been implemented by many ISVs. Again the SDP can greatly help here, and it looks like that a "designed for usage based monetization" section in the designed for * book will be needed :)
Ad funded:
Very trendy and at the core of many new ventures business models, the ad-funded model is increasingly investigated. Advertisement being so closely related to the demographics of the audience as well as the intent of the audience (awareness, purchase...), the architecture will need to be able to capture these two parameters to increase advertisement effectiveness. Also, if placement is done within the application, tools, APIs and/or SDKs must be provided to the media buyers allowing them to optimize their campaigns by placing the appropriate ad. Support for rich media, typically video, might become an important piece of the architecture. From a platform perspective, technologies like Silverlight can become a very powerful tool.
With ad funded comes also the possibility of fraud (click fraud or equivalent); understanding how to detect and prevent it, could take a big toll on the architecture. Similarly, being able to "fight" filters or ad-blockers, for example by degrading the functionality if ads are not viewed or clicked, could be required.

Whether the model is right or needs tweaking, one thing is sure, the surface area is huge. Providing the appropriate level of architecture guidance and more importantly full platform support will take some time. The good news is that many things can be used today already, and much more will come over time. In the coming months, expect my team to build on the success and great feedback received on LitwareHR and start exploring all the additional facets of the BRCM model.

As a final note, below a simple table summarizing which aspect you are most likely going to be interested in, based on "who you are" ISV, Hoster or Enterprise:

As mentioned at the beginning of this post, I am just starting experimenting with this model, so feedback and comments very welcome.

Why a Deregulated IT would actually be good for Microsoft

gianpaolo — Sun, 01 Apr 2007 17:11:05 GMT

Following my previous post, some (internal and external) folks have asked me why I was performing seppuku by sharing my thoughts on Deregulated IT :)

Their premise was that deregulated IT, taken to its logical conclusion could (would?) disrupt several Microsoft franchises such as Windows Server and Exchange. By embracing consumer grade assets for part of the enterprise IT portfolio, this model would drastically lower the number of CALs (one of the primary revenue generator in the enterprise for Microsoft) required to run large IT shops and therefore negatively impact Microsoft revenues.

Here is my reply to that:

(1) I am not the one disrupting the current model, smart CIOs considering it are. I am just a messenger or maybe more accurately a “generalizer” of the “one size doesn’t fit all / consumerism” trends; which means that, whether I blog it or not, this type of hybrid IT will happen anyway. Also, although a flattering thought, it is hard for me to imagine many CEOs enacting the IT Deregulation Act just based on my post. If they were… man, I am in the wrong job! I should enter politics and/or redirect my mighty CEO-controlling powers to prevent global warming or something similar. :)

(2) From a revenue perspective, I am not buying the argument that total revenues would be lower. Revenues from a particular big IT shop might go down, I would give you that, but the deregulated IT function has to be performed by someone, somewhere. The performers of the deregulated IT functions (hopefully on top of a Microsoft platform) would partially compensate for “un-purchased” CALs (Microsoft will need to show why and how to do so on the Microsoft platform of course) + Microsoft would have new revenues streams from the big IT guys (or monetize it through advertizing) when the deregulated function is performed by Microsoft (e.g. MSN Messenger, CRM Live etc.). So, although not able to offer a real comparative study, my point is that I am not accepting (at least in principle) the notion of total revenue going down.

(3) Also, as mentioned in my blog subtitle, I am a dotcom refugee happily expatriated at Microsoft, hence I would rather see Microsoft show thought leadership in this space and “own” the change by helping the transition happen from a best practice perspective and of course a product/platform perspective (more about this in my final point); instead of doing the “ostrich”.

(4) Finally, and most importantly, I believe that only Microsoft has the platform breadth to support/enable the Deregulated IT. Of course all the pieces are not there yet (which is OK as no one is really doing it yet :) but many are. In a deregulated IT space, Microsoft would be the one with the most compelling offering; without entering a complex Microsoft-compete discussion, other enterprise vendors (think IBM/Oracle/SAP and the like) would be at a competitive disadvantage. Although fierce competitors in the enterprise space, they lack all the consumer properties (think MSN messenger, MSN Live Hotmail (or whatever it is called these days)) that Microsoft also has. On the other end of the spectrum, a company like Google, which I hear has some quite successful consumer web properties, lacks breadth in enterprise grade service offerings and in my opinion, even more importantly, lacks a suite of server products allowing “on premise” deployment as well as supporting a “build” strategy when necessary.
The world will be hybrid. It won’t be cloud-only or on premise-only; it will not be browser-only or rich-client only… the right mix will be determined by maximizing a cost/value equation whose most important variables will be control, cost efficiency, flexibility and compliance. Therefore, the more hybrid the world is, the more critical it is to rely on a platform covering both enterprise and consumer spaces as well as being able to offer servers and services. And as far as platform breadth is concerned, Microsoft is still far ahead any competition.

Anyway, enough about the theory. I am quite motivated now, to use the next few weeks trying to “put my money where my mouth is” and:

a) Define an hypothetical example of partial deregulation, most likely around email

b) Propose a high level architecture, describing the new requirements and challenges

c) See how Microsoft platform would support/enable it

P.S.

If you are a big honcho in a big enterprise IT and you are interested in exploring all this in more details. Feel free to get in touch with me (gianpc (at) microsoft.com).

The IT Deregulation Act

gianpaolo — Fri, 30 Mar 2007 11:48:40 GMT

Inspired by the Airline Deregulation Act the IT Deregulation Act (or IDA) is a CEO directive whose main purpose is to remove obligatory usage of corp IT services by the business units and expose IT users to market forces.

Of course, there is no such thing as the IT Deregulation Act, but when you think about it; it could make a lot of sense.

In my numerous SaaS discussions with enterprise architects and CIOs of large (very large) companies, I increasingly end up discussing (asked by them) how they could embrace "public" service infrastructures for part of their IT capabilities, for example email (Hotmail) or instant messaging (MSN Messenger). The first time I heard that question (about a year ago) I put it in the "interesting but a bit wild idea" bucket; today I have little doubts left that this trend, sometime also called consumerization of IT (as echoed here and here among others) is becoming very real. Note that they are not necessarily interested in booting all enterprise software out, but rather implementing hybrid architectures where some aspects of IT are managed internally and some others are sourced from the cloud and/or where a subset of their user population has access to a less-featured version of a service (e.g. Hotmail) whereas another set of the population has access to a more-featured version of that service (e.g. Microsoft Exchange). A key motivation of this "one size does not fit all" model is to match the cost of sourcing that service with the value of that service for each individual user.

My premise here is that if you want to follow that path why stop there... why not going all the way and fully deregulate your IT i.e. make all your IT division-offered services compete with external market offerings. In this scenario central IT becomes only one of the many service providers, you (business unit / empowered ex-central-IT-constrained customer) can choose from.

We have all experienced the benefits of the deregulation of government protected monopolies such as the airlines, telcos, utilities (energy) why not push that model to corporate IT?

Of course, this is easier said (or blogged) than done and a lot of pain will be experienced before getting to a better place. But I would argue that it is no different (actually most likely easier) than the pains that national flag carriers, national telecom companies etc... have gone through. The main question is whether we believe that free market dynamics can be applied here, if they can, then deregulating IT will result in higher quality of service and fairer pricing for the end user; which ultimately translates to a lower total cost for a higher total value for the company. Not a bad proposition.

Note that it does not mean that central IT will loose 100% of its "business". If you look at electricity/gas companies or telcos (a part from less than a handful well publicized failures or bankruptcies) the vast majority of previously protected monopolies still have the lion share of the market and are financially healthy. Please, do not misinterpret this as me saying that corp ITs take their internal customers for granted, most don't. I am simply saying that by introducing a healthy dose of competition in the mix, will force the IT department to think very hard about where to compete, where to extend, where to disengage. In other words, think hard about the role that IT will play in the company. By the way, this model would also allow IT to start selling to other companies which could create potential revenue stream into a historically considered cost center.

I am quite convinced that implemented properly, the CEO/COO/CFO and probably most of the business unit VPs will welcome this "deregulation", the role that will get most "heat" (again?!) will be the CIO. But if I were the CIO, I would see that as a tremendous opportunity to turn upside-down the entire IT division and make it a true participant of value creation in the company. It is maybe a bit harsh to say, but if the main role of the CIO is to "just" keep the lights on, the CIO role will be relegated further and further down in the corporate organization where cost reduction will be the only KPI. This would be truly sad, as it doesn't have to be that way.

From an architecture perspective, which is (as usual :)) where the magic needs to happen for this to work, the impact will be significant. Simply put, it will require taking the core concepts of SOA and extending them to cross boundaries, cross services, cross location, cross everything. Governance, Identity, Entitlement, Integration and Composition will be the core pillars of this model. With the notions of Federation, Standards and Metadata as key supporting elements.

As you can most likely deduct from this post, the concept of deregulated IT is still very raw in my mind, but what do you think? Would a Deregulated IT Architecture Best Practices white paper make sense? Feel free to jump in and start a discussion, I think this is a very prolific ground for innovation.

Mr. and Mrs. CIO SaaS will not make your life simpler (but it is not necessarily a bad thing)

gianpaolo — Mon, 27 Nov 2006 11:48:06 GMT

This is the continuation of my previous post: SaaS, CIOs and the Mongolian Steppes . (If you have not read it, you might want to consider a quick scan for context, but not 100% required)

(3) CIOs are rightfully asking themselves a lot of questions about what to do with this “SaaS thing”.

Enterprise IT is complex, no doubt about that. Some argue that the overzealous salesmen are to blame; others point the finger to the gullible buyers. My opinion is that it is intrinsic to enterprise IT where a very large number of variables (often conflicting) need to be taken into account. Typical constraints are cost, time to market, technology dependencies, legacy integration, current skill set, training requirements, vendor viability…

I often compare enterprise architecture to advanced calculus where the goal is to find the local maxima based on a series of constraints.

Above: a multidimensional function showing multiple local maxima (and minima); but that's not exactly the point.

The point is that in my opinion and contrary to what many CIOs are expecting, SaaS will not make their lives any easier. It could actually make them more complex, but that is a good thing!

I can already hear many of you say: “Wait a second?! What are you talking about… I thought the whole thing about SaaS was about not to worry about running the applications. I thought it was about IT staff not to wake up in the middle of the night because the server farm crashed. I thought it was about not to worry about patch management, tedious upgrades etc. How can all this not make my life easier? “

Well, if simplifying operations is the definition of “making my life easier” then yes, it will. But taking full advantage of SaaS in the enterprise IT environment will go much further than simplifying the operations. SaaS will add new dimensions of opportunities which CIOs will have to take into account, using my calculus analogy, SaaS will introduce a bunch of new variables which will make the search of local maxima more complex. BUT (and that’s a big but) the new local maxima will most likely be “higher” than the pre-SaaS ones.

Put differently, by making the running of mundane IT operations easier (i.e. by not running them), and by enabling additional sources of software, SaaS will:

(a) move the CIO attention to the even more strategic aspects of IT,
(b) add additional variables to the already complex enterprise IT equation which if handled properly will lead to a more optimized IT (higher local maxima)

that’s what will make the CIO job more complex; but as I said before, it is a good thing as the CIO function will grow (or grow further) into a core strategic function.

Granted, there is a looooong way to go before we declare victory to IT operations complexity, but the trend is there.

So, what are those additional dimensions/variables that SaaS is bringing? Following a good discussion with my SaaS partner in crime Fred, and another with John deVadoss, 3 dimensions emerged.

1) The “where” dimension

This is about the on-premise / cloud decision. With SaaS becoming/being a serious alternative, where should a particular service run? becomes a key question and a source of optimization.

· Do I keep my HR app in house or do I move it to the cloud?
· What about the new travel management system, should we buy the additional module from our packaged software vendor or integrate with the hosted solution offered by the new entrant? etc.

The where dimension by itself adds a lot of new variables as financial, political, legal and technical considerations need to be taken into account.

Governance is also tightly coupled with this. When IT, being the only holder of the datacenter key, was the ultimate gatekeeper of what runs or doesn’t run in the enterprise, the governance process (although already complex) was somewhat simplified. Now that business units can buy software services directly from the cloud, the control around what runs is lowered. It is a bit like the bouncer at a door in a night club. That person has pretty much full control on who gets in or not… “sorry sir, no sandals and you need a jacket…”; take the same bouncer and place him in a open-air rave in the middle of a giant park, there is no way the same “process” and “control” can be applied.

In other words, by smart sourcing the various services (i.e. finding the right on premise / cloud mix), optimization of asset can be achieved at the “cost” of managing additional variables.

2) The “who” dimension

The who dimension is something I have been discussing with John deVadoss quite a bit lately (albeit not enough). The idea is to provide a different set of capabilities to the end users (CEO, field sales team, factory worket...) based on some overall policies. Some call this the “consumerization of IT”, John calls it “differentiated IT” I do not know who whether he coined the term. The way to think about this is that with a lot of enterprise-like services out there in the cloud (instant messaging, email, desktop productivity…) a CIO could optimize IT by thinking hard about who should get the “true” enterprise grade service (fully featured, reliable, integrated, with backup etc. ) and who should get access to the “consumer” grade version in the cloud, potentially for a lower cost.

Again, although this is an interesting path to explore which could lead to some non negligible optimization of assets, there are plenty of unclear architectural challenges in this model. Some of them are:

· Support, who will support the consumer versions
· Integration, for example SharePoint integrates out of the box with Live Communication Server / Communicator for presence and other aspects, what about if you have part of your user base used MSN or Yahoo messenger.
· Composition, a big trend in the enterprise is the concept of enterprise mashups, how would one mashup “consumer”/cloud services with internal applications is unclear
· Security, by opening the door to a larger set of non standard/consumer software, the attack surface could be increased, patch management will be harder to put in place etc.
· Governance (again), even if some consumerization is allowed, the extend and non wild west proliferation of it will be another challenge to CIOs

Similarly to the where dimension, the who can lead to some interesting optimization but many more variables have to be juggled with.

3) The “how” dimension

This is what Fred touched upon in this post … By consolidating application deployment and configuration into a central delivery environment that uses streaming, virtualization and Web channels, it frees IT from having to deal with managing distributed desktops that may also be running on heterogeneous OS versions and platforms…

It is a little bit what links the where with the who. Once you have identified where you will be sourcing the various service from, and you decided to whom you will deliver what services, the how dimension will dictate the best delivery model. Virtualization (both session and OS virtualization) will play a big role soon.

(I suppose what, when and why will be a but jealous of not having their dimension :) )

More seriously, it is important to understand that these optimizations might have been possible before SaaS, but SaaS amplifies the optimizations that are possible. It is only when you start introducing SaaS vendors and consumerization from the cloud, that the where and who dimensions make sense. And when you start dealing with the where and who, the how comes quickly into play.

As you might have noticed, this thinking is not fully formed in my brain yet, but I believe the core is there. And in any case, emerging /not fully tested thinking is what blogs are about aren't they? :)

Comments/Thoughts very welcome.

Analysts (finally?!) in tune with our view of the world?

gianpaolo — Tue, 09 May 2006 08:05:00 GMT

Today I was forwarded this AMR research paper

A couple of interesting sentences, that I believe I heard somewhere already, but where… J

One of the biggest misunderstandings regarding the evolution of companies toward service-oriented architecture (SOA) is all that’s needed is to buy an SOA product. Unfortunately, it’s not that simple. SOA is not a single product: it is an architectural approach designed to support maximum flexibility and reuse of existing assets.

[…]

Given the distributed nature of a composite application, an SOA without MDM [master data management] would be neither manageable nor scalable.

The paper is still using the ESB terminology, I guess it will take a bit longer before this will go away as well :)