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

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

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

Sub-divisions:

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

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

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

Townhouses/condominiums:

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

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

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

Hotel — true multi-tenant:

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

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

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

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

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

Thought leaders from across GXS bring you what we have seen in the industry during 2007 and what we can expect to see in 2008 based on the research, news, trends, industry discussions and our observations. Here is a list of our top predictions for B2B e-commerce in 2008…  

B2B Strategies  

1)     SaaS Platforms will ignite Global Innovation  

Prediction by GXS’s Chief Technology Strategist, John Radko  

The barriers to entry for providing services to a global audience are on the verge of collapsing completely from an infrastructure perspective. As the costs of infrastructure software has fallen due to both economies of scale and open-source initiatives, the last barrier has always been the cost of setting up and operating an infrastructure to handle the computing, networks and storage—and now that infrastructure will be available in a service format. Not only are several very innovative infrastructure services now available, but a fiercely competitive market appears to be forming, centered around Amazon (S3, SQS, EC2), Microsoft (Live Services) and Google.  

But even beyond base capabilities like storage, platforms offered as services are sprouting up in many additional places like SalesForce.com, Facebook, GXS Trading Grid^®, etc. The next generation of business software and services will be building on these platforms, which will enable them to offer new products faster and at much greater scale. Small companies will be distributed through these channels in much the same way that musicians and performers are channeled through music companies. Beyond just infrastructure, platform companies will provide provisioning, billing, authorization, etc. The best platform companies are already offering the ability for partners that build on them to integrate not only with infrastructure services but also other services built on the same platform—the natural evolution of the current mash up craze, but taken beyond the web.  

The freedom to build services on pre-existing infrastructures offered as a service and priced as utilities will dramatically lower the barriers to entry for innovators, and that will unleash the next wave of innovation.  

2)     BPO for B2B Goes Mainstream  

Prediction by GXS Industry and Product Marketing Manager, Ryan Kraudel  

The past two decades have seen a fundamental shift in business models driven by the modularization of the functions of a company and emphasizing focus on the core business functions and differentiators that create value for customers. This has lead to an explosion in outsourcing of business functions that are critical to the business operations, but do not differentiate the business from its competitors. This includes functions such as manufacturing, HR/payroll, logistics and some IT functions. The primary drivers of these outsourcing arrangements have historically been focused on cost-takeout and eliminating depreciating assets. However, we are now seeing new areas of outsourcing driving key top-line revenue and business efficiencies that are shifting the outsourcing focus from cost-elimination to business benefit.  

One example of this is B2B outsourcing, the outsourcing of the people, processes and technologies required to operate and maintain a global B2B e-commerce program. A recent study by the Stanford Global Supply Chain Management Forum has identified key business value from B2B outsourcing that led to an average of 245 percent ROI for B2B outsourcing. These include benefits such as automating more trading partners faster and more effectively with global B2B capabilities and supporting a broad range of B2B technologies, which has a direct impact on customer satisfaction. In fact, the Stanford study showed companies using B2B outsourcing showed an average of 62 percent improvement in customer satisfaction, which directly contributes to top-line benefits such as revenue generation, customer loyalty and customer longevity. These are just a few of the results and benefits that demonstrate why the rapid growth in B2B outsourcing around the world is expected to continue through the foreseeable future.  

3)     File Sizes to Multiply in B2B     

Prediction by GXS Vice President of Industry Marketing, Steve Keifer  

There is an increasing trend in B2B towards business partners sharing higher volumes of data packaged into much larger files. Historically, the typical B2B transaction exchanged between companies was on the order of kilobytes. The most commonly exchanged transactions are invoices and purchase orders which are only a few kilobytes in size. However, over the past 24 months, there has been a substantial increase in the exchange of larger files—megabytes and gigabytes in size. The phenomenon is occurring in nearly every industry sector. Examples include product images in retail, check image files in banking, call detail records in telecommunications, satellite images in logistics and CAD diagrams in manufacturing.  

