Integrated Infrastructure Blog

Provisioning Dimensions for the Cloud

At ast Saturday's class for my Middleware Internals at IIIT-Hyderabad, I was introducing cloud computing and provisioning. Some basic questions came up - even computer science students from a Top-10 institution in the country have questions like "Isn't SaaS Cloud". What many miss is that Cloud Computing is more about virtualization-over-the-web and the enabling of mechanics such as integration and provisioning.

To this end (virtualization-over-the-web), Software-as-a-Service (SaaS) provides the end users [i.e. the enterprise] value based views of a 'virtualized' application wherein all the operational and infrastructural aspects are managed by the service provider. Likewise PaaS provides the virtualized view of an application platform on which the end user can build a solution. Or with IaaS, where just the infrastructure/OS is virtualized over the web on which any solution can be installed and configured. The definition of cloud also varies based who you ask. Platform-as-a-Service (PaaS) providers will tell you that cloud is when you build applications on their platform. IaaS providers will tell you that if you use their infrastructure, then that is cloud. But I feel the real cloud is what the end enterprises see--a virtualized over-the-web application landscape in a combination of IaaS, PaaS & SaaS. It's a very heterogeneous environment that enables the IT solutions for the various business needs that the enterprise may have. This integrated infrastructure gets the best of breed with no constraints on technologies, platforms, payment models, and even physical location, while still enabling some common binding elements such as Web 2.0 enabled user interface, common administration approach, common integration approach and even provisioning capabilities across the various platforms in the cloud. 

Provisioning is also emerging as an important common aspect of cloud computing. It has emerged from something intrinsic to specific platforms such as Amazon EC2, and now to a more generic expectation across all cloud services.Though the dimensions and approaches to its realization may be different in different providers, a few key dimensions are hardware resources, application platforms or cross cutting dimensions like user provisioning or business service provisioning. Examples include specific resources like hardware (say 2 CPUs), OS (linux ver x.y), app platform (tomcat servlet engine), or an instance of a specific application. And more importantly non physical resources like provisioning a user (for example: enabling access to multiple systems/apps for a new employee).

Through 2010 I think we should be seeing more enabling abstractions, models and utilities for provisioning in the heterogeneous cloud computing environments.

Now That's a Real Forklift Upgrade

I have to admit... I don’t really know how our customers use OpenEdge. I do know there are a ton of customers - over 65,000. And, if that weren’t enough, there are over 1,500 partners too. What's more, many of them are in-production with SaaS offerings.

Damn, that’s a lot.

(If any analysts are reading... just think about the opportunity of selling Actional into that installed base even if we never got another “new logo” sale.)

This week’s press release follows on from several months of a beta period where about 20 or 30 OpenEdge customers tested the newly released Actional integration.

As TVH Forklift Parts realized, knowing what’s happening in their integrated infrastructure, and being able to assure a consistent level of service has tremendous value to a distributed and shared infrastructure.

Why is this important?

It’s about the business context. Without that context, solutions are just technology (we have good technology too… but that’s not enough).

That’s the difference between assurance and management. Assurance implies business-technology coordination to achieve a business result. Management implies your technical components are up and running. Big whoop. Just today I spent 2 hours on the phone with T-Mobile. All the technical components were up, but it still wasn’t working. I know you can relate.

Colleen points out that our partners are being viewed more and more as business partners, not just technology providers. Simply put, our partners need technology to understand the business impact of “events” within their infrastructure.

Understanding the business impact means that we (technology infrastructure providers) need to provide an awareness of the business context when problems occur. The only way to do that is to track business context all the time.

I’ve heard a few times recently of prospects who have a “competitive” solution in place to track business assurance… but when I probe, it seems they don’t run it all the time because (pick one):

1. It impacts performance of my applications. (it doesn’t scale)
2. It collects too much information. (it doesn’t scale)
3. It requires too much CPU on my app servers. (it doesn’t scale)

I don’t understand how people think a solution that doesn’t run all the time can do the job.

Let me rephrase.

If it’s not running all the time and collecting context of your business, how are you using the context of the business to make better run-time decisions?

Simply put, you’re not.

I’m glad to welcome TVH Forklift Parts to the Actional family. And, if you’re reading, thanks for sharing your story.

Holy Cloud! Thousands of Customers & Hundreds of Partners

