| |
ATOM Feed
What is Software + Services?
#
Sunday, June 29, 2008
Exactly what Microsoft means by the term Software + Services (S+S) can be hard to puzzle out. For a good example of the confusion this can cause, see Phil Wainewright's post earlier this year about Microsoft's S+S mantra, then read the response from Gianpaolo Carraro at Microsoft and Phil's rejoinder to that. While the exchange is interesting, I'd argue that their underlying premise is inaccurate--S+S doesn't mean what Phil thinks it means.
It's easy to assume, as Phil seems to, that S+S refers only to scenarios combining both on-premises software and cloud services. Yet when Microsoft hired me to write a (now slightly dated) paper on S+S, I learned that this isn't accurate. As part of that project, I talked with lots of people in Redmond who were working in this area. Like Phil, I began with the assumption that S+S meant using both together, something that's not all that common today (although it certainly happens, as with iTunes). The truth is that Microsoft really means something broader than this.
S+S is in fact a label for the world we live in today, where individuals and businesses use both on-premises software and cloud services. Sometimes we do use the two together, but more often we use one or the other on its own. Zealots believe that pretty much everything will migrate into the cloud, while Luddites argue that almost nothing will. Neither group is right--the future actually lies somewhere between these two extremes--and so both are important.
So if S+S is actually just a term for today's broad world, why does Microsoft promote this label so strongly? The answer is simple: It plays to the company's strengths. Every vendor wants to shape this discussion (and thus our perceptions) in ways that benefit it. Salesforce.com, for example, uses its No Software slogan to tilt our thinking toward services, while vendors without a strong cloud services focus, such as IBM, continue to emphasize their on-premises offerings.
S+S is an attractive label for Microsoft because they're strong in both areas. With Windows and .NET, they provide one of the dominant on-premises platforms. At the same time, their massive collection of cloud data centers gives them services scale on par with Google, Amazon, and Yahoo.
It's certainly true that Microsoft's revenues are tilted much more toward the on-premises world, and as Phil points out, it's a safe bet that they'll work hard to maintain their position here. As the attempted Yahoo acquisition shows, they're also trying to get bigger on the services front, a business in which they're not even close to dominant.
Still, expect the company to keep promoting its strengths in both areas. As the seismic shift to services continues, every vendor will position itself in the most flattering way it can find. S+S is Microsoft's expression of how it sees itself in a world where both on-premises software and cloud services are important.
0 comments ::
The State of SCA: An Update
#
Friday, May 09, 2008
I moderated a panel on Service Component Architecture (SCA) at JavaOne last week. I was also the moderator for last year’s SCA panel, and several of the same people were on the panel with me this time. While the things we talked about were broadly similar, two things stand out about what's changed in a year.
The first is that SCA is real, or at least part of it is. One of the things the SCA specs define is an XML-based language called the Service Component Definition Language (SCDL). SCDL is meant to provide a vendor-neutral way to describe how components created in various technologies, such as Java, BPEL, and Spring, are configured and wired together to create applications. Vendors were showing SCDL in real products on the JavaOne floor—Oracle had an especially nice demo—and so it's clear that this part of SCA is seeing some success.
Whether SCDL will in fact provide much cross-vendor portability remains to be seen. As usual, this depends on how many proprietary extensions vendors add. Still, a standard language for describing the components and assembly of an application is a useful idea, and the signs so far are promising.
The second thing that stands out after a year is less promising: It’s the confusion around how to write SCA components. Along with SCDL, the SCA specs define how to create components using several different technologies. Yet the various SCA vendors and open source projects can’t agree on which of these to implement. SCA support for Spring components, for example, is hit or miss: some SCA offerings support it, some don’t. BPEL is much the same—Oracle is a big fan, while the open source Fabric3 currently has no BPEL support.
And just as it was a year ago, support for SCA’s new programming model for creating Java components is uneven. As I've written before, I believe that this aspect of the spec is really important--it unifies the diverse approaches of Java EE much as Microsoft's Windows Communication Foundation (WCF) unified the diverse programming models in the original .NET Framework. Yet this part of the SCA standard has always been contentious. At last year's SCA panel, for example, the SAP rep asked the audience who wants to see a new programming model for Java components and (unsurprisingly) got no hands raised. Accordingly, SAP has been a leader in defining an alternative way to create Java SCA components as EJB 3.0 session beans. This alternative is a superset of SCA's original component model, so it's not a wholly new thing. Still, the challenge for developers and decision makers is to choose among these various options, and so creating more of them is problematic.
Some existing SCA offerings, such as Fabric3, implement the original Java programming model for SCA components and apparently have no intention of supporting the EJB-based approach. SAP, by contrast, explicitly told me that they have no plans to support the original Java programming model; they're going with the EJB-based approach. IBM, ever the big tent, is supporting both.
The stated goal of SCA is to provide application portability. Widespread support for SCDL is an essential part of this, but so is agreeing on how to create SCA components. For SCA to really improve portability, the vendors and open source projects that support it need to agree on how their customers should create components. If they don’t, SCA risks becoming yet another standard that doesn’t provide much benefit to the people who use it.
6 comments ::
Understanding Windows CardSpace
#
Tuesday, April 29, 2008
Do you think digital identity is important? If not, I respectfully suggest that you're wrong. Messy, yes, and in some ways hard to understand--it's a broad topic with lots of diverse aspects--but it's unquestionably important.
I believe that one of the most significant events of the last few years in identity is the advent of information card technologies. Spearheaded by Microsoft's Kim Cameron, this idea is embodied most visibly in Windows CardSpace (although there are other important implementations too, such as Higgins). If you're looking for a short introduction to CardSpace, you might read the overview paper I wrote a couple of years ago.
Even better, get a copy of Understanding Windows CardSpace: An Introduction to the Concepts and Challenges of Digital Identities. This terrific book by Vittorio Bertocci, Garrett Serak, and Caleb Baker is far and away the best introduction I've seen to CardSpace and to much of digital identity in general. The book has been out for a few months now, and while it's gotten great reviews, I don't think it's getting the attention it deserves (because nothing about identity gets the attention it deserves).
Full disclosure: The book is part of Addison-Wesley's Independent Technology Guides series, for which I am series editor. This means that I played a small (really small) part in making this book happen. I'm a huge fan of the technology, however, and of this book. You really ought to read it.
0 comments ::
Cloud Platform Services: A Simple Taxonomy
#
Monday, March 31, 2008
If the next great application platform battle is for dominance in the cloud—and it is—it’s worth trying to categorize the services those platforms will provide. We’re all familiar with platforms for on-premises applications, which commonly have three fundamental parts:
- Computing Services, providing a way to run logic. These services might be quite basic, such as those provided directly by an operating system such as Windows or Linux. Computing services can also offer more, such as the higher-level services provided by a Java EE server or the .NET Framework.
- Data Services, allowing applications to store and work with data. Once again, these can be simple, such as an ordinary file system, or more complex, such as the services provided by SQL Server, Oracle, and other relational databases.
- Integration Services, making it easier to connect applications and data. These might include communication services, the ability to run workflows that control the integration, and others. Plenty of on-premises products offer these today, including WebSphere Process Server, BizTalk Server, and many others.
Cloud platforms are beginning to address all three of these areas. Here are some examples in each one:
- Computing Services: The most visible example of raw operating system services today is Amazon’s Elastic Compute Cloud (EC2). By hosting Linux virtual machines, EC2 lets organizations run pretty much any Linux software they’d like in the cloud. For higher-level services, one good example is Saleforce.com’s Force.com. Intended to support a specific kind of business application, Force.com has attracted a significant number of ISVs. Microsoft provides something similar with its CRM Live offering, also targeting a specific kind of business application rather than the more general support offered by the .NET Framework or a Java EE server.
- Data Services: For basic data access, Amazon is once again the most visible: Its Simple Storage Service (S3) works much like a file system in the cloud. Amazon also offers structured data access with SimpleDB, as does Microsoft with its recently announced SQL Server Data Services. It’s worth noting that these two offerings both work with hierarchical rather than relational data, each providing its own (non-SQL) query language.
- Integration Services: Amazon's Simple Queue Service (SQS) provides a simple offering for cloud-based integration. Microsoft takes a somewhat different approach with BizTalk Services, providing connectivity and identity services today with support for cloud-based workflow promised soon.
There are connections between these categories in cloud platforms too, much like the connections in on-premises platforms; Amazon's EC2 relies on S3 for storage, for instance. We're also seeing hints of other kinds of services that a cloud platform will need. BizTalk Services includes an identity service, for example, something that's logically distinct from integration but is nonetheless required to provide cloud-based integration.
It’s early days for cloud platforms, and so nothing out there currently provides anything like the completeness, maturity, or unity of today’s on-premises platforms. All the vendors mentioned above (and others) are racing toward this goal, however, so don’t expect today’s fragmented world to last. Cloud platforms will one day provide the same kind of solid environment for creating hosted applications that on-premises platforms offer today. Anybody who cares about enterprise software should keep a sharp eye on this space.
8 comments ::
Platforms for SaaS Applications: Which Approach Will Win?
#
Tuesday, February 26, 2008
The next great application platform battle is taking shape. As more and more applications are created that provide software as a service (SaaS), it makes sense to provide a common platform on which to build these applications. Just as traditional on-premises applications depend on the platforms provided by Windows, Linux, and other operating systems, developers of hosted SaaS applications should also be able to build on a common foundation.
It's way too early to know who's going to win this battle. Most likely, there will be a handful of dominant SaaS platforms a few years from now, just as there are a handful of dominant operating systems today for building on-premises applications. But it's not too soon to think about what kind of platform is likely to win.
Two approaches to SaaS platforms are appearing. One style, SaaS-only platforms, focuses solely on supporting applications that run in the cloud. The marquee example of this is Salesforce.com's Force.com, which has attracted a significant number of application developers. The second approach aims at providing a common platform for both SaaS applications and on-premises applications. Microsoft has announced plans to do this, and other vendors are also moving in this direction.
Of these two approaches, the second--a common platform for SaaS and on-premises applications--is likely to win. Here's why:
- Extending existing on-premises technologies to a SaaS platform means that developers don't have to learn entirely new skills and new development tools. Instead, there's a ready-made population of people who already know the basics of how to use the SaaS platform. The creator of a SaaS-only platform, by contrast, faces the challenge of teaching developers how to use whatever new tools and technologies it provides. Force.com, for example, has its own programming language, called Apex, that developers need to learn. While Apex isn't especially complicated, using it is certainly more work than writing in languages that developers already know such as Java or C#.
- Using the same basic technologies for both a SaaS platform and an on-premises platform lets ISVs and end users more easily move their applications from one environment to the other. While the two worlds might not be exactly the same, they ought to be similar enough that SaaS applications can be brought in house without too much pain and vice-versa. Providing this flexibility is likely to be attractive to many potential users of a SaaS platform. Contrast that with a SaaS-only platform, which supports solely applications that run in the cloud. If moving an application in-house makes sense for any reason, the only real choice is to rewrite it.
Providing a common platform for SaaS and on-premises applications is harder than creating a purely SaaS platform (or a purely on-premises platform, for that matter). After all, a platform built solely for SaaS applications can focus entirely on the problems those applications face. Targeting both worlds requires addressing the requirements of each while still providing more or less the same programming environment. Still, the advantages of offering a common technology foundation for both platform styles are clear. Five years from now, I'm betting that the dominant SaaS platforms will largely provide the same programming environment as their on-premises cousins.
2 comments ::
Software + Services in the Microsoft World
#
Tuesday, January 22, 2008
Using both on-premises software running inside an organization and services provided by externally hosted software makes a lot of sense. Some things, it seems, need to run on-premises. An awful lot of stuff, though--probably more than you think--can make sense as a hosted service. And a few things work best as a combination of the two.
Microsoft has chosen to refer to this set of ideas as software plus services (S+S). I've written a white paper that gives a broad introduction to the topic. While the paper was sponsored by Microsoft, don't think that it describes the One True Perspective on S+S within Microsoft--I wouldn't make that claim. (In fact, I'm not sure there is one true perspective, as the company seems to use the term in diverse ways.) Instead, the paper's goal is to help people think about this emerging area, organizing the main ideas into a coherent whole.
The paper's subtitle is "A Technology Overview for IT Decision Makers", and the core audience is IT managers. Still, I hope it's useful for anybody who's interested in the area. If that includes you, the paper is available here.
5 comments ::
|
|
|
|
Back
to Top.
