All postings/content on this blog are provided "AS IS" with no warranties, and confer no rights. All entries in this blog are my opinion and don't necessarily reflect the opinion of my employer.
I had the opportunity to participate at this year’s CloudConnect conference, with my session on Building Highly Scalable Applications on Windows Azure, which is mostly an update from my earlier presentations at JavaOne and Cloud Computing Expo. I was pleased to learn that the cloud-optimized design leveraging distributed computing best practices approach, aligned well to similar talks by well-known cloud experts from Amazon, Google, etc. A more detailed discussion on this topic can be found in my earlier post - Designing for Cloud-Optimized Architecture.
One of the major takeaways I had from the conference, was the focus on ‘cloud platforms’ (or platform-as-a-service generally) messaging, further reinforcing the platform view of cloud computing, as opposed to the infrastructure-level perspectives, or mixed views around the popular SaaS, PaaS, and IaaS service delivery models.
It started with Werner Vogels in his keynote presentation. Werner said, “it is all about the cloud ecosystem”, that “everything are cloud services; everything as a cloud service”, and “not constrained by any model”. And “let a thousand platforms bloom”, where “ecosystems grow as big as possible”. This implies that the popular models (e.g., SaaS, PaaS, IaaS) are irrelevant, because everything are simply services that we can consume, and these services can span the entire spectrum of IT capabilities as we know, and potentially more.
It is interesting to see how the platform messaging evolved over the past few years. For instance, Werner Vogels used to refer to Amazon Web Services as “Infrastructure as a Service”. However, I think Werner Vogels has always advocated the platform view, similar to Gartner’s notion of “application infrastructure as a service”, instead of the overused IaaS (infrastructure-as-a-service) service delivery model (as popularized by NIST’s definition of cloud computing). Perhaps, it was also because many people started incorrectly referring to Amazon Web Services as IaaS and not seeing the platform view, that Werner chose to clarify that models are irrelevant and “it is all about the cloud ecosystem”.
I also belong to the camp that advocates the platform view, and the further ecosystem view of cloud computing. The platform and ecosystem views of cloud computing represent a new paradigm, and promote a new way of computing. Though I think the SaaS, PaaS, and IaaS classifications (or service delivery models) still have some uses too. They are particularly relevant when trying to understand the general differences and trade-offs between the service delivery models (as defined by NIST), from a layers and levels of abstractions perspective.
Perhaps, what we shouldn’t do, is to try to fit cloud service providers into these categories/models. As often, a particular service provider may have offerings in multiple models, have offerings that don’t fit well in these models, or it’d be over-simplifying to refer to cloud platforms, like Amazon Web Services, Google App Engine, Windows Azure platform, etc., strictly in this platform-as-a-service definition. These platforms have a lot more to offer than simply a higher-level abstraction compute service.
As Werner Vogels said, “cloud is actually a very large collection of services”, cloud platforms aren’t just a place to deploy and execute workloads. Cloud platforms provide the necessary capabilities, delivered as distinct services, that applications can leverage to accomplish specific tasks.
Amazon Web Services has always been a cloud platform; today it is a collection of services that provide capabilities for compute (EC2, EMR), content delivery (CloudFront), database (SimpleDB, RDS), deployment and management (Elastic Beanstalk, CloudFormation), e-commerce (FWS), messaging (SQS, SNS, SES), monitoring (CloudWatch), networking (VPC, ELB), payments and billing (FPS, DevPay), storage (S3, EBS), support, etc. It is not just a hosting environment for virtual machines (which the popular IaaS model is more aligned with). In fact Amazon Web Services released S3 into production (March 2006) before EC2 (limited public beta in August 2006, removed beta label in October 2008).
Similarly, Microsoft has been using the platform-as-a-service messaging when describing Windows Azure platform, but it is also about the collection of various capabilities (delivered as services). For example, below is a visual representation of the application platform capabilities in Windows Azure platform that I have been using since 2009 (though the list of capabilities grew over that period):
And below shows how those capabilities are delivered as services and organized in Windows Azure platform.
This is important because the platform view is one of the major differentiators of cloud platforms when compared to the more conventional outsourced hosting providers. When building applications using hosting providers (or strictly infrastructure-as-a-service offerings), we have to incur the engineering efforts to design, implement, and maintain our own solutions for storage, data management, security, caching, etc. In cloud platforms such as Amazon Web Services, Google App Engine, and Windows Azure platform, these capabilities are baked into the platform and available as services that are readily accessible. Applications just need to use them, without having to be concerned with any of their underpinnings and operations.
An analogy can be drawn from high-level differences between getting food products from Costco to put together a semi-homemade meal, versus getting raw ingredients from a supermarket and prepare, cook, and finish a fully-homemade meal. :) The semi-homemade model offers higher agility (less time and efforts required to put together a meal and to scale it for bigger parties) and economy of scale in Costco’s case, while the fully-homemade model offers more control.
Another distinction between cloud platforms and typical IaaS offerings, is that cloud platforms are more of a way of computing – a new/different paradigm; whereas IaaS offerings are better aligned towards hosting scenarios. This doesn’t mean that there are no overlaps between the two models, or that one is necessarily better than the other. They are just different models; with some overlaps, but ideally suited for different use cases. For cloud platforms, ideal use cases are aligned to net-new, or greenfield development projects that are cloud-optimized. Again, hosting scenarios also work on cloud platforms, but cloud-optimized applications stand to gain more benefits from cloud platforms.
The cloud ecosystem view takes the cloud platform view one step further, and includes partners and third parties that enable their services to participate in an ecosystem. The collective set of capabilities from multiple organizations and potentially services spanning multiple platforms and cloud environments together form an ecosystem that feeds and builds upon each other (in composite, federated, application models), and generating best practices and reusable processes, communities, etc. This can also be viewed as a natural evolution of platform paradigms, when drawing inference from other models where the iterations typically evolved from technology maturity, critical mass in adoption, and then building ecosystems. The platform with the largest and most diverse ecosystem, gets to ride the paradigm shift and enjoy a dominant position for that particular generation.
The Web platform stack model I discussed back in 2007 is one way of looking at the ecosystem model (apologies for the rich color scheme; I was going through a coloring phase at the time).
In essence, a cloud ecosystem itself will likely have many layers of abstractions as well; one building on top of another. One future trend in cloud computing may very well be the continued climb into higher levels of abstraction, as differences and complexities at one level often represent development opportunities (e.g., for specializations, consolidations/aggregations, derivations, etc.) at a higher level.
Ultimately, cloud platforms enable the dynamic environments that support the construction of ecosystems. This is one aspect inherent in cloud platforms, but not as much for lower-level IaaS environments. And as the ecosystems grow in size and diversity, the network effect (as discussed briefly back in 2008) will contribute to increasingly intelligent and interactive environments, and generate, collectively, tremendous value.
Here's a popular topic. ;) A quick search in the blogsphere finds countless number of posts and comments proclaiming the inevitable (or already happening) decline of Microsoft as we near the age of cloud computing.
A small sampling of some well-known publications finds comparatively less dramatic views, but the theme is quite consistent - cloud computing is heralded as the future, and Google is best positioned to dominate this new era.
While things look quite certain on Google's side in terms of succeeding on the Internet and leading/riding the cloud computing tidal wave, at this point it doesn't seem to be the case for Microsoft.
"The invisible law that makes it impossible for a company in the computer business to enjoy pre-eminence that spans two technological eras"; as described in the NYTimes article, "The Computer Industry Comes With Built-In Term Limits". While I think the article did not articulate the precise reasons why Microsoft won't stay on top through a major paradigm shift (other than focusing on where Google is succeeding and where Microsoft isn't), the question is still valid.
Reason being, cloud computing itself represents a migration from distributed client-server and on-premise software models, to a more centralized model (though logically centralized and physically distributed). Eric Schmidt said, "What [cloud computing] has come to mean now is a synonym for the return of the mainframe... and the mainframe is a set of computers... They're in a cloud somewhere." And this everything-as-a-service (in the cloud) model directly conflicts with what people most commonly identify Microsoft with - software for people to use (and most visibly Windows and Office - client O/S and desktop software).
More specifically, various trends in the past 10+ years have also influenced this paradigm shift. Just to list the obvious ones:
Effectively, the shift towards browsers as the primary channel of access for consumers and deployment target for organizations, has reduced the need to use locally installed software. And this directly impacts Windows and Office, plus server software traditionally acquired and installed on-premise; perceivably the entire Microsoft product portfolio.
Plus arguably, Microsoft's investments in online services so far have not won leadership positions and profitability. Recent deliverables such as Windows Live have made significant progress, especially Live Search where the technology has closed some gaps with Google, but still trails behind in terms of adoption. And the gap seems to be widening still.
So it seems the "Single-Era Conjecture" must be true, and that Microsoft is walking towards its impending downfall? That would certainly be the case if Microsoft completely ignores the market and not see the need to change, or is incapable of change.
However, Microsoft does see the need, and has been working on many significant changes to shift towards the cloud.
But, then, why does it seem so difficult for Microsoft to make any significant progress in this area? A couple of thoughts:
What About the Other Guys?
So much attention has been focused on the perceived "war" between Microsoft and Google. But what about the rest of the IT industry? This shift towards cloud computing also in many ways presents challenges to their existing businesses. I'll bet many organizations are also thinking that they missed the opportunity to land grab some market share in online search.
But from a corporate strategy perspective, the seemingly different approaches are very remarkable. Microsoft is pursuing the path of organically build towards the cloud. Oracle is starting to build data centers, but seems to in general prefer acquiring its way into the cloud once the market begins to mature; as they have done with the major acquisitions in the past decade. IBM is also building data centers, but seems to leverage and build upon pure cloud players such as their partnership with Google; as they have done with open source software. Similarly, Intel, HP, and Yahoo have teamed up to build towards the cloud as well. Very distinct strategies, but do seem to be the sensible approaches for each organization.
However, not everyone will be able to afford building massive data centers and establishing clouds. Yahoo Research Chief Prabhakar Raghavan said, "In a sense, there are only five computers (clouds) on earth." He listed Google, Yahoo, Microsoft, IBM, and Amazon. Well, may be not exactly, but that view of the world is also not entirely implausible, and imagine the kinds of changes everyone will undergo in order to achieve that state.
That view also underscores a complete commoditization of the entire IT industry. While unfathomable by today's standards, it is conceivable that a paradigm shift such as cloud computing could exact such sweeping changes from us. Reason being, cloud-based services have the benefit of the economies of scale, which allows the services to be provisioned at a lower cost. Existing IT shops, which increasingly face the need to reduce maintenance costs and deliver innovation, may very well favor switching over to cloud-based utility-like services; often compromising quality for lower cost.
Nicholas Carr said in his book, The Big Switch - "In the long run, the IT department is unlikely to survive, at least in its familiar form. It will have little left to do once the bulk of business computing shifts out of private data centers and into the cloud." Plus a very contrarian and sensational blog post "Your new IT budget: $10".
Which means, IT shops will increasingly need fewer investments on in-house technology and resources to support operations. And that also translates to needing fewer in-house technical specialists. As demand for technology and technical skills decreases, so does their value, which marks the trend of complete commoditization. Scary thought no?
Of course Nick Carr's view has generated a lot of controversy, as well as an ample amount of vehement disagreement. But in that light, doesn't Microsoft's scramble towards the cloud seem reasonable, and whoever is not doing so may need to be a bit concerned?
In a nutshell, Microsoft does see the importance of cloud computing, and is actively building towards the cloud. But Microsoft's approach to shift towards the cloud, is based on a considerably pragmatic perspective that the world will not completely move into the cloud. We think that on-premise and local/client software still has value in the future, but the cloud will undoubtedly be a major component as well.
The moniker that best describes Microsoft's approach is "Software Plus Services".
Basically, we expect that the world will remain in a hybrid state, where commonly used services (like today's outsourcing of payroll services to ADP) may move into the cloud, but many differentiating capabilities will continue to be implemented and delivered towards the edge. Some potential factors:
So what is Microsoft doing to shift towards cloud computing? To list some interesting points:
Thus Microsoft definitely aspires to become a major player in the cloud. What remains to be seen is just how well Microsoft executes towards the cloud.
Interesting times ahead. One thing is certain - more changes to come, and we can expect Microsoft to ramp up activities in this area very aggressively the next few years. Don't count Microsoft out, just yet. :)
This post is part of a series of articles on cloud computing and related concepts.
Microsoft’s AppFabric, part of a set of ”application infrastructure” (or middleware) technologies, is (IMO) one of the most interesting areas on the Microsoft platform today, and where a lot of innovations are occurring. There are a few technologies that don’t really have equivalents elsewhere, at the moment, such as the Windows Azure AppFabric Service Bus. However, its uniqueness is also often a source of confusion for people to understand what it is and how it can be used.
Internet Service Bus
Oh no, yet another jargon in computing! And just what do we mean by “Internet Service Bus” (ISB)? Is it hosted Enterprise Service Bus (ESB) in the cloud, B2B SaaS, or Integration-as-a-Service? And haven’t we seen aspects of this before in the forms of integration service providers, EDI value-added networks (VANs), and even electronic bulletin board systems (BBS’s)?
For example, it is easy to think that integrating systems and services on the Internet is a simple matter of applying service-oriented design principles and connecting Web services consumers and providers. While that may be the case for most publicly accessible services, things get complicated very quickly once we start layering on different network topologies (such as through firewalls, NAT, DHCP and so on), security and access control (such as across separate identity domains), and service messaging and interaction patterns (such as multi-cast, peer-to-peer, RPC, tunneling). These are issues that are much more apparent on the Internet than within enterprise and internal SOA environments.
On the other hand, enterprise and internal SOA environments don’t need to be as concerned with these issues because they can benefit from a more tightly controlled and managed infrastructure environment. Plus integration in the enterprise and internal SOA environments tend to be at a higher-level, and deal more with semantics, contexts, and logical representation of information and services, etc., organized around business entities and processes. This doesn’t mean that these higher-level issues don’t exist on the Internet; they’re just comparatively more “vertical” in nature.
In addition, there’s the factor of scale, in terms of the increasing adoption of service compositions that cross on-premise and public cloud boundaries (such as when participating in a cloud ecosystem). Indeed, today we can already facilitate external communication to/from our enterprise and internal SOA environments, but to do so requires configuring static openings on external firewalls, deploying applications and data appropriate for the perimeter, applying proper change management processes, delegate to middleware solutions such as B2B gateways, etc. As we move towards a more inter-connected model when extending an internal SOA beyond enterprise boundaries, these changes will become progressively more difficult to manage collectively.
An analogy can be drawn from our mobile phones using cellular networks, and how its proliferation changed the way we communicate with each other today. Most of us take for granted that a myriad of complex technologies (e.g., cell sites, switches, networks, radio frequencies and channels, movement and handover, etc.) is used to facilitate our voice conversations, SMS, MMS, and packet-switching to Internet, etc. We can effortlessly connect to any person, regardless of that person’s location, type of phone, cellular service and network, etc. The problem domain and considerations and solution approaches for cellular services, are very different from even the current unified communications solutions for enterprises. The point is, as we move forward with cloud computing, organizations will inevitably need to integrate assets and services deployed in multiple locations (on-premises, multiple public clouds, hybrid clouds, etc.). To do so, it will be much more effective to leverage SOA techniques at a higher-level and building on a seamless communication/connectivity “fabric”, than the current class of transport (HTTPS) or network-based (VPN) integration solutions.
Thus, the problem domain for Internet Service Bus is more “horizontal” in nature, as the need is vastly broader in scope than current enterprise architecture solution approaches. And from this perspective Internet Service Bus fundamentally represents a cloud fabric that facilitates communication between software components using the Internet, and provides an abstraction from complexities in networking, platform, implementation, and security.
Opportunistic and Systematic Development
It is also worthwhile to discuss opportunistic and systematic development (as examined in The Internet Service Bus by Don Ferguson, Dennis Pilarinos, and John Shewchuk in the October 2007 edition of The Architecture Journal), and how they influence technology directions and Internet Service Bus.
Systematic development, in a nutshell, is the world we work in as professional developers and architects. The focus and efforts are centered on structured and methodical development processes, to build requirements-driven, well-designed, and high-quality systems. Opportunistic development, on the other hand, represents casual or ad-hoc projects, and end-user programming, etc.
This is interesting because the majority of development efforts in our work environments, such as in enterprises and internal SOA environments, are aligned towards systematic development. But the Internet advocates both systematic and opportunistic developments, and increasingly more so as influenced by Web 2.0 trends. Like “The Internet Service Bus” article suggests, today a lot of what we do manually across multiple sites and services, can be considered a form of opportunistic application; if we were to implement it into a workflow or cloud-based service.
And that is the basis for service compositions. But to enable that type of opportunistic services composition (which can eventually be compositing layers of compositions), technologies and tools have to be evolved into a considerably simpler and abstracted form such as model-driven programming. But most importantly, composite application development should not have to deal with complexities in connectivity and security.
And thus this is one of the reasons why Internet Service Bus is targeted at a more horizontal, and infrastructure-level set of concerns. It is a necessary step in building towards a true service-oriented environment, and cultivating an ecosystem of composite services and applications that can simplify opportunistic development efforts.
ESB and ISB
So far we discussed the fundamental difference between Internet Service Bus (ISB) and current enterprise integration technologies. But perhaps it’s worthwhile to discuss in more detail, how exactly it is different from Enterprise Service Bus (ESB). Typically, an ESB should provide these functions (core plus extended/supplemental):
In other words, an ESB helps with bridging differences in syntactic and contextual semantics, technical implementations and platforms, and providing many centralized management capabilities for enterprise SOA environments. However, as we mentioned earlier, an ISB targets concerns at a lower, communications infrastructure level. Consequently, it should provide a different set of capabilities:
A figure of an Internet Service Bus architecture is shown below.
And this is not just simply a subset of ESB capabilities; ISB has a couple of fundamental differences:
So what about some of the missing capabilities that are a part of ESB, such as transformation, message validation, protocol mediation, complex orchestration, and rules engine, etc.? For ISB, these capabilities should not be built into the ISB itself. Rather, leverage the seamless connectivity fabric to add your own implementation, or use one that is already published (can either be cloud-based services deployed in Windows Azure platform, or on-premises from your own internal SOA environment). The point is, in the ISB’s services federation model, application-level capabilities can simply be additional services projected/published onto the ISB, then leveraged via service-oriented compositions. Thus ISB just provides the infrastructure layer; the application-level capabilities are part of the services ecosystem driven by the collective community.
On the other hand, for true ESB-level capabilities, ESB SaaS or Integration-as-a-Service providers may be more viable options, while ISB may still be used for the underlying connectivity layer for seamless communication over the Internet. Thus ISB and ESB are actually pretty complementary technologies. ISB provides the seamless Internet-scoped communication foundation that supports cross-organizational and federated cloud (private, public, community, federated ESB, etc.) models, while ESB solutions in various forms provide the higher-level information and process management capabilities.
Windows Azure AppFabric Service Bus
The Service Bus provides secure messaging and connectivity capabilities that enable building distributed and disconnected applications in the cloud, as well hybrid application across both on-premise and the cloud. It enables using various communication and messaging protocols and patterns, and saves the need for the developer to worry about delivery assurance, reliable messaging and scale.
In a nutshell, the Windows Azure AppFabric Service Bus is intended as an Internet Service Bus (ISB) solution, while BizTalk continues to serve as the ESB solution, though the cloud-based version of BizTalk may be implemented in a different form. And Windows Azure AppFabric Service Bus will play an important role in enabling application-level (as opposed to network-level) integration scenarios, to support building hybrid cloud implementations and federated applications participating in a cloud ecosystem.
Multi-Enterprise Business Applications (MEBA) are a new class of applications that can be used to support business processes that span enterprise and organizational boundaries. MEBAs leverage best practices and patterns from service-oriented architecture (SOA) techniques and technologies, and specifically cloud-based platforms, to facilitate the next-generation B2B (or multi-enterprise) collaboration.
This is a project I had the privilege to participate in for the past few months, along with my esteemed colleague, Wade Wegner, and under Jack Greenfield's leadership, as part of Microsoft's Platform Architecture Team. This project was just highlighted at Microsoft’s Professional Developers Conference (PDC2008) in Los Angeles a few weeks ago, as the RedPrairie keynote demos that showcased Microsoft’s cloud computing platform, and discussed in more depth in one of its breakout sessions (see Wade's blog for more info).
And more recently, we took a more architectural look at MEBA's at Microsoft's Strategic Architect Forum 2008 (SAF08).
So what do we mean by “multi-enterprise business applications”? They are a new class of applications, different from the traditional data-driven applications that focus on managing data and resources and providing access to end users. They are more focused on implementing business processes that span enterprises, such as traditional B2B integration and collaboration scenarios. They leverage and build upon message-based integration and use well-defined protocols and roles, such as fundamental approaches and technologies used in enterprise service-oriented architecture initiatives. Actually, in a way, they represent an approach of extending enterprise SOA beyond the four walls of each enterprise, to integrate and work more seamlessly with other enterprises.
At the same time, multi-enterprise business applications also have some differentiating requirements. Scenarios may include participants distributed throughout different parts of the world. And since they are intended to support mission-critical business activities, we need to have a very robust architecture that can ensure high availability, high reliability, a high-level of security; plus the need to have auditing, reporting, regulatory compliance, and so on; not significantly different from our enterprise IT architecture concerns from that perspective.
And unlike traditional SOA applications that are more focused on functional capabilities within one enterprise, MEBAs extend the SOA concepts and technologies to business processes that span multiple enterprises. In addition, because MEBAs operate between organizations, their primary concerns are also different – community management, identity management, process execution management, multi-enterprise governance, etc.
Moreover, unlike incumbents in the B2B software and service providers spaces where implementations today consist mostly of customizing proprietary products and services; MEBA defines an architecture in which foundational, common services should be implemented, and how they can composited into applications that define business processes. The evolution and maturity model of MEBAs are also more dependent on the community, than any one vendor maintaining a solution. MEBAs are a new class of applications; not a new class of products or solutions.
Thus MEBA’s can be used across many different industries, especially ones that, from a traditional B2B perspective, tend to have a lot of cross-organizational collaboration needs. During this phase of the MEBA project, we attempted to take a more detailed look at the supply chain industry. And a more detailed view found many capabilities, within the supply chain industry, that today leverage various forms of technologies and implementation approaches to facilitate communication and integration across multiple partners on supply chain networks, or in a way, multiple enterprises. And for our project, we chose just one specific area, supply chain orchestration, to investigate further to evaluate how MEBA’s can be used to meet its specific requirements. So at the next lower level of detail, we have identified a set of common scenarios in supply chain orchestration. And then we chose just a few to prototype out, such as search for capacity, product recall, etc.; by building with Microsoft's Azure Services Platform.
So now taking a few steps back up. Let’s talk about how some of these scenarios and capabilities are implemented today across the various industries. First of all we have multiple protocols that are intended to standardize the interaction models and data being exchanged. Some are more industry specific, such as RosettaNet, HL7 for healthcare, and FIX for financial services. While some are designed to be more general purpose, such as ebXML, WS-BPEL or BPEL4WS, and many others such as WS-Choreography, Java Business Integration (JBI), etc.
But this at the same time also hints at some challenges we have today, as in a way, there are just too many standards. And many organizations are in the process of developing more standards to define how multi-enterprise collaboration should be facilitated in their industries. For example, automotive, auto parts distribution, etc.; just to name a few.
And the observation today, is that, B2B, or integration or collaboration between multiple enterprises, or inter-enterprise SOA, is still relatively complex and difficult to implement and manage.
For example, we have a very diverse set of technologies, collected from the past 25 years or so in various attempts at optimizing or streamlining communications between multiple organizations. Everything from EDI, FTP, on-premises software, integration service providers, B2B gateways, to the current class of SOA solutions that can be extended to support B2B scenarios.
And not just the underlying technologies used, enterprises have very sophisticated needs and concerns in many areas, such as security, data ownership, management, and governance, etc. What’s more here, is that these needs and concerns are in a way, amplified or more complex when we look at them from a cross-organizational perspective.
So integration and enabling business processes across organizational boundaries, have been complex and difficult to accomplish, for many years. Why do we think now we may have a better chance at simplifying and streamlining efforts in this area, and moreover, why do we think MEBA’s, as a new class of applications may have a better chance at doing so?
Traditional B2B or multi-enterprise communication and collaboration were complex to implement and often unreliable and error-prone. Organizations had to deal with a multitude of technologies, standards, and additional sets of technologies and implementations with each partner organization on a one-to-one basis. MEBAs aim to streamline and simplify these inherent complexities, by providing an architecture that builds on existing technologies and abstracts infrastructural concerns.
From a timing perspective, the growing inter-dependence and always-connected environment for businesses, and availability of key new technologies (Web services, SOA, cloud computing, etc.), are showing signs that the time is right to take a new approach at multi-enterprise (or B2B) interactions. MEBAs build on the best practices and proven technology models of today, and offer the potential to greatly streamline and simplify efforts of implementing business processes that span multiple enterprises.
And in general, by leveraging many of the best practices and building on many of the latest trends, such as the concept of an “Internet Service Bus” (ISB) providing an architecture and platform, upon which multi-enterprise business applications can be constructed, that simplify and streamline many aspects of B2B integration today, while meeting the needs of the organizations and participants involved. We think, this concept of the ISB, will significantly transform the architecture, and how we design and implement approaches to facilitate multi-enterprise business applications.
And of course, this doesn’t mean we intend to replace the work organizations have already done with protocols and standards (such as RosettaNet, ebXML, HL7, FIX, etc.). In fact we think we can leverage those work, and use MEBA’s to provide implementations of these protocols, as well as an environment / platform to facilitate their orchestration and management.
Thus MEBAs provide the potential of these high-level benefits:
Business benefits – improve business agility, bottom-line revenue (reduced errors and cost, and faster response), and top-line revenue (higher automation, improved relationships with partners and customers)
Technical benefits – simplify and streamline connectivity, improve visibility and governance, higher quality of service, focus on delivering business processes instead of infrastructure, leverage standards-based technologies, bridge multiple and disparate identity systems, etc.
Now let us show you what a reference architecture for multi-enterprise business applications may look like. Just as you would expect, there are many layers of capabilities from this perspective. Basically, these applications will need to have a foundational services layer, which provides some core infrastructure capabilities such as compute or runtime environment, identity management system, workflow execution and management, robust messaging infrastructure, data management solution, and operational management services. On top of that, we can then build a layer of higher-level services, which are considered more functional, and provides capabilities such as community management (extending from trading party management in a traditional B2B perspective), services orchestration, business process management, party management, and so on. Then finally, we can build various types of communities, or partner networks, that define working relationships between multiple organizations. For example, each organization can belong to multiple communities, or as administrators to a particular community, can invite and add new partners, and so on. We would also like to use model-driven techniques to define business processes, and to be able to provision one or more instances of a given business process, each supporting a specific community of trading partners.
When we saw the plans for the Azure Services Platform, we studied them to understand the kinds of applications it would support. Our conclusion was that it will spawn a second generation of B2B applications. We then coined the name MEBA to describe this new class of applications. Our focus here is to talk about MEBAs and how they can leverage this Azure Services Platform. So we will not get into the details of the Azure Services Platform, but we do want to articulate specifically how some of its components help support the MEBA concept.
Windows Azure – the cloud compute platform, provides the underlying runtime environment for the foundational services and MEBA implementation. It offers high scalability and reliability, and global reach to partners across the world
.NET Services – with its Service Bus, Access Control Services, and Workflow Services, provides the fundamental “Internet Service Bus” that can effectively address common concerns around identity and security, connectivity, and service orchestrations between multiple organizations
SQL Services – provides the scalable and reliable cloud-based database solution, which helps to establish databases in the cloud to manage the data that is shared across the multiple organizations, and especially data that support the communities and their interactions
Live Services – provides capabilities to connect to end users and support many aspects of human interaction needs
MEBAs have the potential of completely changing the way enterprises interact with each other. If we further extend the MEBA vision and how it continues to simplify and streamline infrastructure concerns in facilitating business processes across organizations, we may see a world where business networks can be quickly and dynamically constructed to deliver business capabilities, simply by being able to connect the dots (or building with blocks). Business results delivered by the collective resources and capabilities from a network of multiple enterprises will become true differentiating factors, and more significant than any one enterprise can deliver alone. New business models may also emerge, as increasingly enterprises can participate in the larger scheme of things, and sometimes be a part of the process that span industries. The control of processes may begin to shift away from being enterprise-centric, to community-centric. Ultimately, enterprises can create new, more diverse, and more differentiating business offerings by being able to leverage the community of partners.
A couple of announcements at the Microsoft Worldwide Partner Conference (WPC09) have been making a lot of noise today. One is the unveiling of the much anticipated Office Web Applications, part of the overall Office 2010 announcements – that Office 2010, SharePoint Server 2010, Visio 2010 and Project 2010 have reached the technical preview engineering milestone.
Unlike the previous online Office service offerings, such as Office Online, Office Live and Office Live Small Business; Office Web Applications are indeed browser-based Office clients. Specifically, Excel, OneNote, PowerPoint, and Word; in addition to Outlook which had the Web Access version for a number of years already.
And as part of Office 2010, Office Web Applications will be available to nearly half a billion customers at launch:
A few screenshots below. As you can see, one of the major common themes is that all of the Web Application clients will use the Office Fluent ribbon menu system as well.
Excel Web Application
And in FireFox:
OneNote Web Application
PowerPoint Web Application
Word Web Application
The Office Web Applications can be accessed by simply opening the documents as listed on a web page. Even though not just any web page, but can be document folder pages that are hosted in Office Live Workspaces, Windows Live Skydrive, SharePoint Online, on-premise SharePoint Server 2010 instances, etc. Just opening the document (for editing) will open the Office Web Applications in the same browser.
These browser-based clients are considered “basic” cousins to the full desktop client versions. But as you can see, the level of fidelity and richness in the Office Web Applications are actually much better than “basic”. In fact, the included features are quite effective at editing documents from any browser.
Plus some new features in Office Mobile 2010:
This means that, users will have access to, and can use Microsoft Office to edit/modify Office documents anywhere. From the most basic experience, but highest mobility on mobile devices, to most common/streamlined experience on any computer with an Internet connection, and to the richest/professional desktop experience installed locally on your own computer.
Some people may criticize Microsoft for not innovating and still holding on to the desktop dinosaur, but we think a not one-size-fits-all approach, and offering the spectrum of options to use, is actually better for the customer. Someone has used an analogy – trying to fit everything into the browser, and ask all users to use that one model, is like asking everyone to ride mopeds.
In addition to the ability to save/store documents and access/edit them anywhere (cloud, server, desktop, device, etc.), users will also be able to share and collaboratively edit the same document over the network. And this will work access the desktop and browser-based clients. With “fast dynamic sync”, changes from multiple simultaneous users can be synchronized across the group almost instantaneously.
Other new collaboration features include:
Things sure are looking quite interesting with the Office 2010 release.
For more information: