We had a really good session last week with an analyst who covers our industry exceptionally well — and we had a really interesting debate about what multi-tenancy is, and whether it was import for SaaS (or any of the growing number of other “aaS’s” sprouting up…).  For the record, I have a pretty simple definition of multi-tenancy, and I think true multi-tenancy is ultimately required for successful SaaS platforms.  If you are deploying a new stack/instance/virtual machine/OS for every new client, you are not multi-tenant.

When it comes to assessing whether or not a service provider is multi-tenant, I think of the landscape as:

• Sub-divisions - single-tenant
• Townhouses/condominiums - virtualized multi-tenant (meaning, in my opinion, not multi-tenant)
• Hotels - true multi-tenant

Sub-divisions:

If someone is buying hardware, installing an OS, and then populating it with software for you, this is not SaaS, it is hosting!  They may “position” (aka, spin) it as SaaS for purposes of enticing venture capital, but it is not.  If you even know what kind of hardware you are running on within your service provider, you may be in trouble.  If a service provider “consults/notifies/alerts” you when they are doing a memory upgrade — you live in a sub-division.  There is nothing wrong with this, hosting is a very mature business; but you are receiving only operational economies of scale (assuming the provider can operate a data center better than you can…).

So who cares?  Well, you do, maybe.  If you want to be able to scale down as well as up (meaning start small and grow with activity), a suburban home is not a great idea.  I love my 5 bedroom, center-hall colonial, but surprisingly I paid a 5-bedroom mortgage even when only 3 bedrooms were occupied (now its 4, and we’ve decided to live with that 5th bedroom “underutilized”).  I also do not have much cost-efficiency with my neighbors beyond the roads (network).

Looking at it in IT terms, the server infrastructure, disk subsystem, LAN connections, etc are all dedicated.  The OS instance, software licenses, patches, upgrades, etc are being done expressly for me.  This is a great model in many cases, but it is not SaaS.  If you have a say in what version you are running, you are probably not in a true SaaS environment (if fact, here we talk about doing away with version numbers altogether…)

Townhouses/condominiums:

If you live or have-lived in a townhouse or condo, you know that this is really a hybrid model, with some shared infrastructure (typically building maintenance, lawns upkeep, etc), but still essentially a dedicated model once you are “inside”.  In the era of time-sharing this model was fantastic, because computer time was so expensive that the hardware was all we thought about, and software was just “there”.  Although you have some additional shared infrastructure with your neighbors, you still are on the hook for furniture, plumbing, electrical, HVAC, decorating, etc.  Most of us of course prefer it this way in our home life, but not necessarily so in the data center…

In the IT world, a common townhouse model is “virtualization” or “multi-instance”.  In this case, a dedicated software environment (typically from the OS up) is deployed for each customer, on shared hardware infrastructure.  This has a number of advantages over the “sub-division” model, but is still not (in my opinion) SaaS, for reasons we will come to in a moment.  Advantages include not only shared hardware, but efficiencies in hardware management, from server upgrades to back-up management.  This can be a highly efficient model when used for applications like web-hosting for instance (where the hardware cost to software cost is more favorable to hardware).

Under typical 21st century situations, however, this model is not SaaS because the dedicated capacity still includes — usually — an operating system, versioned technology stack, and potentially many customizations to the OS/networking environment that must be operated and maintained.  Look at just one example, OS security patches…  If the OS vendor (or open source development project) issues a patch, it must be checked and out and applied specifically to your environment.  Whoever is doing this may decide to forego this if you do not fund the work, or you may request that the vendor honor a “blackout” period and not apply it right away.  Meanwhile, other customers in the townhouse community may make different choices.  At the end of the day, everyone is “different”, which is actually worse than the “sub-division” because in addition to managing all of that, the operations team has to keep track of who did what when….

Hotel — true multi-tenant:

When you stay in a hotel, whether for an extended stay or overnight, you may worry about the location, the food available, shuttle service to/from the airport, and whether the internet access is fast enough — but I am willing to bet you will not worry about the air conditioning system.  The air conditioning, and a myriad of other details, belong to the proprietors of the establishment, and under normal circumstances you will not need to give them a second thought.  So it is with true SaaS.  SaaS is as much defined by what you don’t have to worry about as what you do:

• installation
• upgrades
• server rollouts/deployment
• backups
• versioning of any sort
• capacity