The trend towards larger file transmission really should not be very surprising given the growth in file sizes that we have seen in the consumer segment. For over five years now consumers have been downloading and sharing large audio and video files for home entertainment. With the dramatic decreases in the cost of storage and networking, it is only logical that this trend would extend to business communications as well. In fact, demand for large file transfer in the workplace has increased steadily in recent years. Do you give a second thought to sending a 5MB email attachment to a colleague at one of your business partners?  

Unfortunately, all of the popular IP standards used for B2B lack the features such as compression or checkpoint/restart necessary to support high volumes of large file transfer. As a result, many companies are forced to license expensive, proprietary “managed file transfer” software to support their needs. It is too early to predict what will occur in 2008. But one thing is for sure, with customer demand rising quickly, large file transfer is becoming a mainstream B2B function need rather than a niche technology.  

Supply Chain Strategies  

4)    Global Trade, Local Trade-offs  

Prediction by GXS Director of Product Management, Pradheep Sampath  

In recent years, supply chains have been constructed and modified to become nimble, agile, demand-driven and of course global in response to the proliferation of global trade. Global trade will become so mainstream that consumers and organizations will no longer subject themselves to local supply chain trade-offs just because products happen to be sourced a dozen time zones away. Retailers who historically have carried separate sets of inventory to fulfill demand from brick-and-mortar, web and catalog channels will drive to further optimize and unify stock. Manufacturers who have traditionally shipped ocean containers or multi-case lots to automated distribution centers will pledge to streamline their direct-to-consumer shipment of “eaches” to suburbia.  

Manufacturers and retailers alike have for some time evaluated B2B integration platforms that help obliterate the divide between transactions and trade. In 2008, these platforms will no longer be perceived as bleeding edge, but as mandatory tools that oil the global trade engine. Speaking of oil–$100+ a barrel will mandate levels of supply chain efficiency that even academicians have only evangelized behind closed doors. Consolidators, contract manufacturers, customs brokers and suppliers will all strive to exchange logistics transactions that are accurate and actionable. Simple on-demand applications will serve as “windows into global trade” and will enjoy mass adoption, shielding both multi-national corporations as well as four-person factories from complexities of the transactions that define trade.  

5)    Physical and Financial Supply Chain Convergence Will Show Early Wins Among Early Adopters  

Prediction by GXS SVP Marketing and CMO, Bobby Patrick  

Leading supply chains will seek opportunities to inject working capital into their supply chains and optimize business performance for themselves and their trading partners. The convergence of the information flows in the physical and financials supply chains will enable financial institutions and logistics providers with new ammunition to benefit their customers and solve real business problems, such as dramatically increasing days payable outstanding (DPOs) for buyers and reducing days sales outstanding (DSOs) for suppliers.  

6)    It’s Time. The Greening of B2B  

Prediction by GXS Industry Marketing Director, Bryan Larkin  

In 2008, companies will look at B2B as a way to address their corporate responsibility with respect to green initiatives. Corporate Social Responsibility (CSR) and Environmental Health and Safety initiatives have started to include B2B in their scope, but in 2008 this will become a significant issue for companies. Companies that have not fully automated their supply chain will see that doing so will not only make their business more effective, it will also play a significant part in meeting their Corporate Social Responsibility initiatives.  

Best Practices for Success  

7)     Supply Chain Intelligence Is the Next BI  

Prediction by GXS Vice President of Product Management, Andrea Brody  

The demand to make sense out of the B2B transactions that move across the Internet and VPNs will increase 20 percent year over year. Since the movement of supply chain data via EDI and other formats has become mainstream, corporations now want to obtain valuable information from that data by correlating and providing business rules in order to effectively manage their supply chain to improve financial performance and exceed customer expectations. In today’s world of globalization, outsourcing and vertical disintegration, over 80 percent of the events that matter to a business will come from outside of the business. Investments in business intelligence and business activity monitoring software will require operational signals that transcend geographies, integrate widely diverse technology and break the barriers of standards and languages.  

8)    B2B Master Data Management: It’s the Data Stupid.  

