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….

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 »

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.

Interesting blurb from SDTimes about a forthcoming study of software projects.  If you’ve been in the industry for any length of time you have probably had the “only 16% of projects succeed” statistic thrown around at seminars, meetings, etc.

 Well, now 35% of projects are succeeding – take that!  Sure, that means that 65% are still being labelled failures, but that is really a glass half-empty way of looking at it.

At the risk of endangering the careers of many software development process improvement gurus, Read the rest of this entry »