The new/old approach to technology design edges into “early majority” use

 

For the skeptics out there, word has it that service-oriented architecture is real and it’s really being done—however incrementally.      

 

Consultants say many of the largest U.S. banks are in a fast follow to the activities of European and Asian leaders.

One the largest Dutch banks, for instance, has adopted SOA broadly to initiate a major redesign of all lending and customer service processes. The transition has led to more efficiency and a better customer experience.

Senior research analyst Jerry Silva, with TowerGroup, Needham, Mass., says that the SOA projects he’s helped out on here are mostly tactical and even modest. “But this isn’t bad news,” says Silva. “In fact, most of the banks are thinking very strategically about services, and seeing how they could get to an enterprise play.”

Silva explains that there is a think global, act local mindset, “in order to work out the kinks with the technology and get some immediate investment return.” He and others offer these elusive tidbits: One global giant based here is counting on SOA to retool its complete product origination activity in the online channel—meaning every loan product under the sun will share common screen designs and workflow configuration.

Another bank, far smaller, has taken a services approach to synchronize data between the online and ATM channels so that, in the words of a consultant, a customer could reset ATM interface preferences from a home computer, as an example.

TD BankNorth, according to an executive at the Halifax, Canada, IT consulting firm Keane, Inc., has relied on web services, a predecessor form, in part to enact a speedier conversion process post merger. Citibank has gone on the record at a recent Burton Group Catalyst Conference, describing its SOA infrastructure roadmap plan. Several more institutions have similar integration projects in the works, and this is just the start of what could be the next fundamental shift in how automation gets built.

And yet, misunderstandings about the technique and tools prevail even though many in the banking industry are taking great strides with SOA in the last 18 months, and at least 80% of the top 50 banks are doing “something” with the method, according to sources. One root issue is whether a bank in question emphasizes the “services” aspect of the technology (what it can do to modernize business process for clients and employees) or the “architecture” aspect, that is, the idea of code becoming uniform and reused. The latter scenario, obviously, is more of a geeky, IT kind of initiative that might leave business people not understanding what value they’ve gotten.

What makes a service
The SOA recap, in case you’ve missed the basics elsewhere: Services are more like a method of computing and software design than a technology like, say, Linux. Think of it as a concept about how business logic is supposed to be structured with a decidedly pragmatic implication for business agility and development speed.

A service is somewhat analogous to a mini program and it does some fundamental unit of work; moreover, it’s designed to be reused and recombined with other mini programs to build what’s referred to as a composite application.

“Services really are like today’s Legos with multiple custom shapes,” says Jim Adamczyk, senior executive, Accenture, New York City. “The pieces aren’t the uniform blocks of my youth, yet each piece still has that same great uniform connector that makes it easily linked to get work done.”

The consultant and IT expert was talking toys to make a bigger point, that SOA is, in the view of many, a logical extension of web services (discussed here and elsewhere between 2000 and 2004) built with WSDL, SOAP, and other standards that yield interoperability. Where web services were humble and relied a lot on the imagination of the handler—just like those old-fashioned plastic blocks in hunter green, bold blue, and siren red—next generation services have more specialty and shape “out of the box.”

To Adamczyk, the latest development of note is linking SOA with business process management application sets and/or portals, to expose code in the context of human-centric work. Or, if you prefer to think of it this way, to put a computer screen of visibility into a process that a person can interact with that was either manual or, at the other extreme, part of a cycle of batch transactions previously.

Why do it this way?
What’s the point of evoking services instead of executing standard application code, often referred to as monolithic application code? The short answer is, services yield composite applications which are easier to connect to other composite applications, in or out of the context of workflow. (The longer answer has to do with stripping out code redundancies inherent in traditional software design.)

Experts tend to divide the territory, for discussion sake, into low-level, IT-specific services and those that represent, in essence, chunks of business process. So while “check balance,” is an example of the former, “measure customer value” is closer to the kind of service that next-generation practitioners are looking for. Not that SOA is trouble free. Some common problems include not planning for security or not starting with an XML foundation architecture, according to IT expert Thomas Earl, who blogs on the subject. He also indicates that troubles arise when organizations don’t standardize their SOA platform and building methodology, (say, declaring themselves a .NET shop or a SUN shop) which leads to problems like incompatible data representation or non-complementary web service extensions. Also problematic, according to Earl, is the lack of technical and business governance.  For instance, failing to figure out who owns a given service and under what terms it gets evoked.