At parties, I do everything I can to avoid talking about work. But, when forced, people eventually ask where I work. When I tell them Progress Software, it's usually followed by "No, we're actually a big public company that does more than databases."

I bet you didn't know we had thousands of SaaS customers in production using our products... Well we do!

And, by the way, it makes a great opportunity for each of those to use Actional for both cloud governance and inter-mediation for customer-specific policy and really flexible standards-based application layer security. If we never sold a new logo, we could still grow like weeds. Our tiny competitors are struggling to survive the recession after raising tons of money their investors will never see again, and we're in a position to thrive by delighting our existing customer base. Awesome.

And not only do we have thousands of customers, we have hundreds of partners adding vertical value to our software solutions.

That partner thing. It's big here.

Why does it work so well for us? Well, that's a huge thanks to the culture of collaboration here at Progress. Actually, it's more than that. It's like an open source attitude towards collaboration (even when we're creating commercial products). We listen, we adapt, and we learn.

We're a day away from the end of our fiscal year, and things are really crazy as you'd expect as we close our year end business. This has been a real transitional year for Progress and another successful year for Actional:

1. We've absorbed IONA and Mindreef, and rolled out new products around integrating those technologies with Actional.
2. We've received top recognition from Gartner and Forrester analysts, and Forrester even delivered a few use cases demonstrating hard ROI numbers around Actional deployments at our production customers in finance and telco.
3. We've delivered another major release update, demonstrating Actional's capabilities well beyond traditional web-services based SOA by integrating Progress OpenEdge, SAP ABAP, IONA Orbix IIOP, Spring, and Microsoft BizTalk orchestration support.
4. We've weathered a very bad economy, and we're quite well positioned for a very strong 2010 with our top-selling Business Transaction Assurance offering.

Why on-premise SOA cannot offer cloud pricing

David Linthicum suggests that SOA infrastructure vendors must switch to a cloud pricing model and get paid only on delivering value, further taunting the vendors to put their money behind their products. Interesting proposition... But I don't believe it will work. And the comparison to cloud or SaaS may not even be valid. For SaaS, its easy to identify the value delivered - as that of a business solution being made available as a service. For cloud, the SLAs are at the platform level and can only ensure availability - they cannot ensure business value. On-premise SOA is even worse because the operating platform is not even in the SOA vendors control, so guaranteeing even the availability at the same level as cloud is not even possible. At best the vendor can assure that the SOA platform will not fail, but they definitely cannot guarantee against failure from the hardware, OS or other layers in the solution stack that reside with or on the on-premise SOA.

The business value that David refers to is way beyond just platform availability, and that surely cannot be assured by any single component in the overall solution stack - unlike in the SaaS model where the SaaS provider controls the complete solution stack and can provide the guarantees.

NYC Cloud Computing Expo Preparation Almost Done

Well, we're just a few days away and preparation is winding down. We've got an article written and ready to go, and I've got my presentation mostly complete and just need to work on layout, notes and review. Sounds like I'm almost done... just hope I don't get sidetracked by some fire drill.

The media alert went out today and it got me thinking that it might be interesting to share the creative process.

Personally, I don't get nervous with public speaking. It doesn't mean I always do well, its just that I quite enjoy the opportunity to get in front of a crowd of strangers full of adoration for the gems spewing from my mouth. In fact, I tend to not "rehearse" for presentations as much as "immerse" myself in the content and visualize how it will go, the thoughts I'd have, the questions that might come up, and feed that back into the presentation in a way that makes it more robust.

This presentation started with work on a white paper I began working on about two months ago. It was a bit of a free form set of ideas I have about cloud computing. I had only the guideline of my submission - The Impact of Cloud Computing on Enterprise Architecture - and I ended up with content in four areas:

1. The difficulties of enterprise integration
2. The corporate challenges of enterprise software
3. A definition of cloud computing
4. Some best practices

The level that I speak at is relatively high, and I worry that it's not enough detail for people. I guess we'll see on Monday.

It took me a week of writing, with some interruptions I'm sure, to get down about 3,000 words on paper. That's about 3 1/12 pages of writing, and it was handed over the PR team for editing.

It may be totally behind the scenes but the people that have edited my stuff in the past, this time included, do wonderful work. It's always important to double check the content and the meaning, and to make sure that the important points stayed, but they really tighten it up and focus it down.