In its truest form, SaaS bears a striking similarity to the outstanding telecommunications infrastructure offered by the likes of Verizon, or the ubiquitous email connectivity of the BlackBerry (noticed very much recently because of a rare disruption in service).

But what does this have to do with multi-tenancy?  Multi-tenancy is the ultimate discipline, forcing providers to build highly scalable systems because they have no choice.  A typical node of GXS’s B2B outsourcing service might perform work for a dozen clients — which prevents us from doing anything special to the core stack for any one of them.  As a result, if needed, a client may be moved to another node or spread across several, with no change on their part.  We do this not because to operate at scale we must operate a multi-tenant environment (full disclosure, we do operate some dedicated environments to meet data privacy or regulatory requirements, but they are more costly both to us and to the customer).

If there is no multi-tenancy, customer specific configurations will become the norm, assuming the provider is customer oriented.  Over time environments will all become “exceptions” to the standard.  Initially happy customers will become dissatisfied as the promise of SaaS is unrealized, because they have bought space in a data center, not a true service offering. 

The past couple of weeks I have been busy helping with the roll-out of our new integration offering between the GXS Trading Grid and Microsoft BizTalk 2006 R2, a very exciting collaboration between GXS and Microsoft (and worthy of a blog entry of its own, very soon…).  Having wrapped up a couple of key activities, I started — as is my custom — to wade through a 10 inch stack of magazines (I checked!), and who knows how many emails…

Back in September, CIO Magazine started talking about the balance between outsourcing and innovation, referencing an innovation crisis (this is a blog entry, the print version of CIO had a longer and very interesting piece, but this gives you an idea).  This is the latest of a series of well-written articles on the dangers of leaving innovation to others (another I enjoyed, around manufacturing, back in 2005, is here).  R&D is a topic near and dear to my heart, as it is part of my role here at GXS, and the dangers as I see it fall into two categories:

1. Leaving R&D to outsourcing companies (traditional) may result in no innovation beyond cost-reduction
2. Too much dependence on even innovative partners can dull the innovative edge of your own team

I have a strong belief that every company needs to look for the opportunity to innovate in their core business, and one of the best ways to accomplish this is to free up resources in every other part of the business by partnering with companies who do that as their core business.  While this may address #2, it can put you in jeopardy of the first danger, which brings me to the knock-down, drag-out SaaS versus outsourcing.

What really got me thinking about this was a string of articles/blogs/etc along the lines of SaaS doesn’t matter, business value does…  On the surface this is really hard to argue with, as most generalizations are.  But like most generalizations, taken to extremes this is a dangerous idea.

In the CIO Magazine article, the problem surfaced was that most outsourcing contracts are based on the achievement of SLAs (service level agreements).  Traditional outsourcing companies have an enormous incentive to standardize and drive cost down, and pretty much nothing else.  This is the complete opposite end of the spectrum from commercial software vendors, who live and die by new license revenues, and have an enormous incentive to innovate.  Unfortunately, this innovation can only be realized through upgrades and installations, so customers receive benefits unevenly, only as the upgrade.

So how does this translate into SaaS out-innovating Outsourcing?  SaaS (software as a service), is a service based model like some traditional outsourcing, with the economic incentives of commercial software (if we don’t innovate, we quit winning new business…).  Unlike traditional outsourcers, who contain costs by limiting change in a given client (admittedly to preserve service levels), a SaaS based offering controls costs by applying its innovations to all customers.  If this sounds crazy — it’s not.  Change, in the form of innovation, is much less expensive than variation.  If I add new features and capabilities to my entire customer base, I have a better cost model than a software company supporting 3-5 different versions of their software (which is why most software companies “end-of-life” versions with depressing regularity).

This is the best answer to the conundrum posed in the CIO article about how to leverage the expertise of outside companies without risking loss of innovation — work with organizations that must innovate to survive.  SaaS is a marketplace with many of the cost efficiencies of outsourcing and an incredible pressure to innovate and invent (don’t believe me, look at Salesforce.com, Amazon’s web services, Microsoft’s Live Services, etc). 

And if people tell you that the business model doesn’t matter (SaaS, outsourcing, etc), tell them to talk to the music industry about iTunes, or the CRM industry about Salesforce.com.  Business models matter, they drive behavior and economics.  Innovation will always be strongest where companies need it to win, and that is the team I want to be on.

