SOA in Action

Will Web 2.0 approaches such as application mashups finally bring SOA to the masses? Software AG technology evangelist Mighael Botha thinks so, describing mashups as "the face of SOA."

That's because mashups are tangible and accessible, he says -- "something that I can take to a user, and say, 'Okay, this is a mashup that shows a single view of a customer within your organization.' Although typical business users may not relate to IT terms like 'enterprise service bus' and 'governance tools,' and even if users don't understand what a mashup is, they can be presented with a single view showing all kinds of data about customers or products through a Web 2.0 or AJAX front-end."

As part of our series of podcasts with industry leaders that we launched in conjunction with InfoWorld's SOA Executive Forum (held May 22-23 in New York), I had the chance to speak with MIchael. (Link to the podcast here from InfoWorld.)

"ESBs use services that are foreign to the user," he says. "But the mashup is the real face of SOA, bringing business closer to an event-driven architecture to show them that they can really get useful information from the new technology that is being implemented."

Botha also discussed how even with governance, businesses struggle with right-sizing in SOA initiatives. Services may not fit enterprise needs the way they are originally implemented. Right-sizing goes through constant measurement and optimization after implementation, says Botha. "After a third or fourth iteration of the release of a service or a software package, you typically get into a situation where everything has been optimized and that piece of software is right-sized."

Web and Enterprise 2.0 technologies may simplify both governance and right-sizing, as well as boost overall SOA adoption, says Botha.

(Click here at the InfoWorld site to hear the entire seven-minute podcast.)

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Many companies set out with SOA to achieve an integration goal or streamline an application or process -- and wind up far more than they originally expected. As companies move further along the spectrum of SOA deployment, BEA engineering vice president Charles Stack says companies are discovering to their delight and surprise that the changes SOA brings are more fundamental than originally expected.

As part of our series of podcasts with industry leaders that we launched in conjunction with InfoWorld's SOA Executive Forum (held May 22-23 in New York), I had the chance to speak with Charles. (Link to the podcast here from InfoWorld.)

"Businesses are finding that what they intended the services to be used for only scratches the surface of what they actually could be used for," Charles said. Deep organizational changes are required as a part of the implementation, but these changes present companies with new business opportunities -– in part, as a result of the deconstruction of their former business capabilities.

For example, Charles explained, as the number of companies' services increases, there are more opportunities to "make them available to a broader community -- whether it's internal to your enterprise or even external to partners." Charles talked about the rise of "unintended uses or serendipity" that accompany a growing service repository. "Services are being consumed by others within the organization in ways and for reasons that were maybe never considered."

(Click here at the InfoWorld site to hear the entire 12-minute podcast.)

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

The convergence of service-oriented architecture and Software as a Service lays open the possibilities of bringing in services from outside the firewall, which can be “snapped” into place within a company’s infrastructure. This also means that services a company creates can be introduced to a broader market beyond the firewall. Miko Matsumara, vice president of product marketing for SOA at webMethods, says that as SOA and SaaS mature, the two will open up vast new markets that no one is even thinking of today.

As part of our series of podcasts with industry leaders that we launched in conjunction with InfoWorld's SOA Executive Forum (held May 22-23 in New York), I had the chance to speak with Miko, who applies his Yale training in Neuroscience discover new truths about the way services organically interact with each other. And he had plenty to say about the way SOA is evolving in the context of SaaS. (Link to the podcast here from InfoWorld.)

"We're seeing an entire transition in the industry towards business services residing on the Internet," Miko said. First, he said, look at how “you consume Software as a Service in your enterprise.” One of the most exciting aspects of SOA, he said, is that “organized capabilities may be under the control of different ownership domains. It means that you can actually bring services into your company from the outside. At the same time, because of the integration and component architecture and the use of standards, you could just snap it into place and consume software services much like you would consume internal IT services. It all snaps together like LEGOs.”

But the story gets even more interesting as SOA-SaaS evolves, Miko continued. “Organizations are now beginning to deploy what they have to offer into the economy, deploying their business services onto a network deployed model,” he explained. “This actually takes it beyond Software as a Service and it starts to get into business services on the Internet.

“We're starting to see that the entire economy is not just moving to delivering software as services, but delivering packages, books, and anything that you can imagine in products and services as Internet-connected service interfaces.”

Miko also pointed out that governance and planning was important right from the beginning when deploying SOA. "Out of the box, people need to start architecting and engineering for this future state," Miko explained. "People who favor speed and scale before they start thinking of structure and governance could be at risk of having their projects falling apart."

(Click here at the InfoWorld site to hear the entire seven-minute podcast.)

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Service-oriented architecture and Software as a Service (SaaS) both use the word "service," but with two different meanings. And, typically, SOA has been within the firewall, while SaaS has been outside the firewall. Eric Newcomer, CTO of IONA Technologies, says it won't be long, however, before SaaS and SOA converge.

As part of our series of podcasts with industry leaders that we launched in conjunction with InfoWorld's SOA Executive Forum (held May 22-23 in New York), I had the chance to speak with Eric, who has been leading the charge for standards in the Web services/SOA space for some time. So I knew it would be interesting to get his latest take on the state of SOA. (Link to the podcast here at InfoWorld.)

One emerging trend Eric is watching closely is Software as a Services (SaaS). Namely, as things progress, many services that are part of the SOA may actually come from outside of the company. Eric feels that as enterprises break down applications into reusable services, and "start to think about hosting some of those reusable services outside of the company, and delivered in a Software as a Service mode." Likely candidates for SaaS-based services would be commoditized portions of ERP or packaged applications, he said.

"I see Software as a Service taking a very important role in SOA, especially around commodity or very general-purpose functions, such as accounting and billing, security, and maybe transformation, where it's not really to a company's competitive advantage to develop, build and host those kinds of services."

Eric also spoke about the management issues in SOA deployments. One issue is making sure that services generated by business units are scalable and ready to fit business requirements, he said. "We see emerging technology such as SCA [Service Component Architecture], providing the capability to compose multiple services together." Eric also said orchestration engines such as BPEL are playing a role in service management, "where you can take the very large-grained interface that meets the needs of the business and decompose it or assemble the smaller grained services that the developers might be working on."

Also, thanks to Web 2.0, interactive consumer sites like Google Maps are upping the expectations for enterprise applications, he said. "You've got a couple of challenges there. One of them is to get the level of interactivity improved in the user interfaces on your enterprise applications based on adoption of some newer technologies such as AJAX and maybe Flash, and some of these nice presentation technologies that are coming out."

Although companies need a way to connect those interactive technologies to existing systems and data sources, Newcomer cautions against thinking of a mash-up as a means to integration. "We've seen this with portals and with screen-scraping," he says. "You want to make sure that you have a good design for scalability, performance and maintainability -- which sometimes, taking that approach might get in the way of."

(Click here at the InfoWorld site to hear the entire seven-minute podcast.)

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Perhaps a good analogy for a service-oriented architecture is a condo or homeowner's association. The structure belongs to everyone in the organization. There is, in theory, no single owner. But, collectively, the co-owners entrust management of the enterprise to selected officers of the association, and everyone is expected to abide by their enforcement decisions.

The model works well for homeowners' associations (unless you're the one being told to take down your holiday lights) -- is this a good approach for enterprises as well?

The fact that SOA has no single owner creates a host of governance issues. I recently explored some of these issues in a podcast I hosted with special guest Ashish Mohindaroo, Oracle's Fusion Middleware Director. The podcast was conducted as part of last week's InfoWorld SOA Executive Forum, at which Ashish was a featured speaker. (Link to the podcast here at InfoWorld.)

Whereas in past enterprise projects a single department had complete control over a project, SOA breaks down departmental barriers -- and that raises new questions, Ashish says. Questions such as: Who has access rights? Who manages services? Who pays? Without answers, notes Mohindaroo, tension could emerge between departments if companies are made to play it by ear.

That's what makes governance so important, Ashish continues. Governance provides a management structure for SOA, which lacks the direct or centralized control that technology projects typically have. "The whole idea behind governance is to really define a path of how a company can start from a point project and then scale it out by breaking down the departmental barriers across the enterprise."

While Ashish believes most companies are past the point of needing to be convinced of the value of SOA, most projects are still in the early phases. That's why starting early with governance is important. Governance is more than creating a repository of available services, he says. "Governance means having a standard of service has to pass certain parameters. It has to be defined in a specific manner. It has to meet a certain service-level agreement. And it has to conform to the specifications that have been defined by this governing body within the organization." Once these standards are set, Ashish explains, "it's very easy for companies to change policies or change definitions without going back into the hard process of manually recording these policies and structures into individual Web services."