But while some may be perplexed—or gaga—in their struggle to grapple with services, others aren’t all that impressed.

 

“My sense is that services are mistakenly viewed by some as the Holy Grail,” says Robert Usner, director of marketing, product management and quality assurance for Nexus Software, Inc. “To me, SOA is just another integration tool,” he says.

Granted, by virtue of his company’s market position, Usner is involved in data integration projects rather than other types, but his gut sense as a technologist is that services should not have ubiquitous play in the back office.

“Its use makes sense where there is a benefit derived from loose coupling—that is, where two services aren’t internally constructed the same way or don’t come from a common platform,” Usner explains. “Yet for many executives, they have a hammer and everything looks like a nail.”

Chris Curan agrees. The chief technology officer is with  Chicago-based, operational strategists Diamond Management and Technology Consultants and has seen many early projects peter along.

“A company has to make sure its IT group is ready to collaborate with business executives and that its assets are organized to get the best results,” says Curan. “What you are doing, technically, is exposing code more broadly across an organization and reworking how business logic is distributed so you need collaboration,” says Curan. This need for broad, multi-department exposure can be true even of tactical projects. “Because of that, execs also ought to identify processes and workflow first,” says Curan.

There may be a way to break the gridlock, notes Patrick Morrissey, senior vice-president marketing and business development, Savvion, Santa Clara, Calif. His suggestion? To create an application set that can effectively bridge disparate business and technical “reference systems, vocabularies, and methods.” (What he means by this is that a business exec thinks of account opening in terms of real world customer and business process steps, but a technologist thinks of it in terms of, say, accessing data or linking to system code to enact a procedure.) The company recently introduced BusinessManager 7.0, a business process management suite that allows a window into to the steps embedded in project work.

“This effort to map, then redesign process, and make use of services to streamline the coding underneath can deliver the kind of agility that SOA alone is being credited for,” says Rob Risany, the firm’s product marketing executive.

Not that the technicalities that lie beneath aren’t steep. Randy Heffner, vice-president Forrester Research, Cambridge, Mass., hosted a November teleconference, When To Use Which Web Services Specifications, suggesting to the writer that many details had yet to be worked out before, as Gil Scot Heron might say, this revolution could be televised.

How much do they need to know?
Not all business executives understand these sorts of nuances and, in the tech community, there is a raucous debate going on about how much business people need to know. Yet because services have the potential to distribute business logic differently, the tools, techniques, and potential drawbacks probably should be understood on some basis. To get projects developed properly, Heffner thinks business executives ought to be in the driver’s seat.

“Right now, quite frankly, the business people have to be in the position to champion these initiatives because IT still doesn’t have the clout it once did,” says Adamcyzk. “While we are finally at a place where innovation is being emphasized, banks need clear project definition.”

Lance Hill, vice-president product and solution marketing, WebMethods, Fairfax, Va., says of the dozens of projects he’s aware of personally: “Some banks are very open about use of services—maybe they are wrapping services around legacy code for example,” Hill explains.

“These SOA enthusiasts tend to educate business execs, and are generating buzz and support from the top down with formal committees and a lot of SOA discussion,” he adds.

Others, notes Hill, have decided that their executives are better served by low key, tech-driven, adaptive strategy that leaves business people only with results.

However a given bank goes about managing their learning curve and political issues, they should adopt projects that drive out cost and drive up revenue, says consultant Judith Hurwitz, founder and president of Hurwitz Associates, Burlingame, Calif., and author of the recently published, SOA for Dummies.

Only then should businesses take on the more esoteric infrastructural aims of service reuse and code “perfection” and lifecycle management around creating, connecting, managing, and upgrading services. BJ

 

The electronic version of this article available at: http://www.nxtbook.com/nxtbooks/sb/ababj1206/index.php?startid=48

TrackBack URI for this entry