Something in one of my recent posts ( SOA versus ESB — conflict or collaboration ) struck a chord with Dan Foody over at Progress Software, and his post about understanding your organization before you architect has now gotten me thinking.

The Chief Architect of the GXS Trading Grid is a guy named Jeff Barton, and he has a favorite phrase on this, “architecture by org chart”.  This is somewhat different from Dan’s blog entry, as Jeff’s point is the tendency of development teams to be more Ptolemaic than Copernican (basically, teams make the rest of thew world revolve around themselves).  As I looked up the wikipedia entries on the Ptolemaic system, I realized just how apt this metaphor was — since it requires gigantic planets in space to spin, perform loops and rotate around Earth to make the math work!

The widespread implementation of SOA requires coordination across multiple teams, who must “do work” on current projects that is — in the short run — exclusively of benefit to other teams!  Over time, and not even that long in GXS’s experience, benefits boomerang as other teams do the same — but this is a leap of faith, and many IT people are not into leaping.  This same challenge is also faced by the proponents of RFID deployments (we’re for that, but that is another entry….).

This is where the influence of CTOs, Chief Architects, and senior developers is make or break. 

Dan references the very real challenges of balancing the power of IT/non-IT groups, but in my experience even balancing amongst different IT teams can be a monstrous challenge.  One technique I have seen work with some success is to deploy mandatory common infrastructure, with some degree of enforcement.  I have seen a few models of this:

1. preferred vendors:  one ESB, database, ERP, etc.  There might still be multiple instances (better be, in the case of databases!), but at least there is a single skillset and technical support connection.  You still have versioning issues, but at least you’re on the right track.  Easiest to enforce if you have centralized purchasing, as they can flag orders for anything “off the list”
2. common services:  you have to go to the “insert capability here” team (ESB, message queueing, database).  Much more amenable to a unified structure, but requires incredible commitment from the teams providing services, and lots of enforcement from above.  The first time a project misses because of an external dependency (”they wouldn’t configure the ESB for us!”), it starts to unravel.  Particularly challenging because the “core teams” are not directly connected to revenue, which can cause issues when budgets are allocated.  This is probably not an option for teams in organizations where IT is not in control — or at least on par — of resource allocation for IT projects
3. outside service providers:  Like #2 above, but using an outside service provider or SaaS vendor.  I admit this is somewhat self-serving, but the difference is that you do not have to deal with internal rivalries, and for-profit service providers tend to have more capacity when you go to them, which is really just a function of scale.  We have many managed services customers who require their divisions to use us for certain functions, and that achieve both standardization and integration (we are already integrated to their back ends).  Easier than #2, but only works for certain problem domains

I’m sure there are other models, and would love if people would add some comments about how it works in their shops.  As much as I would like to say there is a solution to “architecture by org chart”, I think the best we can do is get the architecture to reflect the view from higher up in the org chart (c-level), so that it ends up including the entire organization and its needs.

Catching up on email today, I came across a comment that an EDI professional posted about how frustrated she was with EDI!  In the well-written response to an ec-bp article, she shared her frustration:

“I have not been able to find a solution that would not be very costly to change to and would make life any easier than the way we currently do things. All customers want something different and it is getting more complex as time goes on.” 

In another section:

“Edi in my opinion did not standardize or uniform anything. For example you have hundreds of options on every document. You don’t have to have the same information on your advance ship notice as the other guys. You can request an 855 instead of a 997.”

Guilty as charged…

Like many industries, ours has focused so much on empowering users through advanced features and complete configurability/customization that it seems nothing is simple.  This is partially a consequence that the real drivers behind e-commerce are the PRACTITIONERS, who are often at the leading edge of supply chain practices, which sometimes get complicated.  As a service provider and a software vendor, we owe our customers powerful offerings that are as easy to use as possible.

But if we’re not there yet, we are trying — and you don’t have to take my word on it!  Many of our key initiatives over the past couple of years are targeted straight at the issues highlighted, including:

• Development of e-Commerce Accelerators to make it easier for small and medium businesses to connect into global e-commerce with the software packages that run their businesses
• Managed services that can accept most protocols and translate partner formats into whatever you want internally
• Integration to other software vendors’ products (like BizTalk R2, webMethods, etc) to give customers choices and allow them to use what they know
• Ever more flexible web forms solutions that leverage Web 2.0 technologies