(Link to the podcast here at InfoWorld.)

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Are mashups the new face of SOA? SOA and Web 2.0 may have a lot more common ground than first realized.

Recently, I had the opportunity to work with Gian Trotta, Beth Gold-Bernstein, Elizabeth Book, and the ebizQ team to prepare collateral material to go with InfoWorld's recent SOA Executive Forum. Our special report on SOA and mashups for InfoWorld can be found here.

As part of this effort, I had the opportunity to speak with some industry leaders about the converging roles of SOA and Web 2.0. Mighael Botha, technology evangelist at Software AG, for one, sees “mashups as being the face of SOA,” he said. “Mashups are something that I can take to a user, and say, ‘Okay, this is a mash-up that shows a single view of a customer within your organization.’ The user might not understand what a mashup is, but when they see that they can get all kinds of data about their customers or products from five or six or seven different systems in the back end.”

Web 2.0 may ultimately even be good for SOA. Ashish Mohindaroo, senior director of Oracle Fusion Middleware, observed that “Web 2.0 is all about increased user productivity, and SOA is increased reuse of existing assets. If I'm able to mix and mash different Web site content, to deliver a new page or a new service to my end user, that's a great thing,” he explains. “I can assemble new services which in the past would have taken me a longer time because everything had to be built from scratch.”

SOA and Web 2.0 have different constituencies, at least for now -- SOA tends to involve enterprise architects and development shops, while Web 2.0 has more of a consumerist element.

Beth Gold-Bernstein also observes that there may be a generation gap at play with Web 2.0. Namely, that its now part of life for the under-40 crowd.

This is bound to inevitably percolate into corporate management. And, there is more Web 2.0 being adopted within enterprises as of late. A recent survey of 2,847 executives worldwide by McKinsey & Company finds that investment in or planned adoption in the following Web 2.0 technologies and approaches: social networking (37%), RSS (35%), podcasts (35%), wikis (33%), blogs (32%), and mashups (21%).

My colleague over at ZDNet, Dion Hinchliffe, observes that SOA and Web 2.0 have different centers of gravity, however. Dion has been watching the mashup developing between SOA and Web 2.0 for some time, and observes in a new post that both categories share a lot of overlap, as both invoke standards-based services that can reside anywhere across the Web."We’re continuing to see more clearly that Web 2.0 and SOA really are largely (but not 100%) the same concepts that merely lay on different — if fairly different — parts of the software continuum." The major difference, Dion observes, us that Web 2.0 focuses on the data as the most important part of software applications, while SOA focuses on the services and messaging.

Many industry leaders now agree that enterprises need both the structure of an SOA-type approach and the entrepreneurial energy of a Web 2.0 approach. As part of the InfoWorld SOA Executive Forum project, I spoke with Miko Matsumura, vice president of product marketing SOA for webMethods, who cautioned against letting mashups run too far amok without governance, as “there is almost a tyranny to structurelessness,” he says. “That kind of model is inherently less agile, flexible, and more expensive, than a model that actually consists of logical constraints.”

Miko added that the constraints SOA governance may impose "should be thought of more as a ‘pivot’ than as a ‘straightjacket.’ If you constrain something along one dimension, it doesn’t mean that it’s not free to move across the other dimension. That’s the balance that SOA represents, which is the IT-business alignment. One side wants to go wild, while the other side wants to buckle down everything.”

Both SOA and Web 2.0 have much to offer organizations going forward. Web 2.0 may have the wild, untamed energy of restless youth, but SOA brings the experience and maturity to keep efforts focused.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

What can an organization do to free itself from "Service Averse Architecture" and move more boldly into the Service Oriented kind?

Through a good diet, lots of exercise, and changing bad behaviors -- figuratively, that is.

I recently had the opportunity to join Anne Thomas Manes (Burton Group) and ebizQ's own Elizabeth Book for an interesting chat on the reasons why companies end up with SAA, rather than SOA. (Podcast is here.)

Unfortunately, as Anne noted, SAA is the "status quo." Elizabeth recently blogged about SAA, defining it as an architecture that is built without having first consulted the people who will use it, is unreliable or does not deliver on its promise, is so secure and complex that it discourages people from using it comfortably, or is so insecure that its data is compromised, corrupted, lost or stolen.

