Maybe it’s time to go back to basics, advised ZapThink’s David Linthicum during his keynote before the Open Group’s Enterprise Architects Practitioners Conference, being held this week in San Francisco. With undercurrents as to whether threats of an oncoming recession are taking its toll on SOA budgets, or whether there is what Gartner terms a “trough of disillusionment” afflicting SOA adoption, Linthicum stated to a room of enterprise architects that you have to start with an ROI case.
“Most of the people in this room could use a good lesson in that,” he noted.
Of course, given that SOA is an architecture, not a technology or product, the notion that you can attach a quantifiable dollar benefit at first sounds like a bit of an oxymoron.
So how do you do it? Not surprisingly, none of Linthicum’s answers were terribly new or startling as he trotted out familiar benefits of reuse, flexibility, and agility. He acknowledged that selling reuse is a pretty tough one, considering the fact that reuse has been promised ever since the days of CASE or Cobol Copy Books before that. The difference this time is that SOA is not about reusing code, because code is supposed to be abstracted from the service. Nonetheless, Linthicum concedes that’s a tough sell.
But he raised an interesting point on how to quantify ROI from flexibility or agility, which is to compare a scenario of how the business acted previously vs. a predicted scenario after implementation, such as ability to swap out a business service rapidly. A “hard’ ROI would come from savings of time – how much would it take to make the change with and without SOA. We don’t blame him for not touching the ”soft” benefits, such as ability to respond or change course sooner.
He added that’s also important to frame the issue properly. You should not spend time figuring how to solve a business problem, but rather, selling an idea to the business. So at first blush, that sounds like swinging for the stands, with some grand vision statement rather than saying you’ll address a tactical problem.
Yet in the next breath, Linthicum stated that it’s advisable to take an iterative approach that blends principles of Agile Development in something he terms “Agile SOA.” Namely, you develop the vision, but not all the details in advance, and then you advance into it, one modest piece at a time so you don’t end up with, what Joe McKendrick termed a couple years ago, “Just a Bunch Of Web Services” or JBOWS.
As noted, none of what Linthicum stated was new, but it was significant that, five years or so after modern concepts of SOA have emerged, that he felt the need to remind us why and how we should pursue SOA.