Now, before you right this one off as a sales pitch, time to come clean — as I said, we’re not there yet (and neither is our competition), and here are some reasons why:

• Integration is still very tough.  Even with standard integration options, if customers have customized their own software, it can require professional services (ours or someone else’s) to get it all setup and working
• Mapping between standards, and customized usages of the same standard, is still hard.
• The world of e-commerce processes is still largely “un-standardized”.  There are no widely used methods of specifying the rules for which EDI documents a given partner uses, and in what order (RosettaNet PIPs were ground-breaking here, but many factors have limited adoption — including complexity)

So, is it hopeless?  Absolutely not.  More companies do e-commerce, and in particular EDI, than ever before — and at a lower unit cost than ever before!  Keep on going, and we will too, and keep voicing frustration and constructive criticism, because we’re not there yet…

In most areas of business software and services today, buyers face a choice between special, purpose-built software, and modules of more generic frameworks.  As a for instance, you want to manage a to-do list, so you can either use Outlook’s Task feature, or get a specific tool (or keep a list in Excel, but that is another blog post….). 

Likewise, when someone is looking to manage inventory, if they are an Oracle or an SAP shop, they can either buy the sister module for their stack … OR … get a “best of breed” piece of software from another vendor.  (As an aside, you should NEVER, NEVER, buy a module of a rival stack — believe me — just don’t do it…..!!!).

In the world of B2B, this problem is even more difficult to solve, as most B2B programs involve integration to internal systems (often via middleware).  Special purpose B2B programs tend to have excellent partner management, solid translation, and good orchestration capabilities…. but ….the business process management, analysis, and extensibility generally cannot hold a candle to the full-fledged platforms offered by webMethods (now SoftwareAG), TIBCO, IBM, BEA, Microsoft, and — increasingly — SAP.

This has led to a couple of approaches from the purpose built side

1. Build on top of a strong horizontal platform.  This is our approach in our partnership with webMethods/SoftwareAG, with our TG Enterprise Gateway offering.  The goal here is to deliver a specialized application for traditional high-scale B2B messaging on top of a flexible powerful framework (essentially having your cake and eating it too)
2. Expand the platform to become a full integration suite, and compete with the existing enterprise infrastructure vendors.  This approach works well for some environments, but creates tension in enterprises where there is a strong bus already in place.  It also has the unintended effect of reducing the effort expended to integrate to “competing” environments, reducing customer choice

On the other “front”, the large infrastructure players are trying to consume the B2B space, but face challenges of their own.  Things to watch out for include:

• solutions that are too “fine-grained”:  EAI is typically large numbers of small messages, requiring very fine control.  B2B on the other hand, tends to be characterized by much larger transactions (documents), but lower volumes.  Using a standard EAI approach is often sub-optimal
• machine to machine orientation:  EAI systems are often very geared to connecting systems, often using adapters.  Many will simply consider partners to be “systems”, and model standard protocols as “adapters”, but this is a problem because it can have the unintended consequence of tying a partner to a protocol, creating issues when a partner changes technologies
• in-line translation:  because they are optimized for high volumes, the focus of data transformation in platforms is operational efficiency.  The issue is that B2B mapping is quite a bit more complicated than EAI mapping, and the folks that do it are often not traditional developers.  Many products require mappers to use Integrated Development Environments (IDEs, like Visual Studio or Eclipse), which are often not the right tool for data transformation

The truth is that designing the correct solution for B2B is still very challenging, and the growing capabilities of the infrastructure platforms make it more challenging still.  For my part, if B2B is a major part of your IT operation, I still believe the base platforms are not there yet, but the gap is narrowing.  There is a lot of merit to the hybrid approach (a B2B product built on a strong general platform), but selecting the right approach still involves extensive evaluation and a strong knowledge of your own — and your vendors — technology strategy.

My apologies for the title, but I couldn’t resist…  I was part of a meeting with a very interesting software technology we use internally (AptSoft), and we had a spirited discussion about the role of BPM, the role of CEP, and which is best suited for BAM.  But first, let me expand the acronyms:

• BPM == Business Process Management
• CEP == Complex Event Processing
• BAM == Business Activity Monitoring

Rather than a hypothetical discussion, I want to position each of these in the world of electronic commerce, especially when traditional EDI documents are at issue.