The root of the problem for organizations stuck in this rut is that they treat SOA on a project-by-project basis, rather than as an enterprise effort, Anne said. "You can always supply service oriented architecture concepts and principles in every single project that you do. The thing is, if you're only doing so on a project-by-project basis, then you're not going to get significant value out of it.. You're just going to get small incremental value -- and that's not necessarily a bad thing. But if you really want to do service orientation, you want to reduce the redundancy that you have in your environment, reduce the number of systems that you have to integrate. You need a cross-project perspective to figure out where your priorities are and what it is you need to do first."

However, not every IT department or enterprise is ready for the kind of changes SOA requires or brings about. Just as lifestyle changes are often necessary to improve one's health, enterprises and their IT departments may also need "lifestyle" changes to successfully leverage SOA, Anne noted. "I think of SOA being a lifestyle. You have to start thinking in a completely different way if you really want to make your systems more agile and more flexible."

Part of this lifestyle overhaul is to think in terms of business needs, not technology needs. "You have to work with various folks in the business organization, to understand what the business is," Anne said. "What are the things that the business has to accomplish? Then you figure out how IT can support it."

Click here for access to the full podcast.

Posted by joemckendrick in SOA  |  Permalink  | Comments (1)  | TrackBacks (0)

I just had the opportunity to stop by InfoWorld's SOA Executive Forum in New York to imbibe in the whirlwind of enterprise case studies, expert panel discussions, and thought-provoking keynotes.

What's the buzz this year in the world of SOA? A couple of observations:

With the exception of security, there was very little discussion of the technical issues of service development and deployment. That's because, well, there are no technical issues.

What was top of mind and top of discussion across all the sessions and panels was the organizational and management aspects of SOA, which are the perplexing and hair-pulling issues that are holding back SOA progress.

However, while ZapThink's Ron Schmelzer has been kicking up lots of dust as of late with his recent missive that SOA is being hobbled by IT departments themselves, I got the sense at the conference that IT -- at least among the enterprises presenting -- was leading the charge to business transformation.

In fact, the conference kicked off with a major IT-led transformation of what was a government organizations a decade ago to a lean, mean fighting company. W. George Glass, Chief Architect for BT, described his organization's SOA efforts, which began in earnest about three years ago. As a result of the SOA, the company has been able to close down close to 800 systems, and plans to close down another 700 to 900 systems over the coming 12 months, Glass said.

BT's SOA proponents have been able to evolve the company's focus from maintaining operations to concentrating on the customer experience, he explained. Now, even BT's CEO is talking about services such as order to cash. "The language of the IT department has now percolated right up through the business," he said.

BT intends to be fully SOA enabled by 2009, Glass said. BT's SOA deployment now covers up to 3,500 core systems, built on 14 platforms. BT has identified 63 capabilities that includes various functions, with another 22 on the way. New capabilities go into the test cycle every three months, Glass said.

To keep IT on track, BT also has tied carrots and sticks to the use of standards and shareable services in new applications, Glass added. If members of the IT department pass the implementation test in line with SOA, they earn a bonus in advance. However, "every time IT deviates against the architecture, they lose a quarter of their annual bonus," he said.

When fully complete, the transition will make it much easier for BT to build and introduce new products and services for customers by reusing common components – say, customer identification and revenue collection – allowing BT to focus development resources just on new functionality, Glass said.

Glass emphasized that to build acceptance for SOA, proponents need to "show the benefits to business partners in dollars and cents." We established a "completely new way of working at BT -- always start with the customer experience. "We're using SOA to build a customer oriented architecture."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Elizabeth Book has coined a new way to describe many of the attempts at Service Oriented Architecture that don't quite make the cut: "Service-Averse Architecture."