Prediction by GXS Senior Global Product Manager, Melanie Ligons  

2008 will be the year when companies finally understand that the real challenge holding them back in the automated supply chain is lack of data quality. Information integrity issues associated with products and transactions reduce the ability of an organization to make appropriate short and long term decisions. Corporations have been hording data for years while analysts and consultants told them to do something with it. Now that business intelligence solutions are taking a primary place in the spotlight, companies are realizing that the data they’ve been hording is flawed—and so is the data they are using to run their business on a day to day basis.  

For years the retail and CPG space have struggled with new ways to share product data, only to be dismayed by the exorbitant costs and miniscule returns. High-tech manufacturers scoff at the idea of trying to adopt the Global Data Synchronization Network because they see it for what it is: just another way, using another technology, to share data. Sharing data isn’t the issue. Making sure companies have complete and accurate data, and then keeping it that way, is the real challenge.  

Leading companies will step up to the plate in 2008 and address the data quality issues by taking the first steps towards implementing solid B2B Data Management programs. They will follow in the steps of a few groundbreakers that have already paved the way. These data governance initiatives will need to address cultural, process and technical roadblocks that keep companies from successful supply chain execution. Most important will be changing the cultural aspect, as data accuracy will need to become part of the fabric of the business. The processes can be defined and supported by technology, but adherence and commitment will be the key to eliminating data quality problems.  

While numerous tools have been introduced to address information management over the past several years, the focus of the tools themselves, those selling the tools and the analysts covering them have been primarily on utilizing the tools to provide workflow for managing the flow of a subset of data within an enterprise (think Product Information Management in the B2B Data Management space). Now we are starting to see (Gartner 30 November 2007 - Methodologies: Blueprints for Success With Data Quality Improvement) the focus of analysts shift to actually addressing data quality. Smart executives will listen because this is something they can get their hands around. If the decisions they are making are based on flawed data, if the financial statements they are signing are based on inaccurate numbers, if the deals they are agreeing too might not be what they think they are, then they and their companies are in trouble.  

9)    e-Invoicing Adoption Continues to Skyrocket  

Prediction by GXS Senior Marketing Manager, Rochelle Cohen  

2008 will see a veritable explosion in the adoption of e-invoicing to help businesses automate their accounting processes. Businesses are increasingly applying technology to automate their procure-to-pay process and gain the dramatic business benefits that have been documented in numerous case studies and benchmarks. When e-invoicing is integrated with automated workflow and e-payments—which over 90 percent of large enterprises are doing or planning to implement—it enables companies to not only reap significant hard dollar cost savings from reduced operational costs associated with handling paper, but also to take advantage of discounts that can add millions of dollars to the company’s bottom line. Furthermore, more companies are taking advantage of the opportunity brought about by this “perfect storm” of automation to gain even greater savings by leveraging prorated discount structures or discounts negotiated once invoices are ready to be paid.  

Further fueling the adoption of e-invoicing are electronic invoicing legislation, such as the EU Council Directive 2001/115/EC which allows the electronic invoice to serve as the legal invoice in the European Union, and the availability of third party service providers that now offer a broad range of translation, protocol mediation and regulatory compliance services. These services enable companies to overcome the barriers that have prevented 100 percent trading partner participation in the past. For example, now even small trading partners can participate in e-invoicing programs without changing their current processes. And, suppliers are beginning to welcome the opportunity because they recognize the benefits they too will receive; this is particularly true when buyers promise faster payments in return for electronic invoicing. Furthermore, buyers who do business with international suppliers can rely on the third party service provider to ensure that varying local government regulations are satisfied. 2008 will be a breakthrough year for e-invoicing. The business case is clear, technology options providing seamless integration with in-house are readily available and the e-invoicing adoption rate has been growing steeply and steadily.  

Marketing  

10)   B2B Service Provider Blogs Become More Common and More Personal  

Prediction by GXS Global Product Manager, Justin Duewel-Zahniser  