BPM is about “managing the expected” (before I get angry posts from BPM devotees, I do not mean only the “success case”, but the finite universe of expected “paths”, including errors and timeouts…).  Given the way modern electronic commerce plays out, this encompasses most of what goes on.  When a purchase order is issued (say an X12 850, for our purposes), we may expect a response within a certain period of time.  Either the response, or its absence is reasonably predictable, as are the ensuing shipment notice, invoices, RAs, etc.  Although much can go wrong with this business process driven by EDI documents — most of it is predictable, and can be nicely modeled using a BPM tool.

But what it I get a shipment notice for something I didn’t order?  Or what if sales are collapsing (demand) for something that I am ordering?  Or what if a price changes, as sales fluctuate and shipments are late?  Or suppose that not only did Partner ABC not acknowledge my purchase order, but he has not “done anything” for six hours — even though I normally receive traffic from him every 15 minutes (some partners are very needy….).  These situations are examples of problems that are better addressed by CEP, or Complex Event Processing.

My rule of thumb is that if the occurrence is not “likely enough” to be modeled in a process diagram, you should not handle it via business process management.  Also, if you are looking to correlate events across several processes (like a partner suddenly going “dead”, or sending bad data in all of their communications), BPM is likely to disappoint.  The reason is reasoning (pun intended).  BPM tools are following a defined process, and are usually not rules driven.  CEP systems, on the other hand, use sets of rules to analyze and respond to events in context (this means that each event is considered in light of all the events that occurred earlier — where appropriate — and all the subsequent events).  I consider this kind of rules based process to be “reasoning”, which is what enables such systems to respond to circumstances on the basis of “principles” rather than process models.

So given this amazing “reasoning” capability, why not use CEP for everything?  Because BPM’s predictability and clarity are among its greatest virtues.  Having sat with customers and sketched out their business processes on many whiteboards, I would not relish attempting the same exercise by “writing rules”.  Rules engines are deeply enmeshed in mathematical logic, and not necessarily a natural way of thinking for many people.  Also, the CEP system’s very flexibility is not an asset when you are trying to execute the exact same process a few thousand times.  Your auditors (or the government’s) will likely appreciate the predictability of standard BPM.

I firmly believe there is a place in most supply chains for the application of both technologies — but what about business activity monitoring?  BAM is all about seeing what is going on while there is still time to act on it (everything beyond that is more properly data-warehousing…), and that means BAM needs to have data from both BPM and CEP.  “Talking” to BPM systems will let your business monitoring tell you what is going on in terms of the “plan” (on target, delayed, in error, etc) and the micro level, while CEP provides information on the unplanned and the macro level.  Basically, even if you are using a BAM solution that is a component of a BPM or CEP suite, it had better be hooked up to the rest of the world…

I recently attended the Forrester IT Forum at the Gaylord Opryland in Nashville. The conference, and the hotel are both favorites of mine, though sadly I experienced less of each than I would’ve liked. Having said that though, the sessions I did attend were excellent.

Some of the best sessions are often surprises, and for me that was the case with “Using a Goal Tree to Measure and Manage”, by Jean-Pierre Garboni (VP of Forrester). I was a quantitative business major in school (no, that is not an oxymoron, it is called management science or operations research), so I thought it might be of interest. Far from an esoteric discussion of quantitative methodology though, it was asystematic attempt to explain why the millions of dollars of investment in monitoring have not given us more insight into customer experience.

The answer lies is a pattern so common it is almost a cliche — we are measuring and monitoring infrastructure one piece at a time, and thereby failing to get the “big picture” (I am really, really over simplifying here…). Basically, we are best at measuring things like uptime, transaction rates, queue depths, etc; all of which contribute to outcomes, but are not good representations of the entire outcome(s). This is further complicated by the fact that there are different outcomes for operations,”the business”, and the customers.

This may seem obvious, but if you are currently building/using SOA based applications and services, I’ll bet you’re not ready for this. For instance, if you have the ability to dynamically add capacity to your SOA service, is that load management capability talking to you operations management infrastructure? If I add a node and it runs slow, can I recognize the solution that is impacted? Can I resolve down to customers? This has always been an issue, but in an area of SOA and virtualization,it is an even bigger deal.

