Confusing Nouns and Verbs: A Common Pitfall in SOA and Integration Initiatives
SOA projects can go drastically off course when they get tangled up in inter-system dependencies and new capabilities in myriad legacy systems. This can be the death knell of a service-oriented architecture initiative, as it falls behind schedule and runs over budget.
CIO — 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.