Elizabeth says the a service-averse architecture is a project that meets at least one of the following descriptors. (Naw, there can't be too many of those out there, right?)

An architecture that is built without having first consulted the people who will use it.

An architecture that is unreliable or does not deliver on its promise.

An architecture that is so secure and complex that it discourages people from using it comfortably.

An architecture that is so insecure that its data is compromised, corrupted, lost or stolen.

An architecture that, in short, is averse to the services it is expected to provide.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Which comes first, the service or the machine?

The service should be designed first, of course. But in the world of legacy systems, there may be limits on what services can be extracted or exposed. The mainframe is a great SOA engine -- probably the best -- but it can also be limiting.

IBM is really, really, pushing the mainframe hard as an SOA enabler. Among many other things, last month, Big Blue announced that it has expanded its CICS software to better leverage the System z platform as the computing hub for SOAs. The vendor also said it is currently working with over 1,000 enterprise customers that are implementing SOA with the mainframe as a hub. "Mainframes are finding second careers as the hub for SOA," said James Stallings, general manager for IBM System z.

Sounds good. Where's the downside, then?

In a new article, Mike Oara, co-founder and Chief Technology Officer of Relativity Technologies, discusses the issues that arise when a company seeks to expose mainframe applications to the SOA cloud.

Namely, that while the mainframe is a great, solid, scalable machine for supporting SOA, identifying exactly which services should and can be exposed to the outside world is not a trivial task.

Mike says three questions tend to arise during this process:

Should one begin by deriving services from the legacy application, or rather start with all potential services and decide which would fit actual business requirements?

If certain services are required, what is the best way to find them within a typical legacy application?

What is the most suitable degree of granularity at which they should be defined?

There are three ways to identify such services, Mike explains:

The top-down approach: This approach "advocates the up-front definition of services by architects and analysts. This group defines the best set of services that could possibly satisfy all business requirements." However, the mainframe may be incapable of offering such services. "An architect may determine, for example, that a service should allow an application to retrieve the top three most expensive items ordered by a customer. Although the information is in the database, the mainframe program may be incapable of retrieving order data in this way or with this criterion."

In other words, someone may be trying to design a sportscar with parts from a minivan.

The bottom-up approach: Here, Mike states, "the definition of services originates in the knowledge of the legacy application. The services are discovered, rather then defined as requirements." However, he cautions, "this form of service definition is known to produce sets of services that are awkwardly defined, superfluous, and out of alignment with real business and architectural requirements."

In other words, the SOA is bent, shaped, and twisted into unrecognizable forms to try to make it fit with the existing apps.

The meet-in-the-middle approach: "In this approach the service modeling team and the mainframe application experts work together to identify potential services that are both useful and feasible, given the existing legacy constraints. Before solidifying a particular design, the architect would ask: 'Can such a service be provided?'"

This falls in line with what SOA should be all about -- opening up communication and collaboration across business unit boundaries. The mainframe folks have tended to be isolated from the distributed application teams.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

InfoWorld is preparing for this week's SOA Executive Forum in New York, and I and other members of the ebizQ community had the opportunity to help prepare of collateral material around the event, including a series of podcasts and articles with conference speakers. We'll provide links when ready.

InfoWorld's Galen Gruman has also just published this overview of what it takes to break SOA bottlenecks within enterprises.

As Galen observes, "tools and applications, even those totally relevant to SOA, get you only so far. Any enterprise embarking on an SOA journey needs to know where it’s going and how to make the right preparations. Fortunately, SOA has been around long enough for some top-level best practices to emerge. And frameworks and maturity models from vendors and consultancies are beginning to crystallize. So are the barriers and bottlenecks that thwart SOA efforts. Some are technical, but most are managerial — tough issues that will put IT in new, often uncomfortable roles that may test all participants’ faith in whether IT and business are truly aligned."

Here are some of the major bottlenecks Galen has identified:

Getting the concept: "If you think that using WS-* standards, licensing an ESB and deploying service registry means you've arrived, think again.... It's easy to miss what SOA is really about.... SOA is an architectural concept not necessarily tied to any specific set of technologies. Think of it as a many-to-many topology: many services and many applications — and that’s pretty much it."

Selling the dream: "The key to getting a buy-in is to explain SOA not as a technology, but as a way of operating the business more effectively by being process-oriented."

Hammering out the architecture: "An effort of several months involving business managers and enterprise architects can create the basic blueprint a company needs to begin guiding its SOA effort; you fill in the details as you work on specific deployments.... Businesses can’t improve unless they understand what they are doing and what they want to do. That requires understanding the business processes, which companies often don’t do, instead acting on instinct or autopilot."

Scoping out services: "There are several dangers in mapping processes to services: defining them just for the current project’s needs, defining them at the wrong level of granularity, and building services that aren’t needed. Developers have to anticipate how the service — whether created from scratch or derived from a legacy application — might be used in other processes, so the service can be employed in both current and future projects."

Timing the technology choice: Too many companies buy SOA technology tools before planning out their SOA. "it’s a mistake to buy SOA infrastructure, governance, or development tools until you have your enterprise architecture in place, along with the operational architecture -- that is, the design for how you will actually run your services."

Addressing the data problem: "SOA requires an underlying data architecture, so no matter where the data originates, the metadata describing it is consistent enough to be understood the same way by all services using it... That's one big cleanup job."

Governance, governance, governance: "Although specifics vary from company to company, it’s becoming clear that there needs to be a central entity to establish and maintain policies for building and using services, including monitoring compliance and resolving disputes. This can be a center of excellence, an architectural review board, a competency center, or a program office."

Changing developer culture: "The last thing developers want are SOA "governance cops" telling them what they can and can't do. To change the individualist developer culture, create the right incentives."

Avoiding vendor lock-in: "With the sprawling nature of SOA, and the immaturity of some SOA-related standards, vendors want to reel you into their proprietary world."

Putting services to the test: "Dependencies among services increase the complexity of testing, especially when you can't possibly predict all the future applications that may consume a service."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Last fall, ebizQ put together a very comprehensive survey of SOA governance policies at 313 companies last fall, which found that those sites that have runtime and design-time automation are far more likely to report high levels of comfort with their governance solution than those who rely on manual enforcement. ZDNet colleague Beth Gold-Bernstein emphasized that the most value is gained during the development-time process for SOA services. (The Webinar is archived here.)

In this new post over at Enterprise Systems, Kelly Shaw has put together five additional pointers for effective development-time governance:

1) Focus first and foremost on the delivered applications, not the services. "Many failed SOA initiatives are the result of developers’ focus on deconstructing existing applications into component services with little or no business value... Instead, developers must work closely with end-user representatives or business analysts who have a business perspective about what capabilities the application must provide.... Visual models work best. They provide a common frame of reference understood both by the business analyst and the development organization."