They turned my 3,000 words into 1,120. The final piece has just 20 additional words, though I had to do about a day of editing to bring some of the meaning back, and highlight some points that were lost originally. It'll be posted on Monday so keep an eye out for it. As always, let me know what you think.

I had been thinking about this cloud stuff for some time, and tweeting ideas to see how people would respond. I've also been vigorously reading the tweets and blogs of others to get a sense for where the conversation is. Hopefully, my presentation on Monday adds something to the conversation, in a way that constructively builds on what others are saying.

The difficulty with creating the presentation, of course, is that I didn't just want to put the paper in presentation form.

That would be boring. (Boring is bad.)

I came across a presentation titled "Charts are Cheap" by Major Dan Ward (who unfortunately, didn't include a link to his blog in his presentation, so I can't link you to him!). The idea was 1/2 - 1 idea per slide/chart. Simplify and people will understand more.

So, I'm trying something new with my presentation. It's really lightweight and a lot of what I'll say is not written on the slides. It is, mostly, written in the paper. And, what's not, would be great to discuss online after the event.

Part of the reason to do something different is my "middle of the night" speaking slot. And, I believe I'm also last for the day, so anyone that does come, and stays awake, has me between them and the bar. Not an enviable position.

Though, if they need a drink after my presentation, I believe Mike is organizing a Tweetup at ESPN Zone in Times Square after. Hope to see you there.

This Should Make It Obvious to Anyone

Looking at things from the perspective of how software is evaluated and brought into the enterprise, it's no wonder cloud computing is dramatically changing the landscape. Combine that with the trend of software vendors looking to compliance to shore up revenues, and customers pushing back to reduce their software maintenance costs, and I think we're in for some interesting changes in selling software over the next couple of years*.

In any case, I thought it would be interesting to put together a quick list of how software is piloted in a "traditional" purchase cycle, and how it might be piloted if "purchased" from a cloud.

So, assume a thorough selection process has been completed on a product and its alternatives (I don't think we do that well today either... I think it's too feature-focused and we're not nearly evaluating the "right" things), and we're talking about getting the first small set of people up and running on the selected solution.

Traditional Software Purchase

1. Software is purchased.
2. Hardware is purchased.
3. Space is found in data centers for the production kit.
4. A plan is created for moving into production, often a lengthy process inserted around specific rules/restrictions for changing production systems.
5. Development and test environments are setup.
6. Computer room space is found for the permanent location of the development and test kit.
7. Any databases required to support the application are purchased and configured, including hardware if necessary.
8. Administrative and security staff support is required to configure all this new equipment to company standards, backup procedures, and security policies.

Cloudly Purchased Software

1. Get a login.

Even people who don't know anything about software should be able to figure out which is easier. And, while I shouldn't need to ask, but, how much longer do you think the first process takes than the second from the time a decision is made?

If you want to follow the doings of a new startup taking advantage of just this difference, follow Mike on Twitter. He's starting a new company and taking full advantage of open source and clouds to have some incredible infrastructure and development cost metrics - actually showing through his own experience what can be achieved.

Want to hear more? Remember, I'm speaking at the NY Cloud Computing Expo later this month.

* "Ray" Wang has been tweeting and blogging about this topic quite a bit. I find it very interesting to follow.

Cloud Computing... It Depends on Who You Ask

What exactly is cloud computing? Lately, this is one of the most often repeated question in any discussion about the Cloud. And the answer depends on who you ask! (Personally, I think that if there are not at least three different popular definitions of a new technology, then the technology is not in its "hype" phase of the hype cycle :-) ).

Cloud is often confused to be just one of:

• Utility Computing - The on-demand resources with dynamic provision offered by virtualization platforms such as VMware, EC2 etc.
• Grid computing - Loosely coupled discreet computing nodes, that come together to form a larger computing-grid.
• SaaS - Just the notion of a software abstracted on the web is cloud to some.
• PaaS - To some, cloud is if one were to "build" the solution and then deploy it on a virtualized platform on the web.
• User centric cloud - RIA desktops that provide seamless and integrated access to information and services on the web, while still retaining a "sane" visual front to the user.
• Even Wikipedia defines it as: The majority of cloud computing infrastructure as of 2009 consists of reliable services delivered through data centers and built on servers with different levels of virtualizationtechnologies. The services are accessible anywhere in the world, with The Cloud appearing as a single point of access for all the computing needs of consumers.
• And, I am sure there are more!