Dialog with customers through blogs will increase, whereas using blogs as a medium for company promotional content will decline. Companies are increasing the use of blogs as an avenue for communicating with customers and the market, as evidenced by new supply chain vendor blogs started in 2007. Companies traditionally begin blogging externally in the Marketing organization since the focus there is naturally on external communication. In 2008, customers will continue to engage blogs as an avenue for dialog with their service providers and the value of provider blogs will become more evident in organizations outside of Marketing. Additionally, blogger voices from the user community will begin to increase and take on more authority in the space, consistent with what has been happening in politics, fashion and media.  

A very interesting post on “Paying for SOA” by Nick Malik over at Microsoft (he is in the Enterprise Architecture group).  He applies a taxonomy based on tax policy — which is surprisingly apt (or at least I felt so after reading his post…)

For me, the core challenge is that two truths are in conflict:

1. Centrally providing services at scale is usually more efficient
2. Small, independent teams will outperform large dependent teams (I wish I could phrase this better)

Did I say these are in conflict?  I made a mistake, a mistake many people make, because I equated efficiency, productivity, and speed.

In the traditional IT world, I would propose these definitions:

• efficiency:  total cost of ownership to the entire organization, which may mean “sub-optimizing” a given team
• productivity:  the efficiency of a person or team on a given project, but not necessarily the whole organization
• speed:  time to benefit for a given solution

“Big SOA” can be considered to be good for efficiency.  In this world you build things only once, reuse like crazy, and standardize as much as possible.  The theory is that you will get some speed benefits, later…   The problem here is that we turn the world inside out, and make the engine room the entire purpose, rather than just a big infrastructure to move the cruise ship from island to island.  Big-time architecture programs often disappoint because they get so enmeshed in infrastructure that they forget why they were started (to make it easier to do things).  I believe some large outsourcing arrangements (where entire IT groups are consumed by mammoth firms) succumb to this as well, though not all.

Total independence, on the other hand, makes no sense either.  If every team is using a completely different philosophy and technology stack, you never get any scale and spend lots of time integrating stuff.  This is almost never a conscious decision, and is mostly observed in acquisitions (hey, nobody told the IT groups that would be one big happy family one day) — but on a smaller scale it is not uncommon to see different teams “agree to disagree” on key points like middleware.  Independence and free choice will initially drive productivity, but as systems need to be linked, you pay it back with interest.

So what is the answer?  I think it is somewhere in-between.  Our own GXS Trading Grid applications are a mixture of mandated shared services (like identity, translation, messaging), and independent application functionality.  The balance is difficult to achieve, but Nick Malik’s piece is some nice thinking on at least one model of achieving it….

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

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

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

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

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

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

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

In the time since SOA has become an “IT” technology (or pattern, if you prefer, since SOA is not so much a technology as a design pattern…), there have been some surprisingly vigorous debates about whether SOA implies ESB, is complementary to ESB, or is anathema to ESB.  I claim no objectivity here, as the GXS Trading Grid has been designed with a particular point of view on this topic, but first lets get our definitions clear…

SOA = Service Oriented Architecture.  Good luck getting agreement on a definition here, but I would say that is a method of architecting applications and systems using loosely coupled services working together to accomplish a purpose.  The trick is to do this in such a way that the services involved can be reusable, so that all of the inherent efficiencies of code reuse are realized.

ESB = Enterprise Service Bus.  Another one that is difficult to define, but at a minimum a standard asynchronous message bus that all or most of an Enterprise’s applications utilize to communicate.  The “ESB” was popularized by Sonic Software (a division of Progress Software), with their phenomenal product SonicESB (not many pieces of software can define a new category) — but now most EAI/middleware vendors (think webMethods, TIBCO, etc) have competitive offerings.

So is the relationship between SOA and ESB just some esoteric technology discussion?  No.

The root of the argument is that an ESB becomes a “backbone” through which all communications flow, and thereby tightly couples services via that backbone.  It may seem a small matter, but the “loose coupling” concept is key to SOA.  But, at least with the GXS Trading Grid, there is a “third way”, which borrows from both points of view.