2) Services should built new only as a last resort. Developers "need is a metadata repository that includes interface definitions, data definitions, SLAs, security requirements, known defects, application lifecycle information, and historical information from the runtime such as performance data." This repository should be integrated with the IDE and registry.

3) Services need to be delivered with a comprehensive set of unit tests. "You can’t afford to have poor quality services in production. Similarly, updating a service that is already in production is a risky proposition... You can mitigate the risks associated with updating production services by requiring that all services be delivered with a comprehensive set of unit tests that can be run to validate the quality and correctness of the service."

4) Always perform consumption-side tests before deploying a service into production. "...you shouldn’t do is skip this step or you won’t be able to perform a reliable impact analysis, and your risk of production failure will dramatically increase."

5) Separate your production deployments from your consumption deployments. "You can get your updated service into production, resolving any problems without the added complexity of a new application release. If something does go wrong, you know where the problem is and can revert to the previous service version without fuss."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

You can look at the SOA-virtualization connection two ways: one, SOA itself is a form of 'application virtualization,' in which components are represented and made accessible via an abstraction layer, or, two, since SOA workloads can be unpredictable, infrastructure virtualization allows for the right allocation of processing resources when needed.

Recently, one of my colleagues here at ebizQ, Gian Trotta, spoke with Ken Oestreich, product management director for Cassatt Software, about the ways virtualization can improve SOA management. (Listen to the podcast here.)

According to Oestreich, virtualization offers a great deal of potential benefits in terms of performance and agility, in part because it offers operating system and platform independence, meaning companies don’t need to make system-wide changes in order to use the software. A pooled, automated approach gives IT management a faster time to market -– in effect, dropping an application into a pool of resources without the need for traditional consolidation planning.

There has been a lot of discussion across the industry and the blogosphere around the SOA-virtualization connection. For example, late last year, Butler Group issued some research that also discusses the convergence of SOA and virtualization (but keeps the two concepts separated). The analyst firm found in a survey that 69% of companies have put into place or have piloted virtualization solutions against their servers and other infrastructure components, while only eight percent have working SOAs in place.

However, the report notes, while many organizations are moving to server and storage virtualization to abstract those resources, but the real value comes from abstracting software through SOA: "The use of server and storage virtualization technology is bringing significant benefits, including the creation of a more flexible pool of IT resources better able to support consolidation and optimization strategies, along with improved workload management, and much better utilization of hardware. This will become a key element of infrastructure flexibility that will see rapid growth over the next two years. The move towards a SOA is a key element of software flexibility, and will fundamentally change the way in which software applications are designed, developed, and deployed."