The exciting part of this talk, from my point of view, was the methodology. Basically, you start with a high level goal (roughly equivalent to the successful outcome), and a modeler (person, not a piece of software) decomposes that into systems, processes and ultimately functions with measurable results. The idea is that the functions are well-suited to the current suites of monitoring/measurement, and the model helps us to roll this up into a fair approximation of the outcomes. The largestbenefit may in fact be the way this approach gets people thinking ‘top-down”.

I recently had the opportunity to chat with Geoff Crawshaw of OpenAir, about the approach they have taken to managing their software as a service offering. GXS is an OpenAir customer (we use it to manage our professional service teams projects and time tracking), and we recently had an internal session to look at how we use OpenAir, and what is distinctive about it as a service — things that would be difficult to match through the purchase of traditional enterprise software.

What we came up with was not surprising:

• We were able to ramp quickly, over a three month period in our case — globally. This may not sound fast, but the truth is the service was constrained by our ability to load data and train people; at no point did the software as a service slow down the process
• New features arrive on a regular basis without any “upgrade”, in fact — there are no version numbers (I cannot state how amazing I find this. It doesn’t sound like a big deal, but it is — see below about “feature switching”)
• Costs scale with usage — in this case the number of seats. The service is pretty generous here though, as it is very easy to download data (almost every page has a “download” link that can retrieve the data into a pdf or spreadsheet ), so only people that need to “use” the system need a seat

I say these are not surprising because this is what you generally associate with SaaS. What was more surprising was the following:

• customization: the system can be both customized and personalized. Individuals can change the layout of screens (order of fields, what fields are shown, sorting, etc), and create their own reports
• extensibility: new attributes (data fields), reports, etc can be easily added — all through a web interface
• integration: there are techniques to integrate (both batch and realtime) to internal systems (traditional enterprise software)
• speed: the system screams. While I certainly would not say I would expect a hosted service to be slow, I am genuinely surprised that it is quite a bit faster than even our internal portal

Suffice it to say that most of us, and myself in particular, were intrigued — so I asked for a meeting.

Geoff shared with me some of what I would call the “culture” of development at OpenAir. First off, PageBuild (how long it takes to render the page from OpenAir’s point of view) is the key metric — and they obsess over it. They have detailed analysis about how customers perceive speed (basically, if 80% of the pages render in less than a second, with an average of .3 seconds, customers think its fast), and they work like crazy to hit those targets. Deployed features are monitored for PageBuild,and yanked back (see feature switching, next) if they slow things down. Note that being able to regress is a big advantage of the SaaS model as well. They aggressively use existing technology (particularly minimizing database hits), but it is the attention — rather than technology — that keeps it fast.

But they do have a very novel approach to feature deployment — and it is very specific to the SaaS model. They do not think about releases as a packaging of code, but rather as an event that concludes a development cycle (which run about 6 weeks, 4 for coding and 2 for testing). “Features” are somewhat independent of each other, and are deployed using “switches”. Most features are deployed “switched off”, until support can reach out to customers and determine if a feature should be “switchedon” for a given customer. The amazing thing about this feature switching architecture is that the application layer is shared for all customers (each customer has its own database, but customers share a common “farm” of application servers).

This points out another major difference from traditional models (and also helps explain why version numbers are redundant), all of the customers are on the same codebase. This seems obvious since they share the same production application servers, but this means that there are no “old versions” to support. If you are a software or service vendor, you can appreciate the incredible productivity gained from this — which translates into higher quality (focus on single version is powerful), and muchhigher support productivity.

One final point of discussion was the difference in business model, which I know helps GXS succeed as well. In the Software as a Service model, the bulk of revenue comes from existing customers using the service (this is how GXS has operated for its entire history). This is very, very different from enterprise software, where license revenue is the primary contributor of revenue (maintenance is important, but customers are “invested” once they pay the license fee, and switching costsare historically very high….). The effect of this is to focus SaaS vendors on features that drive value in the opinion of current customers using the system, while traditional enterprise software companies must tilt more toward features that appeal to buyers of software. Geoff makes the point that SaaS companies have the upper hand because their financial rewards are better aligned with continuing customer satisfaction than software vendors — and I agree.

Yesterday I attended part of the “Microsoft across America” tour, which was a session evangelizing Vista and Office 2007.  I had to leave somewhat early (missed my chance to get a free copy of Office 2007….), but I must say I was very impressed by what was discussed (I was in the partner track, which was focused on people delivering services to mostly small and medium businesses).

It is pretty fashionable to bash Microsoft, Read the rest of this entry »