Confusing Nouns and Verbs: A Common Pitfall in SOA and Integration Initiatives

With every client I serve, I see a few common trends that can cause distraction. The greatest of these is database (or system) bias. Developers, architects and business representatives begin to see functionality framed in terms of the database (or system) from which that aspect of data originates, rather than as a service in the enterprise. This is a grammatical issue, in service oriented architecture (SOA) terms, like confusing nouns and verbs.

System bias is the point in an integration or SOA initiative when multiple systems need their data updated to reflect an upstream (external) change. In particular, it is the moment when people representing each system claim they need to build a capability into their existing systems to receive these update notifications. This is far too early in the conversation to discuss which systems should be doing what, but more importantly there probably shouldn’t be multiple systems doing anything. That is point-to-point development, not SOA.

For example, imagine a line-of-business application that generates orders and functions as an Accounts Receivable (AR) system, exporting data to a financial application using an “order extract.” As use cases are discussed, the end user might point out that invalid payments (rejected checks) need to be propagated back to the AR system, adding a fee to reflect the charge. The human conversation may then drift onto the specifics of the Order update and the creation of the Fee, resulting in the services to update Order Status and create Fees. This may be the right way to go, conversationally. But in technical terms, the discussion should focus on the business service being provided (the verbs Create and Update), not the business data being operated on (the nouns Order and Fee). The level of granularity here is critically important, and it’s unique to each organization and SOA initiative.

The functionality may be better provided by a single service, Reverse Payment, which more closely represents the business needs. This may seem trivial and is certainly subtle, but if you don’t have to allow updates to Orders or creation of Fees from other systems such services shouldn’t be created at all and are really unnecessary overhead. Fixation on the nouns, the data in this case, distracted the team from the often more appropriate focus on the verb, the business capability. This type of confusion represents a data bias.

This problem is more pronounced when the customer comes from a mainframe background. I have never worked much on mainframe systems myself, but I surmise that the mindset may be due to how such development was done and its technology and methodology constraints. Confusing or failing to distinguish between Verb and Noun violates many principles in an integration or SOA strategy.

Successful SOA does not come about by adding functionality to all the existing systems (nouns) in the enterprise. It comes about by adding services (verbs) which may or may not be part of those existing systems. Existing systems may be nothing more than a data store or one step in a multistage service (a service composition). That is, new services may be built upon existing systems, but not necessarily into existing systems. This type of confusion represents a system bias.

For a successful integration initiative (which people are starting to call a SOA initiative), you need to decouple the systems from direct point-to-point interface-specific implementations. An important SOA concept is that your software offers services that manage the details internally and that it exposes only a contract representing the service being offered, not just the data operated on by that service. When system representatives start talking about where the data resides and how it needs to be updated by their systems in response to SOA events, they’re already wandering astray.

It’s the last part—how the data should be updated by each of their systems—that gets people off the track. Yes, it’s important to discuss what data needs to be updated in which systems, including the rules governing how and when. However, these end systems should not concern themselves too much with this updating. At the most, they need only expose an interface from which the SOA can perform these updates. Usually it makes sense to forego creating such an interface in the legacy system and use the middleware or integration platform to do so.

It is at the moment of this confusion—the departure into focusing on the nouns within the context of system bias—where SOA projects can go drastically off course. That’s where they get lost in a tangled web of inter-system dependencies and in the new capabilities being stapled onto myriad legacy systems. Often this is the death knell of the initiative as it falls behind schedule and runs over budget.

It is easy to confuse the concept of service (verb) with the data a service operates on (noun), but it is a dangerous mistake to do so. That leads down a path to point-to-point integrations that are difficult to manage and costly to maintain.

In my experience, this mindset is more a culture issue than anything else. However, I believe changing this culture is vital to the success of any SOA initiative. The bias may be deeply ingrained and take time to change, but eventually the “Aha!” moments begin to occur and slowly there is a meeting of the minds. Unlike most of the difficulty with SOA, which is really concerned with adapting IT to the business, this system bias mindset is often ingrained within IT departments themselves and thus can be addressed more easily.

Dan Rosanova (dan.rosanova@novaenterprisesystems.com) is principal consultant at Nova Enterprise Systems (http://www.novaenterprisesystems.com), a consultancy that specializes in Enterprise Applications and Microsoft BizTalk Server solutions. He has ten years experience delivering enterprise solutions in financial, insurance, telecommunications, and medical industries on Windows, Solaris and Linux platforms.