Udi Paret, a Silicon Valley enterprise software executive, said perhaps more SOA-style thinking is needed to extract more value from system virtualization. Speaking at a conference, he observed that "the recent shift towards virtualization – virtual servers, virtual networks and virtualized storage – is only compounding the problem [of data center sprawl]. …the total number of entities to be managed continues to skyrocket. The focus is simply too tactical; the level of abstraction is too low."

Paret urges a shift to what he calls "service-oriented infrastructure," which "operating system for data centers" that "can automatically reallocate hardware, software, systems, connections, etc., in terms of high-level, service-driven objectives, as business conditions change, or response to problems or catastrophes, to keep service at guaranteed levels."

InfoWorld's Tom Yager is not so keen on the SOA-virtualization connection, branding the concept "virtualization oriented architecture," which pulls the nitty-gritty of data center management together with SOA principles, and issued this warning: "VOA calls to mind the use of virtualization to make SOAs more durable, mobile, and versatile. I can see SOA and virtualization — brilliant, simple technologies — pairing to devolve into an enterprise Frankenstein of ultimately unmanageable complexity."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

New data out of Saugatuck Research finds Software as a Service (SaaS) is gaining traction in today's enterprises. As reported in Network World, more than a quarter of companies are using at least one SaaS application, up from 11% at the beginning of 2006, the consultancy reports. Saugatuck goes on to predict that SaaS adoption will grow to 47% by the end of this year, and by 2010 it will reach at least 65% worldwide.

If Saugatuck is right, that means that SaaS adoption will double over the next few months, from 25% to 47%. This truly makes 2007 the year of SaaS.

The consultancy goes on to observe that integration with in-house software will likely require SOA, the report states. “SaaS is going to complicate and hybridize user IT and business operational environments faster, and to a greater degree, than most user and vendor executives understand at this point,” Saugatuck writes. “The vast majority of user IT departments will simply not have the resources to handle the influx of enterprise-level SaaS” expected to occur over the next seven years.

How complex can SaaS-in-house integration get? Chip Vanek, director of corporate and CRM applications for Magma Design Automation, recently led an ebizQ.net Webinar, discussing the integration challenges his company had to address as it moved to SaaS-based services. Magma, supplier of computer-aided design, relies on CRM func­tionality delivered as Soft­ware-as-a-Service (SaaS) from Salesforce. com to track orders and maintain customer satisfaction levels.

At Magma, SaaS-based appli­cations are highly integrated with onsite ERP applications to manage the compa­ny’s buy, sell, and make processes. ‘ SAP is our back- end system of record,’ Vanek explained. Vanek said that his company needed to do quite a bit of integration work to mesh data coming from the Salesforce.com system into the SAP system. ‘We have an issue where we need to take the information that we have in Salesforce and pull it back into our back-end system,’ he explained. For example, in the compa­ny’s ‘buy’ process, ‘we have hundreds of people around the world that are cre­ating purchase requisitions. We have to make sure that we have them properly approved. We needed a bi-directional synchronization between the two sys­tems.’

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Running an airline requires a lot of synchronization between a lot of systems, and if you're operating a fleet of 300 airplanes making 1,000 flights a day, you have to make sure everything is airtight. What is each flight costing in terms of fuel consumption and salaries? What repairs are needed? When is the next round of scheduled maintenance? What happens when flights are delayed due to weather?

Batch was okay in its day, but doesn't cut it anymore. To better stay on top of these matters, Scandinavian Airlines International (SAS) has embarked on a year-long project to move its operations from home-grown mainframe applications to three new distributed systems that provide real-time messaging. A new report in ComputerWorld states that the airline is employing SOA via an enterprise service bus (ESB) as a messaging backbone. The ESB will serve as an intermediate layer of middleware that lets the company map data from disparate systems, route messages, ensure that services are delivered in the correct order and enforce security rules.

Jonas Berggren, vice president of production systems at SAS Group, estimates that the migration project will lower IT maintenance costs by $250,000 per month after it goes live -- a potential savings of $3 million a year.

"Every time a plane takes off or lands, that event in the form of a message is sent to multiple systems, including internal systems that monitor maintenance, and to partner and supplier systems," Berggren said. In addition, the data is used by another internal system to calculate the costs of specific flights. Those messages will flow through the ESB and automatically update all of the systems using services in real time as opposed to the batch updating used by the airline up until now.

Retraining end users who have been using the mainframe applications over the past decade will the most challenging part of the migration at SAS, Berggren said.

Posted by joemckendrick in SOA  |  Permalink  | Comments (2)  | TrackBacks (0)