Architecting Services
- 09 November, 2004 11:11
The SOA concept isn't new, it's not a technology per se, it isn't just the use of XML and Web services, and it's a good deal more than a development methodology
A leading vendor in the service-oriented architecture (SOA) market space readying itself to put a proposal to a large Australian government department recently brought in an equally leading implementation vendor to quote on the implementation side of the project.
The implementation vendor, using traditional models, estimated the project would take between 10 and 12 weeks and involve 20 people. The SOA vendor rejected that estimate as hugely overblown and asked the implementation vendor to redo the estimate using the new model and modelling techniques. The result? To the implementation vendor's disquiet, the revised estimates suggested implementation would actually take just two weeks, and involve the efforts of just two people.
"Now you can see why the vendors and the service providers don't want this [SOA]," says Gartner vice president and research director Dion Wiggins. "It cannibalizes their existing revenue stream." Yet love it or loathe it, Wiggins estimates that service providers have just three years before they will be forced to take up SOA as mainstream. Once they do they are going to have to look at changing their business models - in terms of consulting at least.
The trend to SOA is inexorable, Wiggins implies, and is already well under way. The average enterprise might still have another three to five years before it can expect to gain the level of process maturity that it needs to truly capitalize on SOA, but the trailblazers in numbers of process-driven businesses - particularly in banking and insurance - are already enjoying early wins.
Brad Kasell, engagement manager, emerging technologies, IBM Software Group A/NZ, says SOA is receiving a lot of attention from all major financial services companies, all of which have already proven the viability of Web services using proof-of-concept or pilot applications and are now looking to scale that technology across the enterprise. Kasell says those SOA efforts can be expected to be multi-year and ongoing.
"Many of these organizations feel that they already have a SOA to some degree - this is as a result of enterprise architecture efforts that have taken place over the past five to seven years. To some extent, there is a feeling that the primary SOA qualifier is that the enabling technologies are more standards-based than those previously available. In fact most of the architectural considerations such as performance, scalability, reliability and availability can apply to any technology, and the concepts are well understood," Kasell says.
Among those institutions the enterprise service bus concept is proving to be very attractive. Although a complex undertaking, this has proven to be quite compelling for early users. "The reality behind SOA is that when deployed properly - that is, when accompanied by the requisite change in the way that companies do business - a SOA offers significant benefits and advantages," Wiggins says.
It certainly has at trailblazer Capgemini, whose services architecture - built off the back of the European's integrated architecture framework and used as the standard model for both internal and external clients - will enjoy its 10th anniversary this year. Australian vice president, technology services, Brad Freeman says for Capgemini the major driver of the SOA is the way it helps the organization understand how it might modify its architecture to get value out of its IT investment. Capgemini does not do much pure architecture consulting, he says, rather it uses a SOA to run its own systems integration projects as a means of getting a "better bang for its buck". But he says many of the consultancy's clients are interested to understand what their environment would look like under a services model, and how they could subsequently tweak that environment to get the best value out of it.
"We're not too evangelical about it [SOA]," Freeman says. "It's just we know that if you build complex environments using a SOA approach, you tend to get a better result, a more flexible result, and the end result is a lot cheaper over a total cost of ownership model. So you build something for 10 years, not for the next 12 months."
Page Break
Going to the Max
Also known as adaptive architecture, SOA is extensible and dynamic, with a key focus on interoperability. As a design approach SOA breaks down monolithic applications into suites of services that are available to IT across the enterprise to promote maximum flexibility and value. The idea is to optimize technology investments and achieve tighter alignment by integrating existing systems, applications and users into a flexible architecture that can easily accommodate changing needs.
Using a SOA also makes it easier to anticipate both changed requirements and potential changes in business processes. Flexibility is the name of the game.
Implemented as a collection of loosely coupled reusable services on a network that communicate with one another asynchronously and have well-defined, platform-independent interfaces, a SOA allows greater reuse of IT assets and greater adaptability to support ongoing change. As a higher level of application development it helps mask the underlying technical complexity of the IT environment by focusing on business processes and using standard interfaces. Enterprise resource planning (ERP) systems are dissolved in favour of self-contained services performing specific business functions that can be invoked over standard protocols to ensure their availability across the enterprise and beyond.
IT analysis firm Butler Group says while the majority of organizations have yet to take advantage of it, they should consider adopting a SOA as new applications are developed. The company says SOAs will have a significant effect on styles of development, with increased use of modelling and the application of patterns, and less emphasis on pure coding. They will also promote the use of Web services as the standard model of communication between application components.
Vendors say having a single standard all the major vendors support for packaging of software parts makes the idea of building large scale systems out of parts a reality for the first time in the history of computer science.
"I tend to think about it in terms of building software systems out of parts, and that's something that people have wanted to do for a long time because of course they do it in other industries like manufacturing and electronics, but in the world of computer science we've been behind the curve relative to most other industries in our ability to build systems out of parts," says WebMethods chief technology officer Graham Glass. "That's basically what SOA is all about: It's the idea of constructing systems out of parts. And one of the main problems and one of the main reasons people haven't been able to do that in the past is because there hasn't been a standard way to actually build a software part."
Consultant and IT analysis firm Meta Group says the new set of meta-architectural principles will be broadly diffused throughout the IT environment in the form of service-oriented business architecture, service-oriented security architecture and service-oriented management architecture by 2005. By 2006 it says SOA will be widely understood and treated as a metadata (or model) interoperability architecture, given its emphasis on interoperable identifiers (namespace metadata), formats (information models) and protocols (process models). By 2007, composite applications will be based on the SOA principles of dynamic, extensible, federated interoperability and enabled by XML-based technologies such as Web services.
However, Meta points out that in demanding a fundamental shift in the way organizations think about the construction and relationships implicit in their IT and business systems, SOA demands as profound a shift in thinking as client/server did several decades ago.
"This example is instructive; it took more than 15 years for client/server architectures and the associated design concepts to permeate industry at that time, and the SOA transition is unlikely to be simpler," writes Meta's Daniel Sholler. "SOA is reflected in changing ideas about how businesses are organized and should relate to each other. Put simply, it is a reflection of the long-term drive toward focus on core competencies and differentiation, and the associated trends toward outsourcing."
Page Break
All Under One Banner
Much confusion prevails about the precise definition of a SOA and its implications for the organization, especially since use of technologies like as Web services, the initiation of reuse programs and the construction of loosely coupled systems are all part of the SOA, but are often undertaken without a larger-scale perspective.
Cutter Consortium's Web services strategies editor, Tom Welsh, expresses the resultant cynicism. He says SOAs have come encumbered with "a generous helping of salesmanship, washed down with appeals to businesspeople's well-known dislike of technical details and promises to deliver all the benefits of IT without the attendant chores and limitations". Welsh says this propaganda on behalf of SOA is calculated to win business for analysts, consultants and system integrators, and notes that once contracts have been signed and payments assured, these suppliers will no doubt be able to design and build distributed systems that meet expectations and discharge their contractual obligations.
"Should anyone be uncivil enough to challenge their claim to be building SOAs, the studied vagueness that pervades most discussions of SOA guarantees that just about any working distributed system can be classified as one," he says.
Welsh agrees the aspirations behind some of the SOA advocates' more extreme claims are perfectly valid, and endorses their aim of ensuring the people directly responsible for the day-to-day running of business activities are able to create and modify applications that would automate those activities. However, he says for now when a vendor claims to have successfully delivered a SOA application, we can expect to find that traditional methods have been used. A distributed systems architect - a programmer with lots of old-fashioned experience - will have assessed the requirements, resources and constraints, asked some shrewd questions about future expectations, and come to an informed decision about the best design. If it is a distributed system and it works, it will probably be possible to label it an example of SOA.
But Gartner's Wiggins disagrees, arguing that semantic agreement between vendors on such tools as transfer protocols and Web services makes integration much easier and helps assure definitional consistency. So too does the fact that those tools allow users to automate many tasks, and in some cases, to eliminate programming. The real issue, he implies, is the ability of the organization to change in order to take advantage of SOA.
"Today's systems that are based on SOA are designed around modelling, where you draw workflow and flowcharts, and that flowchart actually becomes code - becomes executable," Wiggins says. "And that's something the businesspeople can do, but it requires a change in mind-set, it requires a change in the system itself. So instead of the old systems where the business was forced to adapt its processes around whatever IT delivered, today's next generation systems and the early first generation of SOA-based systems are turning that on its head."
He says the effect is to turn the IT department into an enabler of process, but with the process itself being managed by the business.
Page Break
The Economics of SOA
If SOA is altering how enterprise software is being designed and deployed, it also promises a superior economic model for enterprises.
Commenting in Windley's Enterprise Computing Weblog, Phil Windley notes some comments from John McDowall, CTO of Grand Central Communications, writing in Fast Takes, that SOA is evolving to the point where new applications will not be deployed as monolithic instances but will become a collection of services woven together in a loosely coupled framework.
"The heart of John's argument, I think, is a very telling phrase in the centre of his document: 'a significant part of the cost of enterprise software provides no significant business value to the enterprise'," Windley writes. "That's true of many products. We all pay for things when we only need part of their functionality. We do this because the convenience of having things pre-integrated is worth the cost of the parts we don't need. The promise of SOAs is that the integration cost will go down and consequently we'll be more likely to demand unbundled functionality that we can put back together in a custom implementation."
While some disagree, Windley sees this trend as already having "significant legs" outside software, with the modern corporate organization already much more likely to outsource much of the manufacturing and provide the initial engineering, the final integration and the sales and marketing than their counterparts of 20 years ago.
"Where [car maker] GM used to do everything, they now manage a supply chain. John's making the argument that this same trend will extend to IT and that SOA is a significant enabling technology. I think he's right," Windley writes.
Meta's Sholler notes designing for SOA involves thinking of the parts of a given system as a set of relatively autonomous services, each of which is (potentially) independently managed and implemented, that are linked together with a set of agreements and protocols into a federated structure. Not only does this describe the way many organizations think about their value chain, it is also clear these structures enable the business to be very efficient in its operations (each piece can focus on providing the service in an efficient way) and that such thinking can be applied at nearly all levels of scale, from participants in a worldwide extended supply chain, to linking HVAC building control machinery.
"Just as a business can be viewed as a network of independent components all operating together to deliver some valued good or service, IT systems can be designed based on that same principle," Sholler says.
Wiggins agrees one of the main reasons that companies are looking at SOA is because it provides them with a layer of abstraction that allows them to replace implementations of any part of their system at any point in time, without affecting the rest of their systems. That in turn leads to lower maintenance costs and greater agility. For instance SOA involves repackaging reusable business processes so that they can be built into workflow. A vendor asked to tweak a product for a client who might once have lost the sale because the work would have taken too long and been too expensive can now model the changes in the office, drag and drop a few elements, and generate the code to support it, he says.
With systems based on SOA designed around turning modelling based on workflow and flowcharts into executable code, businesspeople are - once they have suitably adjusted their mind-set and systems - doing that design work by themselves.
A case in point is CLSA, the emerging-markets arm of Credit Lyonnais, which implemented a major service-oriented architecture project that provided return on investment in just seven months. The project, begun with a clear vision and understanding of the high-level business requirements and the involvement and commitment of the business throughout, delivered business agility and time-to-market benefits beyond expectations.
CLSA sought to integrate its front-office order management system with its legacy back-office settlement system, its trade order processing system and Nova, its new settlement system, through message routing from multiple worldwide offices. The completed project would automate business flow, eliminating the need to rekey information and providing confirmation of trades in real time. The project delivered business agility and time-to-market benefits beyond expectations according to Wiggins, who has prepared a case study on the work.
"The project went live on May 1, 2002, as scheduled. CLSA reports that, overall, the platform works well and is stable. As anticipated, some performance issues arose in production after the volume of transactions increased. These issues were largely resolved by replacing the generated J2EE code in 'bottleneck' areas with optimized, handwritten J2EE code. Some minor reworking of components was necessary to make them more flexible.
"The overall flexibility and agility of the system has exceeded CLSA's expectations," Wiggins writes. "CLSA received a return on its investment after only seven months - far earlier than the 18 to 24 months that it had projected."
In Australia, Wiggins says the uptake has been relatively good. There were 300 people at Gartner's June conference, many of whom were deploying SOA.
Page Break
Pathways to SOA
According to Glass, one of the nice things about SOA is that it is relatively straightforward to put adaptors in place that can make virtually all your existing infrastructure appear as a collection of services. Indeed from an architectural perspective that is the way WebMethods recommends people go about adopting a SOA.
But how useful that approach is appears to directly relate to the complexity of the existing environment. For instance, the Australian Taxation Office has a long-term goal of moving to a SOA and is experimenting with Web services, but CTO Todd Heather says it would be wrong to say it was formally embarked on an implementation of a SOA.
Heather says the ATO has successfully exposed a Web service standard for interaction with taxpayers and tax agents through its e-activity statement application, has written a position paper for the Organization for the Advancement of Structured Information Standards (OASIS) on the definition of Tax XML, and is quite active in the evolution of that framework within the standards. However, Heather says the ATO has no plans to change its systems just to move to a service-oriented architecture. Rather, the delivery of any new architecture would occur through work done on systems for business purposes.
"The main changes we're introducing to the systems for business purposes are in the Change program because that's an assembly of packaged software - we're adopting the architecture that is inherent in those packages. We're not imposing a service-oriented architecture on those packages," he says. "We just keep looking for opportunities to drive value out of this. If we've got some basic agreements about how we're going to interoperate, then we can start looking for business value to build on top of those standards."
Heather says the ATO has done some simple object access protocol (SOAP) work in its interactions with other agencies, putting it "at the bottom end of the SOA stack".
"As we begin developing more applications during the Change Program or after the Change Program, say enhancements to our portals, we'd be trying to move up that stack towards a service-oriented architecture. But it will be in the two- to three-year time frame," he says.
Still, the route to SOA is much easier for some organizations than for others. Solutions consultant Mincom is looking to Web services to impact the way it assembles software-based solutions for customers: it plans to move from a more traditional development cycle to a dynamic service-oriented, process-focused and flow-based development style. It sees Web services as mitigating the challenges of process description and modelling.
Mincom director infrastructure solutions John Benders says because it already has a fairly modular architecture, Mincom has found it fairly easy to start on the path to a SOA by encapsulating much of its existing functionality into base services. "We're not fully at a SOA yet, but we've certainly got a migration plan that seems to be falling into place quite neatly," Benders says. "In fact this is the first time I've ever done anything like this where it's falling in so neatly as this."
Next, Mincom plans to identify the business services it wants to "expose" as true services and plug those together from those base services. Benders says while he can see Mincom will need much more in time, the first-generation tools available now are making the work run fairly smoothly to date.
"We can see that we're going to need a lot more in the future, but at the moment the timing's fairly right for us - I think we're on the right side of the curve," Benders says. "We see workflow as being the big thing. A lot of our customers want to be able to see those rules and they want to be able to - and this is I think going to be a challenge - take our services, or take what we provide, and they're going to want to change those. They're going to want to be able to say: 'That's not actually how we want that service to work; we want our service to do this, this and this.' And at the moment they're probably going to have to build their own to do that."
He says the industry is not there yet, but that is where Mincom's research effort will be concentrated in the near term.
Wiggins says the average enterprise will take three to five years to gain the level of process maturity that it needs to take advantage of SOA. In the meantime, the nay-sayers abound. As businesses become more process-oriented, that picture will change dramatically, he says.
"If they haven't started already on Web services we consider them laggards today. If any enterprise today, especially mid-size and above, hasn't already embarked on at least experimentation of Web services as a minimum, they are already in the laggard space," Wiggins says.
"The reality behind this is today if you're doing concepts and you're able to adapt and respond to market needs rapidly, then you have a distinct competitive advantage."
Page Break
SIDEBAR: Four Challenges
The development of service-oriented applications requires the following steps:
1. UNDERSTANDING which processes can be turned into services.
2. BUILDING a foundry of application processes. This will come increasingly from business applications that are designed as a set of services.
3. ESTABLISHING the granularity of services at the right level to ensure that services are effectively reusable. Too much granularity makes services too specific to be used; too little granularity makes them too general to be used.
4. FOSTERING a reuse culture is essential to consistent, repeatable success in capturing and using business processes. It enables an organization to deliver processes as a well-defined set of services and to make those services easily available to developers.
Source: Daryl Plummer, analyst, Gartner (US)
SIDEBAR: Managing the Building Blocks
by Carol SliwaYou could have hundreds of Web services. Here's how to make sure you can organize, catalogue, find and reuse them
Danske Bank A/S's trailblazing work to build a service-oriented architecture had got so advanced that it exposed more than 1000 services from its mainframes and application servers. But the Copenhagen-based bank found itself in a frustrating predicament.
"We couldn't find them," says Claus Torp, the company's chief architect.
The problem threatened to wipe out one of the main benefits of service-oriented architectures (SOA) - reuse. So Danske set about revising its concept of a service, refining its repository and establishing a governance process to enforce best practices.
The result was a collection of 140 services that is far more manageable.
An in-depth look at several SOA pioneers shows that the steps Danske Bank took are key to a company's ability to reuse code, build applications with greater speed and efficiency - and ultimately save money. But it's not easy, and the implementation sequence is important. Sun Microsystems, for instance, built a registry and set up an architecture review board. But the IT department is just now circling back to do a closer examination of Sun's 80 to 100 Web services.
Karen Casella, an IT director at Sun, recommends that a company starting down the SOA path first look at its business requirements and identify which Web services are needed. "We learned the hard way," she says. "We put some of the infrastructure in place before we completely understood what we needed to have in play."
Companies need to figure out which business processes can be turned into services, carefully design and define the services and distinguish them from components.
When Danske Bank began building standard interfaces to expose its legacy programs, it defined a service as "one function". Now it describes a service at a higher level, as a logical grouping of functionality and data, such as "customer" or "account". The company's 140 services are each composed of about 10 "operations", or components, that are essentially more granular services. There are currently more than 1365 operations. Danske expects to eventually have 250 services.
How well a company can break down its business processes and application functions into services will determine the level of flexibility and reuse it gets, Torp says. Danske uses modelling tools to develop logical maps of the functional building blocks and business processes. Then it matches the business processes to the services to make sure it has solved the right problem. "A lot of doing service-oriented development is making sure you can run different business processes on top of the same service building blocks," says Torp. "If you want to be effective, you have to make sure there is only one place to do the same function."
Cendant Corporation's Travel Distribution Services division spends a considerable amount of time determining the optimal granularity of its services and service components, according to CTO Robert Wiseman. A service is something that can be called externally through Cendant's business domain model, dubbed Rosetta Stone. A service component, such as logging, is called only internally. So a "get hotel" service might call several low-level services, such as a latitude/longitude "destination finder" that the company makes available to customers. But Cendant's currency converter is a component, since it currently isn't exposed to customers.
Cendant expects an ongoing project to extract components from monolithic applications to have a big payoff, Wiseman says. For instance, passenger name record (PNR) is a basic unit of data used by booking engines and global distribution systems such as Cendant's Galileo. By making "Super PNR" available as a service, the IT department won't have to maintain six or seven instances of PNR in different applications.
The Hartford Financial Services Group built pockets of Web and other services over three years ago, but its enterprise-scale SOA work didn't start until 18 months ago. A good candidate for an enterprise service is one that two or more applications need, says Benjamin Moreland, Hartford's manager of application infrastructure delivery. "But not everything should be a service," Moreland warns, noting the potential performance hit from exposing services.
Page Break
Establishing the Registry
Vendors may have expected Internet-based registries based on the Universal Description, Discovery and Integration (UDDI) standard to spread like wildfire. But early SOA adopters care more about internal registries.
That doesn't mean UDDI is dead, though. UDDI was so important to The Hartford that it chose its registry based on the product's conformance to UDDI 3.0. (Officials declined to name the product due to a company policy against endorsing vendors.) The registry includes metadata describing the services and the means to connect to services via particular transports. But the UDDI registry isn't meant for everything. Departments continue to maintain local registries for some services they create, because The Hartford is selective about what goes into its enterprise registry.
"We don't want to create a junk drawer of services," says Moreland. "What we feel should be in the enterprise UDDI are services that will give us leverage and flexibility across the enterprise."
Providence Health System uses the Infravio management framework for its service library, and much to the surprise of company sceptics, its developers are actually reusing services, now that they can find the Web Services Description Language (WSDL) files defining the interfaces. "We commonly refer to this as 'Google-izing' Web services," says Michael Reagin, Providence Health's director of research and development. "They can reuse services with minor modifications in a couple of hours. People are more productive. Everyone's happy." Providence Health's greater concern these days is managing its growing number of Web services and SOA framework from an operational standpoint. The company has close to 50 composite services, each one comprising one to 20 more granular subservices.
Early adopters that couldn't find a registry to suit their needs built their own. Danske Bank maintains separate repositories for components from its mainframes and J2EE- and Microsoft .Net-based application servers. The repositories replicate between each other, forming one logical repository that essentially is a superset of a UDDI registry, adding operational parameters for functions such as load balancing, says CIO Peter Schleidt. A service integrator agent dynamically selects the most efficient way to call a service, using SOAP over HTTP or more efficient, proprietary protocols.
Danske also has a structured library for its services and their corresponding interfaces. The library also houses information about the relationships between its functional and process models. There's even a librarian that developers can call for help. But the library didn't launch until a year ago - "a lot later than we should have been doing that", Schleidt says.
Governance
When push comes to shove, a governance body can help a company stick to its SOA principles. Danske Bank has steering committees in 18 different business areas for product, process and IT development. But when business managers are anxious to beat the competition, they're sometimes tempted to forgo the generic SOA approach if it takes longer to complete. "You need a governance process where you can handle situations like that," says Schleidt. "We always have the time to change things afterwards, so why not try to turn it around and do it right the first time?" The quick-hit approach can have long-term consequences. Danske now has two personalization engines, four interactive customer communication services and four payment-handling applications, Torp says.
Two years ago, The Hartford formed a central group called the Property and Casualty Architects Collective to examine how it would adopt a SOA across the enterprise. The group put together a reference architecture outlining recommended approaches, practices and products to be used in a particular context. "It's about shared architectural thought and reuse of thought processes. That's where the hard work and value is," says James McGovern, an enterprise architect at The Hartford.
A separate application infrastructure delivery group is responsible for selecting and implementing the management platform, business process engine and UDDI registry, as well as making sure the WSDL files used to describe service interfaces conform to standards. An architect not involved with a particular project reviews the project's application design to make sure services aren't duplicated.
At Cendant, project managers have that responsibility. The service name and input and output fields are accessible through an XML-based layer in its Rosetta Stone business domain model. A single group is responsible for updating the business domain model. "This is how we control reuse," Wiseman says.
If a business domain owner spots a service already in the registry, the service is flagged as a candidate for reuse. A SOA governance board, largely consisting of IT managers, then takes over. Developers need not apply.
"The programmer is the last person that should make the decision," says Wiseman. "They will always want to write something new."