Syscon attempted to reconcile the definitions by getting no less than twenty one (!!) industry experts to define cloud. Their definitions had wide ranging defining attributes: elastic, virtualized, services over the web, multi-tenanted, pay-as-you-use, massively scalable technology enabled services, SaaS is the consumer-face of cloud computing, distributed utility grid (wow!), on-demand resources with APIs, and more!

What I see missing though is the end enterprise view. It is this view that brings all of the above (and more) together. As I see it, this is "cloud computing". A fairly abstract IT enterprise landscape. Where the biz requirement is real—with its solution made available over the web, with simple web based user access, with guaranteed SLAs on service availability and performance, with seamless integration to other information sources/services over the landscape. The exact location, platform, configuration, size and such are all abstracted from the enterprise by the solution provider. Further, the solution provider also takes care of maintaining the application (enhancements/bug fixes), managing the production environment, and managing any backend integration requirements that the client-enterprise may have - offering a complete "managed service". The enterprise needs to focus just on the biz at hand, and in defining the IT solution that is needed. The solution-service providers takes care of the rest. All of them coming together to form the enterprise "cloud" - accessed over the web, managed over the web and probably even orchestrated over the web.

The enterprise Cloud will also evolve over time. When there is just one ISV making a solution available in the above managed model, that is SaaS. If the same ISV also "builds" it on the web before making it available on the web, then that is PaaS. If the ISV just uses storage on the web, then that is cloud storage. If the same solution is deployed within the enterprise network on a virtualized platform such as VMware, then that is virtualization. If the solution is distributed across discreet computing "nodes" on the web, then that will be the computing grids. Now fast-forward a few years... If the IT landscape in an enterprise architecture is a combination of all of the above types of solution environments, then there is an opportunity for a loose "biz grid" that can bring all of these together, which in many ways is already prevalent today - the SOA infrastructure! SOA is all about discreet services that are location agnostic, with standards based description and easy access. Today's SOA environments are very very vendor dependent (that is assuming the emphasis is on the reliability and performance). Soon we may see this a reality. A vendor neutral SOA environment that will bring together all the disparate IT solutions in the enterprise, both within and on the cloud. Likewise, Web 2.0 will define the user experience that brings all of the same solutions in a seamless integrated and very-functional UI.

Below is a visual of what I'm thinking... use Comments to let me know what you think.

Convergence of SaaS, Cloud and SOA - Use Case

Was at the HeadStart (innovation showcase) and Compute (ACM Bangalore chapter) co-event this weekend at Bangalore. Was chairing the panel discussion on "Delivering SaaS from the Clouds". The panel included the Founder/CEO of Computational research Labs (part of TATA goup), Head of Cisco/Webex in India (they have a large dev center and equally large India sales ops), Lead Architect at Honeywell, and the Head of the RIA tools development at Adobe. There were an interesting mix of perspectives ranging from the glue and access paradigms from the fringes of the cloud (as in the RIA & webex rich desktops), to hard core grid paradigms and application/service abstractions on the cloud (bright by CRL), to cloud backends (CRL and Webex) and the usage perspective brought on by Honeywell exploring cloud for many of its field initiatives. We also had great discussions ranging from the market opportunities that each one sees to their take on the solution architectures and to the cloud trends that we can expect in 2009.

In particular, I found two aspects very interesting:

1. Build-on-desktop or Build-on-cloud? Unlike the more popular expectations of using the cloud to "host" applications that are built on desktops and 'uploaded' to the clouds to be accessed from browsers, there are also models (in industrial automation) where the application is built on the cloud and 'downloaded' to the devices. Essentially, they are engineered on cloud and downloaded to the devices in the enterprise - examples include energy audits and automation optimizations.
2. The serious production use cases are still elusive. Most people dabbling in cloud are still experimenting and playing around with it. Serious use models are yet to evolve. I believe that this is probably a manifestation of the hype curve. Hopefully the dust will settle down and serious usage emerges in 2009.

Talking about use cases, I came across another interesting use case in the same week. This is in the Governance risk and Compliance (GRC) space. Here the value proposition seen from the cloud is unique—beyond just SaaS. In terms of the agility and the arms-length distance:

The GRC space is extremely regulation driven. And is bound to change often. Today the model for implementing GRC is to "build it in" the existing operational solutions, which we all know is cumbersome and extremely difficult to manage changes. Given this, the proposition from this  company was unique. This company that specializes in governance and consults in best practices, has evolved a "canned" GRC model, and is offering the same as SaaS on the cloud. The compelling case to the clients is that this implicitly allows an arms-length distance between operational systems, easy verifiability of the GRC rules in effect, and is also able to easily modify the GRC rules as they evolve and change. The nature of this scenario is implicitly that of convergence. The value prop is SaaS - the runtime is the cloud and the solution involves extensive access to data and services in the enterprise which is best done using an SOA infrastructure.

Come to think of it, cloud in the enterprise will be deeply entwined with SOA. We are not talking about simple utilities like rate calculators or converters. If serious enterprise solutions are made available on the cloud by 3rd parties, these will always involve access to other enterprise information and services running either in the Intranet or possibly elsewhere in the web-cloud as well. So far, any SaaS solution provides for custom APIs to enable this integration. As the more generic cloud platform evolves, it becomes a question of time and the standards and generic approaches to integrate the enterprise into the cloud will emerge.

This will be yet another space to watch in 2009, even as we already are tracking aspects such as cloud performance, and the cloud monitoring and management (an extension of the SOA Management problem that Progress Software already solves very well with Actional).

Do we really need this complexity?

My first post on the Progress SOA Blog! This gives me jitters... All the writing till now was somehow different. There was a carefree attitude to that writing. When I wrote my book (nearly 40% of the book on SOA approach to Integration), or when I write my personal blog posts, I never had to worry about the impact. Now as informal as this may be, at the end of the day it does have a non-personal tone. Even so, I am excited about this. :-)

My views essentially are reflections on the software services and SI ecosystem and what/how they use technologies in the integration solutions space. Lately, I have been also quite caught by the SaaS/PaaS promise in the SOA context - even if I am quite skeptical about the hyped up value.

Recently, I was speaking on this topic at the IndicThreads conference on Java at Pune. I included a slide on the complexity of SOA. While in my flow I was using it to talk about some of the SOA enablers in our SOA portfolio in simplifying this complexity, the presentation and some following questions triggered a thought... How much of this does the industry actually need? Aren’t these more of a fringe scenario that needs all of this? Isn’t the REST vs. SOAP argument a good case in point? 80+% of the world needs only basic remote service mechanism. While REST more than suffices here, this basic need from the world is but just a small part of SOAP! So, who needs the rest?

The simplicity of REST is stark - at least when compared to the extremely unwieldy SOAP and its numerous accompanying specifications. And it is further compounded by all the WS* standards. Making things worse are frameworks for frameworks such as WS-Policy. WS-policy is a framework that layers on SOAP. And there are other standards that use WS-Policy as the basis for definition. In effect, we have XML over HTTP, on which is defined the SOAP standard, on SOA is the WS-Policy. And on WS-Policy are standards such as WS-S & WS-T. Phew!

Now compare this with REST - that actually has no other specification other than HTTP itself! Granted, this seriously limits what we can do with REST. But lets accept it - the world needs mostly ONLY the likes of just REST and only a very small fraction needs the multiple layers of specifications such as SOAP! Even in the SOAP land this is very well captured in how AXIS evolved - trying to keep pace with the rather haphazard offshoots of SOAP. And now there is CXF whose basic premise is to simplify SOAP and Web Services. From the word go, it has embraced the simplicity and is also trying to be more about services and less about SOAP. In the spirit of the latter, CXF also supports REST right off the bat.

I see 2009 as year where this simplicity is bound to get consolidated. The more simpler and easier the SOA framework becomes, the more it will get accepted. FUSE open sources SOA framework will be one very serious contender in this space. Functionally as complete as any other SOA solution, yet lean and mean with a good set of tools. Watch out for more in the months to come.

All Hail the SaaS Revolution!

Been thinking a lot about Software-as-a-Service (or SaaS) this week, and as it turns out, so have a few others!