GXS Trading Grid is GXS’s service infrastructure for providing B2B services to our customers and their trading partners (base level messaging to full-blown process collaboration, and everything in between) — but for my purposes here, it is a service oriented architecture.  Services are able to invoke one another in realtime to do “work” (this is referred to as synchronous, because the two services are working together at the same time, or in synchrony), which is typical for “immediate” processing like authenticating a user or checking the status of something.  This is implemented in the traditional model with independent services “talking” to one another directly (the agreed method of “talking” is the interface, or contract).

This is a really easy model to work with, but very challenging to scale, and scalability is our number one priority.  The reason this is challenging is that you have to have enough capacity to respond immediately (within microseconds anyway) on every service!  This is hard to do across the board.

To put it another way, it is reasonable to expect that a grocery store will have a can of chicken soup for every customer that wants one, but not that there will always be available checkouts — no matter how crowded the store gets!

The checkouts (and the deli counter, and the pharmacy) are asynchronous services, and they can scale very effectively (a store can open more checkouts, or increase staff at the deli).  However, there must be an infrastructure (the rows of cash registers, the deli counter), and that is the Enterprise Service Bus.

Because of its ability to handle load without loss (work queues up), and its dynamic scalability (a good architecture lets you add capacity on the fly), we build as much as we can in the ESB model (this is how we have implemented all of our on network translation capabilities, for instance).

By implementing a Service Oriented Architecture on top of an Enterprise Service Bus, you can have the virtues of SOA, with room to grow.

Read the rest of this entry »

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What we came up with was not surprising:

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

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

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

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

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

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

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

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

A really good, and brief, argument for why Services and Components are really different, from Radovan Janecek’s Weblog .

It is not too difficult to argue with it, but it has the merit of being “observable”. His core argument is that components are stitched together through code — either at compile or runtime, while services are accessed dynamically over a network. Interesting basis, and much easier to apply than many based solely on granularity.

This is a good article from a few months back by Dave Chapelle (who authored O’Reilly’s JMS and ESB books). I met Dave during some work we were doing with Sonic Software — and he is a true visionary.

ESB Myth Busters: 10 Enterprise Service Bus Myths Debunked @ SOA WEB SERVICES JOURNAL

ESB stands for Enterprise Service Bus. Sonic (and Dave) practically invented the ESB category, although they have strong competition from other innovators (like Cape Clear, and — of course — open source). The emphasis is on a lightweight container model that can be effectively managed from the ESB infrastructure.

In practice, this proves challenging with legacy applications, often requiring extensive administrative integration to facilitate the management of the “service” from the ESB. As a for instance, most people know GXS for its VAN (value added network). In order to implement our Trading Grid vision, we had to create an interface to manage VAN mailboxes (create, list, extract, etc). This required constructing an API, and then wrapping it as a service that could be invoked from outside.

Piece of cake, right? Well, not exactly… GXS is fortunate to have a contemporary, open-systems based EDI service, so at least we don’t have to automate CICS transactions to add a mailbox, but it is not so contemporary that we have a friendly XML web services interface either. In order to provide that to our partners, we had to wrap a stream protocol (like ftp, but the commands are different) into an API, and then put a services interface on it.

Couldn’t we just “auto-magically” expose the API as a set of services? Sure — but it would not be a great idea, because of that evil word granularity. API work is a lot like wiring or plumbing a house, not so easy to alter later, so you want to handle every possible case you can think of, and offer a fine degree of control to the future user of the API. The service interface is more like the electrical outlets and switches. API’s that are too “coarse” mean you often have to rip open the wall, services that are too fine-grained “electrocute”. The core problem is that an API is supposed to be powerful, while a service interface should be highly usable.

So what does that have to do with ESB? Well, the emphasis on lightweight infrastructure often means you don’t have the toolset you need to integrate. As a result, I think more highly of using technologies with a strong EAI capability (like webMethods) as an ESB than Dave does (though it worries me, because he is smarter than I am….)