Also read SOA case study: Longo’s takes a fresh approach to business
Let’s say you’ve done it: after consolidating servers and working with a variety of middleware products, you’ve created a services-oriented architecture for your enterprise. Congratulations. Now comes the hard part of actually building the composite applications that are supposed to make the SOA effort worthwhile.
The goal of SOA should be composite applications that eliminate what some call “swivel chair” integration, where users tap into a number of applications to carry out a process but need to “hot key” between them, transferring information manually. What follows is an action plan.
1 Know what you’re working with
A composite application leverages a lot of existing logic, databases and file structures in order to create a new system. According to Russ Altman, CTO for SOA at Sun Microsystems, we’re talking about 60 to 90 per cent existing code, and only 10 to 15 per cent new code. “There’s no clean slate there,” he says.
Perhaps as a result, companies sometimes struggle to figure out what they will leverage for subsequent development. “What are the databases, overlap, points of leverage, redundancy? All of those things have to be understood. You can’t wait until everything is modelled,” Altman says. IT managers should start by mapping out everything that goes on in the business, what is managed, and what are the processes.
2 Don’t count on native scripting
The first experience most enterprises have with composite applications involves open source frameworks or commercial variants such as Adobe’s Flex, says David McFarlane, COO of Nexaweb. “What they quickly learn is there’s a big gap between the simple approach of enhancing an existing Web site or RIA and actually building an enterprise application and needing to integrate into the architecture,” he says.
In many cases companies can end up with unsupportable “spaghetti code” that may have meaning to the original developer but doesn’t have the separation of UI and logic that you would find in object-oriented languages. Nexaweb naturally recommends its own suite, but there are others from IBM, BEA and JackBe.
3 Plan your long-term reuse strategy
Altman offers some questions to consider: How many clients can leverage the service you’ve built without changing the service? If you have to change the service to meet the needs of second or third clients, can you keep all the variations separated so that you don’t break your contracted functionality for previous clients? “I may need to do logging different, routing different, billing/metering different, throttling,” he says. “I may need to implement so that I can readily swap one and not break everything else that’s been built.”
4 Abandon the ‘rip and replace’ mentality
Some enterprises see SOAs as a way of deploying all-new software, but Forrester Research analyst Ron Rogowski suggests that’s misguided. “This is a platform that enables applications to interact. In fact, it’s new types of interactions that previously weren’t able to happen through an interface like this. That’s where the real benefit lies.”
5 Budget for services as well as tools
Companies like Nexaweb may charge for their products based on the number of developer licences or through a run-time model based on the number of CPUs involved. It services business, according to McFarlane, is priced “a la carte,” depending on which kind of subject matter experts will need to be brought in to help map out the transition to composite applications. “The issues and challenges they’re dealing with go way beyond the challenges of the technology,” he says.
6 Insist on governance from the get-go
As you start wrapping existing applications with a variety of services, you need to set parameters, according to Rob Gagne, Nexaweb’s vice-president of engineering. In other words, decide what the service level is, who should be accessing the applications and what kind of functionality they provide. Altman refers to “run-time governance” issues. “You have to figure out, what (you) need to do from a quality of service/policy enforcement perspective that is unique to each pairing of service and client,” he says.
7 Measure ROI based on productivity
McFarlane says he has seen customers execute a change request in one fifth to one tenth of the time they do today. That means moving, in some cases, from a six-month point release cycle to a weekly release cycle.
Rogowski thinks it may even eliminate status inquiries. “It used to take 30 days to satisfy some requests. Now it might take three days.”
SIDEBAR: Choose your mashup toolset
Nexaweb Enterprise Web 2.0 Suite features a framework for deploying applications in a browser, a network tier to move data from the server to client, and clustering and failover capabilities. Developers can use technologies such as AJAX (Asynchronous JavaScript and XML) or Java. Also highlighted are integrated debugging, testing, and governance capabilities.
Nexaweb Enterprise Web 2.0 Suite costs US$17,500 for the platform and support for three developers, who could build an application supporting hundreds of users.
JackBe’s Presto Wires functions with the company’s Presto Edge mashup server, which offers secure access to disparate data and services. Users of Presto Wires, who would be business analysts as well as developers, can integrate Web services via a drag-and-drop workflow.
Services can be gathered from such sources as RSS feeds, maps from Google, and research data. Presto Wires carries a list price of US$40,000 per CPU.
Laszlo’s Webtop SDK for Developers works with the OpenLaszlo 4 development platform to extend, brand and build applications. Featured is the machinery around a windowing system application integration, single sign-on, and capabilities to offer a visually integrated experience with data integration on the back end.
Evaluation copies of Lazlo Webtop 1.2 is free for 30 days. Pricing for Webtop deployments starts at US$27,000 plus a per-user fee. The SDK starts at US$795 per year.
Also read SOA case study: Longo’s takes a fresh approach to business