Dave Linthicum posted recently that for the "last year we've been in a silent revolution around the use of APIs/services," while Mel Greer (Lockheed Martin's Chief SOA Architect) says the SaaS model is still an "impending challenge." Past or present aside...

Mel outlines the challenges companies will face by "as a service models" and includes:

• the need for SLA's,
• real time monitoring,
• end-to-end testing,
• new pricing models, and
• a rethink on "service usability."

Mel, if you're reading, when do we not have these problems?!

Though the word is way overused, Mel is really suggesting that we'll need a way to govern the "as-a-service" business model. In fact, it's a popular topic this week. A blogger over at Patni had a long post with a gem in the middle... a governance outline (that I don't fully agree with) for SaaS. I presume this governance model would need a way to measure and police the following five elements of the SaaS scenario:

1. Strategic Alignment
2. Risk Management
3. Performance Management
4. Resource Management
5. Value Delivery

SOA What? Let's think together for a second. Dave's right. There're are a ton of services out there. The Amazon web services are really cool, and people are being really creative with solutions being brought to market around them. Mel's right too. SaaS models are in their infancy, and if they're to really grow and achieve their potential, there are a lot of challenges ahead of us. Why not think about a SaaS governance model that could be used to make SaaS deployment more successful?

Does SaaS impart any requirements that differ from other "services" models? How would you approach figuring out your requirements and evaluating solutions that depend upon SaaS offerings? Do you think that SaaS adds a separate flavor to governance, or is it just same-old with how you operate your services and work with your providers today?

I believe SaaS does add separate requirements. Though, I'd look at the SaaS space from two different perspectives; that of the SaaS provider, and that of the SaaS consumer.

Providers have the following concerns:

• Security: Consumers will have security requirements, but providers will have the more complicated requirement of meeting the security demands particular to each customer, without code changes each time.
• Knowledge: Providers need to know what's happening when a customer calls with a problem so that they can be specific and inspire confidence. Without specifics, vendors are just perceived as finger-pointing even when they're right! (This is one of my favorite customers stories to talk about.)
• Use the SLA as a competitive differentiator: If providers can accommodate their customers' business model better than a competitor, and can accommodate change/expanding models, they'll be a step ahead of the game.

Consumers have similar, but different requirements beyond the obvious:

• SLA's that matter; Availability, for example, is important. Uptime, not really. SLA's should be based upon metrics that matter (and are measurable!).
• Agility, (it's why they're using SaaS); As new features are deployed, it's important for SaaS consumers to be able to on-ramp their applications easily/quickly to take advantage of new features. Conversely, consumers need to be protected from change forced upon them by their service providers.
• Low switching costs; Should a consumer need to change vendors it shouldn't break everything. At the same time, this feature can actually be extended to transparently combining SaaS vendors in the infrastructure so that applications don't know/care which provider is used, and decisions can be made that best serve the business, not the developer.

I'm curious to know what you all think about these requirements, and if these are among the things that are top of mind. I'm curious to know what real-world experiences people have with SaaS from a corporate perspective. I'll tell you, mine are limited to salesforce.com, and they're not very good. Rephrase - they're not what I would want were I a CIO delivering solutions to my users.

Here's a quick SaaS factoid: Did you know that Progress Software has 150 SaaS application providers delivering over 500 SaaS based products to the market today?

A Problem Common to SaaS and SOA

I read a blog posting from the other day by a frustrated software as a service (SaaS) vendor venting that:

• They need rapid release cycles... but,
• They can't find all issues in their pre-production environments

For example, the author said "There are multiple points of failure and I can’t seem to think of how we could avoid these types of issues going forward."

Welcome to the world of running a service.  Whether the service is SaaS, a service you provide inside your organization (e.g. a SOA service), or a traditional business service (e.g. like those provided by Reuters, Bloomberg, and Thomson), the issues are the same: You can never anticipate all the ways your consumers will use the services in advance.  This means the risk of consumers experiencing problems is much higher than in other situations.

It also means you can't operate in a "let's get it right, ship it, and go on to the next project" traditional development-shop mentality.  You need to think about solving the problem in a fundamentally different way.

The first step to addressing this problem is being able to insulate consumers from one another (even when they use the same instances of your service).  The most important thing is to ensure that the actions of one consumer can't cause problems for another consumer.  For example, if a consumer goes into an endless loop making requests of your service, you need to ensure this doesn't impact your other consumers (for example, using infrastructure to implement request throttling controls).  Basically you're controlling the ripple effect.

Once you've figured out how to insulate consumers from each other, you can now think about "onboarding" each consumer as a separate project (even though you are in production your consumers aren't).  What assistance do you need to provide to them so they can successfully complete the project of going live with your infrastructure?  If, for example, they use REST or SOAP services you provide, how do you help them to ensure that they are using them correctly and appropriately?

Thirdly (and really this is just an optimization of the past point): How do you empower your consumers to do this for you (so you don't have to do all the work of making them successful).  You'll never be able to fully avoid the responsibility of "owning" consumer satisfaction (and fixing it if it's bad) - but you can put measures in-place so that your consumers can be more successful with less effort.  This can be as simple as providing much better documentation, samples, and tutorials - all the way to providing an interactive environment for the consumer to explore how to best use your service.

Polymorphic SOA

There's lots of industry noise about Service-oriented architecture (SOA) and the expected benefits, but in many cases SOA is an implementation of procedural programming that may be implemented in Object Oriented (OO) technologies such as Java or .NET. That said, I cannot really see anything OO in a basic BPEL or Web Service implementation; have we all forgotten that OO was promising the benefits of reuse, etc., as well? What if we could improve our SOAs by implementing the OO paradigm in them and using techniques such as polymorphism?

What would a polymorphic service be in SOA? And more importantly, what would be the advantages? One of the most common tasks that occurs in any SOA project is the ability to transform data, e.g. convert a document from one format to another, for which many technologies are currently used, such as XSLT and java binding technologies like Castor and XML Beans (to name a few). While each of these technologies provide the ability to transform one document to another, they do not provide the ability to dynamically implement transforms without further hand coding.

Now what is a polymorphic transformation going to actually implement? Well, unlike an object model, I have no base implementation that I can derive from and no guarantee that my transforms are going to execute in a single environment. And what I don't want to do is deploy a specific XSLT wherever a transformation is required because if the format or the data in the input document changes for some unforeseen reason, then the XSLT is essentially invalid. Therefore, the service that I want to deploy will take in any document and transform it into the target type without having to understand how it is implemented, and if for some reason the transformation service cannot convert the inbound target, then an exception is thrown.

Now I am sure that some of you may see this as being a good idea, but what are the benefits of this? If one of the significant costs of a SOA is the time and money of transformation, being able to insert a single polymorphic transformation service in multiple places could severely reduce TCO of any implementation and reduce the number of errors; how many developers do you have working on essentially the same transformation? For a more tangible example, in the world of Software-as-a-Service (SaaS), what if adding a new partner was no harder than ensuring the partner’s request document can be managed by the OO transformation service. Suddenly the ability to get a return on investment on smaller traffic customers who are making money on fractions of a penny per transaction allows a new market to be tapped.

Is this possible today? Absolutely. Products such as DataXtend SI provide this polymorphic transform services, especially when coupled with ESBs that do not have to be strongly typed.

SOA What? Developers can spend more time developing business logic and less time writing complex transformations, which I am sure they like. But also your SOA infrastructure becomes more agile, allowing you to react to customer and market demands. And if your looking into SaaS to provide the ability to make money on smaller customers, imagine the benefits if all the points of mediation were polymorphic?

The Future of Customer Service: "Our systems have failed, how does that make you feel?"

Breaking a bit of tradition… there is a funny story in here but not until after I let you into my head for a second. Now, don’t be scared.

I've recently been doing some research on social computing. I'm not even close to being a "visionary" - that's Dan and Hub's job - so maybe I'm stuck in the myopic world of SOA. But when I hear web services, I think integration/SOA, but as I read more and more, it seems I'm in the minority. Most people hear web services and think Facebook, Twitter and a host of other things that are seemingly more about social computing than web services. Perhaps they are converging? I think I like that idea…

I [personally] care about businesses using technology in a way that takes the 'technology factor' out of it. It enrages me when I ask a question and the answer is phrased in terms of the technology used to solve the problem.

I recently had a rather humorous conversation with Continental -- I encountered a problem related to manipulating a reservation on their website. It was a (polite) 20 minute conversation where I insisted it was a reservation problem while she insisted it was a website problem. Why did it matter? Because she could help me with a reservation problem but not a web problem - even if the reservation was made via the web. I enjoyed the semantic disagreement because I knew that under the covers somewhere there was an IT vocabulary driving the interaction. (Totally aside, in the end, it turned out she could help me... she put me on hold, called the online department, and then came back online and said, "they are aware of the issue, try again in three weeks." Yes, I wish I was kidding.)