Microsoft Does Have a SOA Strategy

Microsoft Does Have a SOA Strategy

Redmond was conspicuously absent as the SOA Service-Oriented Architecture hype exploded -- turns out it had a plan after all.

August 2007 • by Ed Scannell and Chris Kanaracus

Microsoft has never been inclined to play by the rules. For the past 32 years, the company has maintained the cocky pose of its legendary founder, Bill Gates, aggressively challenging entrenched technology standards -- even some its own customer base wants to see flourish side by side with Windows.

Microsoft's ruthless campaign against open source software and, with somewhat less vengeance, its reluctance to join the Software as a Service (SaaS) movement are the latest examples. Only after years of bloody public jousting did Microsoft finally seek ways to peacefully coexist with the open source world through deals like the one signed with Novell Inc. last November. And it did acknowledge the market presence of SaaS when it introduced the Live versions of Windows and Office, both of which are still incubating.

SOA Takes the Stage
Enter Service-Oriented Architecture (SOA), which for several years has been developing into a transformative force in enterprise IT. SOA, as a concept, has been embraced by Microsoft's usual cadre of competitors, most notably IBM Corp. and Oracle Corp. It has made its way onto the radar screens of the more forward-thinking IT shops, and established standards groups are shaping the rules by which to play.

But true to character, Microsoft again appears to be crafting its own rules and vision. The company has so far declined to participate in certain key emerging industry standards relevant to SOA. It has a different perspective on what SOA is and a different approach for crystallizing its vision. Microsoft has even shown a certain reluctance toward using the term itself, choosing instead to talk about its "services-oriented" or "service-enabled" approach.

The more vocal critics claim Microsoft's approach to SOA not only goes against the technical grain of competitors, but may also not be in the best interests of customers. They believe the company's approach is too tied to pushing sales of its core desktop and server products, which are more expensive, complex and proprietary than alternative offerings.

"Microsoft is primarily concerned with its [own] business strategy. It wants to continue to produce these fantastic profits but that runs counter to what many IT shops are focused on, which is cost-reduction, simplification, consolidation and modernization," says Dana Gardner, principal analyst with Interarbor Solutions LLC in Gilford, N.H.

Gardner and other industry observers charge that Microsoft's business model too strictly requires users to buy into its bread-and-butter operating systems, applications, run-time environment and tools before they can start piecing together a customized SOA that best serves their needs.

But top Microsoft executives disagree with such assessments. They say all the basic building blocks of the company's services-oriented plan can be mixed and matched with a wide range of competing technologies, that the resulting SOA-enabled applications will offer the agility needed to flourish in the fast-paced Web 2.0 world, and that they can do so cost effectively compared to competitors.

"It was clear that if the services-oriented world was to coexist with the real world, we needed to move data efficiently around the organization in a way that was transport-agnostic. This is why we invested in Windows Communications Foundation [WCF]," says Steve Martin, director of product management for Microsoft's Connected Systems Division. WCF is Microsoft's Web services stack shipped as part of the .NET Framework 3.0.

Besides the ability to move data around easily, Microsoft is placing an emphasis on the agility of the SOA-enabled applications. The reason, according to Martin, is that most custom applications live between six and 15 years in an organization, while service-oriented applications live three to six months.

"This is what you're investing in when you take a services-oriented approach -- the ability to rapidly evolve an application because you need to change things in near-real time," Martin says.

'Good, Better and Best'
Microsoft is not selling a big, fat SOA stack, Martin argues. Instead, the company is taking its "traditional" technical approach to the SOA market -- one that is focused on empowering individuals, he says.

IT shops can simply use WCF to service-enable their existing systems, he says. Or they could go further and use Microsoft's best selling Visual Studio suite of tools to build new services. A third and optional step, he says, would be for users to then combine these assets with BizTalk Server, which allows them to wrap legacy technologies with the new class of services. Giving users and developers these options to start small and flexibly build capabilities as their business requires them is Microsoft's "good, better and best" approach to the SOA market.

"People should be able to fly at the altitude that is most appropriate for them," Martin says.

Another central technical element to Microsoft's services-oriented strategy is virtualization. David Greschler, director of virtualization strategy at Microsoft, says virtualizing applications may be the best way to SOA-enable many of Microsoft's best-selling applications.

"It's important in an SOA-enabled world that we think about how to move these applications into that world," he told Redmond in an interview after his keynote address at the SOAWorld 2007 show in late June. "One way to do that is to virtualize them. By tying those apps to policies, by en-abling them to be delivered in real time to whatever device needs them, we've taken the same characteristics that one would see with a Web app and made most any Windows app Web-enabled. It can be part of an SOA-like strategy."

But for all of Martin's talk about the company's ability to provide SOA a la carte, Microsoft is also taking some stabs at a market IBM and others have long ruled: the world of high-performance back-end megasystems that power verticals like the financial services industry.

In June, the company released .NET StockTrader, a trading application based on ASP.NET and WCF. Microsoft highlighted its ability to interoperate with IBM's WebSphere Trade 6.1 sample app and released benchmarking results that showed significant performance improvements over Trade 6.1.

Forrester Research Inc. analyst John Rymer says it's clear that Microsoft wants to show that it's a viable alternative to products such as WebSphere -- and not a supporting player. "Obviously, they're trying to sell it. The problem is IBM is seen as enterprise and they're not," he says.

Rymer says the .NET StockTrader benchmark tests were well-documented, but like any benchmarking, the results should not be swallowed whole. That said, Microsoft is now well-positioned to become a stronger player in enterprise systems, according to Rymer.

Microsoft is backing up its technical investments in this market by bringing on high-powered talent, and from its archrival no less. Earlier this year, it scooped up former IBM Fellow and Chief Architect Donald Ferguson, who's generally credited with turning WebSphere into the success it is today. While his role at Microsoft has not been made clear by the company, Ferguson -- someone long-steeped in the SOA tea -- figures to have a hand in shaping the company's services-oriented strategies in a way that could exploit any potential IBM weakness.

Fatal Flaws?
On the surface, then, Microsoft does seem to have a straightforward and fairly substantive SOA strategy, one Martin details in depth for Redmond (see "Microsoft and Service-Oriented Technology"). But industry observers stress that there are clear limits to it.

Forrester analyst Randy Heffner says that as a company, Microsoft's philosophy is to be "standards-based at the edge. But when you talk about standards that affect internally how things go, then Microsoft doesn't play in that ecosystem nearly as much."

An example of this is Microsoft's decision not to join a phalanx of other vendors -- including IBM -- in endorsing a pair of potentially key standards for SOA: the Service Component Architecture (SCA) and Service Data Object (SDO) specifications. Both are still in development under the watch of the OASIS standards body.

Such standards are too closely tied to rival technologies and platforms for Microsoft's taste, Heffner says: "That would be a hard pill to swallow. Microsoft doesn't want to do the tools that will help people use some other platforms."

Asked directly why Microsoft hasn't joined SCA and SDO, Martin somewhat deflects the question, saying, "SCA is a great endorsement of the work we have done on the Windows communications side. It tells us that others think the strategy of building a set of technologies that are transport payload-agnostic was the right way to go."

While Martin and his colleagues at Microsoft may have crafted an array of SOA-enabling technologies, it's an open question how many enterprise customers are prepared to immediately embrace them. Eric Manley, a consultant who's working on SOA-related initiatives for a Fortune 500 company, says his company is still preoccupied with purely human concerns.

"We're getting there. We've got a lot of point-to-point implementations. I think the bigger challenge is getting over more of the governance, who decides what," he says.

Manley says his company currently has groups working to determine exactly what a runtime environment should look like. Once that's determined, he can start to define the minimal requirements in order to get into that environment, and what the service-level agreements should be.

"Each project is kind of funded from its own money, so [different departments] are very apprehensive about building something that somebody else could consume. You start out with the deck stacked against you," he says.

Manley says that so far, there are only scattered instances where SOA-related efforts have resulted in reusable services.

Like many IT shops, Manley's company is several years behind Microsoft in terms of the underlying technology being used. He says only now is his company moving from the 1.1 version of the .NET Framework to 2.0. He adds that his current environment also includes a healthy amount of IBM's WebSphere technology, although the client machines are predominantly Windows boxes. His biggest challenge, however, is not technology-related but centers more on organizational and social changes.

"Whether it's .NET, Java, Oracle, SAP, who cares? It's working through the governance and who pays for and decides what that is-really, to me in my world [that's] the real challenge," he says.

Some believe the inherent flexibility of SOA-based software, in addition to the perceived greater financial incentive to diversify to multiple platforms, makes more sense for companies like IBM and Oracle than for Microsoft.

"With SOA [Oracle and SAP] can take existing services and components from one set of business apps over to a ripe vertical market and reuse 70 or 80 percent of them and then tailor the remaining 20 or 30 percent to that specific industry. Suddenly, SOA makes a whole lot of sense for ISVs," Gardner says.

Survival of the Fittest
Now that Microsoft's services-oriented strategy is finally crystallizing, there are two ways to think about the future: Is Redmond simply too late to become a major SOA player? Or will the company emerge fairly unscathed from the sector's initial growing pains, poised to become a viable alternative?

Heffner, for one, is not betting his entire bankroll. "They will survive," he says. "Will they get as much penetration in the enterprise as they want? ... I don't [see them becoming] Java killers any more than they've been in the past."

But it may not be necessary to for Microsoft to go lion hunting when it can go trawling for fish instead. Microsoft has a history of going after high-volume, low margin markets, and with SOA still a high-end, high-margin business, the company may simply be sitting and waiting for the commoditized market to materialize with the arrival of low-cost SOA-based tools and platforms.
But whatever the hunting weapon Microsoft chooses for this expedition, there's a good chance the route it takes won't be on a map.

Ed Scannell is the editor of Redmond magazine. Chris Kanaracus is the news editor of Redmond Developer News magazine. You can contact Ed Scannell about "Microsoft Does Have a SOA Strategy" at editor@redmondmag.com.

Governance at core of Software AG SOA strategy

Governance at core of Software AG SOA strategy By Rich Seeley

Governance is at the heart of Software AG's strategy to become a billion Euro service-oriented architecture (SOA) software vendor by 2011.

The plan unveiled by Software AG this week blends governance software it developed with Fujitsu Ltd., with the ESB and BPM technology it acquired with the its purchase of webMethods Inc. in April, plus policy products webMethods got when it bought Infravio Inc. last fall.

Explaining this complex fusion at a Webinar for analysts and journalists on Monday, Ivo Totev, chief marketing officer for Software AG, said the prominence of governance in its future service-oriented architecture SOA software offerings was based on experience with customers.

"We have recognized from previous projects that customers do not look any more just for infrastructure," he said. "They are looking for ways to structure their approach to projects for technologies that improve processes. Service-oriented architecture SOA governance becomes very important when you think about what is the right structure. What are the responsibilities of the individuals and teams? How do they work together? How do they communicate? All of that is very much at the core of our offering, not only service-oriented architecture SOA tools, but very much something that is built into all the products."

Basing its governance offering on the joint technology Software AG developed with Fujitsu under the CentraSite brand will provide a governance suite that Totev characterized as "independent" and "neutral." A new edition of the CentraSite product integrating Infravio technology is scheduled to be released Sept. 1.

"We have chosen to carry on the CentraSite brand for the joint service-oriented architecture SOA governance platform," Totev said. "The reason being that we have many customers who have invested heavily in heterogeneous environments -- BEA, SAP, Tibco, Oracle -- and they look for us as a neutral provider for SOA governance solutions. This is why we have chosen to have an independent brand here, which demonstrates our neutrality."

He said the integration was made easy because both the Software AG and Fujitsu technology and the Infravio product were based on the Java API for XML Registries (JAXR) standard.

Offering a brief history of the governance suite, he said, "Software AG together with Fujitsu has been developing an service-oriented architecture SOA governance platform called CentraSite. This platform was available in two editions the enterprise fully featured edition and community edition which was available to customers for free. At the very same time webMethods had acquired Infravio, another strong SOA governance offering. What we will do is combine the best of both worlds and have a very good service registry, a very powerful policy repository and the capabilities to manage service-oriented architecture SOA artifacts and metadata will combine all of that into one platform. The beauty of standards is that both Infravio and CentraSite are based on the JAXR standard. So exchange of metadata becomes very, very easy."

Around the CentraSite governance core, all the other service-oriented architecture SOA related products including the enterprise service bus (ESB) and business process management (BPM) products will be marketed under the webMethods brand. Totev acknowledged that the acquisition of webMethods was as much about market presence as technology. To achieve its ambitious goal of becoming a major global service-oriented architecture SOA vendor, Software AG, based in Germany and known largely as a European company, needed the webMethods customer-base and name recognition in the United States, he said.

Following Monday's Webinar, Jason Bloomberg, senior analyst with ZapThink LLC., was guardedly optimistic about the company's chances of success after listening to Totev's presentation. The analyst was impressed with Software AG's emphasis on governance.

"They lead with service-oriented architecture SOA governance, which is an important priority for them to have," he said. "Another key strength is that their ESB vision focuses on a mediation version and an orchestration version, two capabilities that are more critical to SOA infrastructure than simple integration is. Also, their business process tooling is unsurprisingly quite strong, as both companies had good, service-oriented architecture SOA-capable products in this space going into the merger."

As for the German-based company's ability to sell itself in the American market, Bloomberg sees that as being more problematic although not undoable if Software AG can successful blend its culture with the Virginia-based webMethods and California-based Infravio.

"Perhaps their greatest challenge, although it's too early to say it's a weakness, is pulling the cultures together so that they can be strong in the US market while remaining strong in Europe and elsewhere," Bloomberg said. "In the past they have been 'too German' in many ways to do well in the US, so we'll have to see if the new webMethods blood can tone this down."

Mercury for SOA

Mercury for SOA Service Oriented Architecture

Industry experts say service-oriented architecture (SOA) will soon be the dominant enterprise IT architecture. Why? SOA has the power to transform IT from a bottleneck and cost center into a key source of business flexibility and competitive advantage.

But when implemented incorrectly, SOA service-oriented architecture can disrupt the business. Instead of becoming more agile, your business could become more fragile. Recognizing this, forward-thinking IT leaders are turning to Mercury business technology optimization (BTO).

With BTO and Mercury’s Systinet offerings, you can mitigate risks and deploy high-quality SOA services that deliver measurable business outcomes. And you can start wherever you need, based on the area of greatest risk in your service-oriented architecture SOA initiative.

Mercury is the only company that delivers an integrated solution for managing service-oriented architecture SOA across the lifecycle, from demand through production:

SOA Governance - provides the visibility you need to create trust and to gain complete control over your SOA environment.
SOA Quality - helps you to validate the functionality and performance of your services as well as manage your testing to mitigate the risk of delivering services.
SOA Management - enables you to manage end-user experiences, service levels, and ongoing changes to ensure SOA delivers business results.

Grid and Your SOA Strategy

Grid and Your SOA Strategy by Jim Byrd

Virtualizing grid infrastructure components to provide management and analysis functionality.

Companies today face increasing IT infrastructure demands, often without concomitant increases in budget or resources. At the same time, critical client applications are integral to continuous, high-quality service. Increasing application performance and resiliency can help bolster a company’s position vis-à-vis its competitors, and keep pace with increasing or volatile service demands.

A key concept gaining traction with IT managers to affect these goals is a Service-Oriented Architecture (SOA) strategy for enterprise systems. SOA is a form of distributed computing that is both application-centric and demand-driven, focused on facilitating a key process. Service-Oriented Architecture SOA achieves this by virtualizing application components and then linking and leveraging these heterogeneous resources across the enterprise to provide optimal client service. By nature, Service-Oriented Architecture SOAs are loosely-coupled, software modules independent of implementation and infrastructure details. This allows developers the freedom to write and edit services without affecting the underlying implementation. The ease of manipulating and modifying services, while leveraging an organization’s existing resources (including infrastructure, IT staff, languages, platforms and databases), makes Service-Oriented Architecture SOA a viable strategy for many companies that already have sunk high costs in existing IT investments.

Grid Computing and Service-Oriented Architecture SOA

Grid computing is in many ways a natural complement to a SOA implementation, since many of the core requirements for a Service-Oriented Architecture SOA are naturally matched by the strengths of grid computing. Clearly, a successful Service-Oriented Architecture SOA implementation requires an accompanying service execution platform to serve as a “fabric” for virtualizing components and to provide management and analysis functionality. Grid-computing infrastructure enables organizations to quickly realize the benefits of a Service-Oriented Architecture SOA without having to undergo costly application rewrites or re-architecture. Besides allowing for global management and execution, a good service platform will also have monitor and alert functions, service level agreement (SLA) tracking and accounting capabilities, easy-to-use interfaces and message exchange protocols and dynamic provisioning. Out of the box solutions are readily available, simplifying implementation and facilitating coordination and interoperability. By using a grid-computing service platform with the above characteristics and capabilities, companies immediately observe the following benefits and help accelerate transition towards SOA:

- Application Performance, with up to a 50-times increase in application response time and throughput

- Resilience and Reliability, as failure rates can drop by 90 percent or more with guaranteed task execution and built-in contingency mechanisms to ensure against failure or system error

- Flexibility and API independence, with vendor-neutral support for a wide variety of clients including leading standards Java, .NET, SOAP, C++ and binary executables. Grid-based environments can be incremental and reversible, able to accommodate newer interfaces based on WSDL, SOAP, XML and BEPL as well as legacy applications

- Service-Oriented Control, allowing for global management and administrative control of operational parameters such as policy-driven service, resource assignment and workload distribution rules

- Dynamic Provisioning, optimally utilizing heterogeneous resources across the enterprise by dynamically and adaptively balancing loads and provisioning tasks within milliseconds

- Rapid Development and Deployment, simplifying and streamlining the production process through standards-based infrastructure that manages QoS and enforces service access and execution policies

- Usage-Based Accounting, with centralized administration tools that allow managers to establish variable cost accounting systems

- TCO Reduction, improving the bottom line through creating a more cost-efficient, productive, and reliable IT system, without additional investments in infrastructure or human resources

At the service level, grid computing can provide additional value-add through parallel execution, high concurrency of task processing, redundant task submission, and distributed caching

Benefits of Grid-Enabled SOA Service-Oriented Architecture

The benefits of a SOA strategy are almost immediately evident, especially when compared to the model most organizations use today—individual silos dedicated to each client application. This silo approach houses and deploys applications on dedicated IT systems, limiting capacity and availability, and often introducing significant latency and execution failure during periods of high compute demand. Virtualization of such systems through a Service-Oriented Architecture SOA strategy allows an organization to significantly reduce risk and improve performance and flexibility by abstracting, distributing and managing distributed resource layers. Additionally, because SOA is demand-driven, resources are used on an “as needed, when needed” basis, and tasks are appropriately assigned based on specified parameters. Virtualization allows a Service-Oriented Architecture SOA to meet fluctuating demand, increasing performance and reliability, while QoS parameters such as security, scalability and support are built-in.

Summary

Grid computing is highly complementary to the Service-Oriented Architecture SOA model. As a design concept, SOA can provide substantial gains in business performance while requiring no additional investments in infrastructure or human resources. A comprehensive grid service platform can act as an appropriate way to achieve the goals of a Service-Oriented Architecture SOA strategy by 1) virtualizing the service execution environment; 2) globally and automatically managing service execution; and 3) virtualizing the underlying system and data-level resources. These benefits confer exponential increases in scale, price and performance gains, allowing companies to more effectively meet the challenges of a changing global marketplace.

SAP outlines its SOA strategy

SAP outlines its SOA Service Oriented Architecture Strategy - Seeking smoother, faster app upgrades... by Martin LaMonica

SAP on Tuesday detailed product developments meant to smooth the process of upgrading to the latest generation of its modular business applications.

Shai Agassi, president of SAP's product and technology group, outlined the software maker's plans to technical executives and developers at its TechEd conference in Las Vegas.

He announced SAP Discovery System, a collection of software components meant as a "starting point" for a services-oriented architecture (SOA), a system design meant to make SAP's applications more modular and flexible.

In addition, he said, the company will shift its product release method to make upgrades faster.

Rather than release large-scale updates of closely interlinked components, SAP will release more narrowly defined packages every quarter or two, Agassi said.

These packages will address a certain aspect of SAP applications, such as human resources or travel management, and customers will have the choice to install them or not.

All the packages will work with MySAP ERP 2005, the core set of automated business processes in SAP that the company plans to leave in place for five years.

Agassi said: "You will have a stable core you can build on and continue to enhance. It drives the ability to flexibly innovate at your pace. When you get services from us, you can decide how to use them in ways that we didn't think about."

SAP is trying to encourage customers to upgrade to the most recent editions of its applications suite, which has been rebuilt around an services-oriented architecture SOA. Once customers adopt this "business process platform", they will be able to more quickly develop innovative software, Agassi said.

SAP Discovery System is meant to be a relatively simple way for customers to start adopting SAP's latest service-oriented suite of applications.

It includes the NetWeaver infrastructure software, Java-based tools for creating services, and a set of sample applications. SAP released a preview version of the package on Tuesday, Agassi said.

Also at the event, the company's executives gave updates on products under development, including a search engine called SAP Enterprise Search.

A preview download is now available and the software will be available next year. It has been built so it can be embedded in different applications, such as human resources apps or in a front-end user interface screen, Agassi said.

He added that the next version of SAP's portal, code-named Project Muse, will use Ajax-style development to improve the navigation of SAP application's screens.

Agassi also announced that a group of SAP customers and partners have formed a community of experts to share technical information and techniques pertaining to the consumer products industry.

Agassi said SAP, through its partnership programme, expects to create expert communities in all 26 industries it supports in its applications.

BEA's SOA Strategy

BEA's SOA Strategy by Eric Roch (Chief Technologist)

Many analysts believe that BEA Systems have turned the company around with their SOA strategy. Both Wall Street and IT analysts like what they have seen. Forrester recently ranked BEA as the top ESB product and their stock doubled from a low of $7 in April of 2005 to $14 in April of 2006.

The following is an article and discussion with BEA's CEO and co-founder Alfred Chuang regarding their service oriented architecture SOA strategy.

BEA's big fight back - Two years ago BEA looked to be in serious trouble as a number of top executives abandoned ship, while the firm appeared to have lost focus. Then began the fight back and a big push in SOA…

So how has BEA fought back? When CBR met up with Chuang last month he put a lot of the company's success down to the relatively recent launch of its AquaLogic suite of service oriented architecture (SOA) products and services. "BEA is ideally positioned to take advantage of the momentum behind SOA-led projects," says Chuang. "service oriented architecture SOA is going to be the dominant architecture for the next generation of enterprise IT systems. AquaLogic and new service offerings have opened doors for us into new customers and projects."

One of BEA's big arguments with its service oriented architecture SOA suite is that, unlike most of the competition, it is "built from the ground up to manage service oriented architecture SOAs".

BEA 'Rationalizes' SOA Strategy

BEA 'Rationalizes' SOA Strategy By Jim Wagner

WebLogic customers now have a roadmap to take their applications and portals onto a services-oriented architecture (SOA) (define) model, with the launch of BEA Systems (Quote) Enterprise Portal Rationalization (ERP) and Value Assessment Monday.

The initiative is aimed at what BEA officials say is a common problem in many of today's companies: a "Web sprawl" of applications and portals by software vendors that leaves blind-spots in the IT manager's view of the enterprise network. This leads to poor end-user adoption rates in the enterprise, BEA said.

Nils Gilman, director of product marketing at the San Jose, Calif.-based software company, said BEA recognizes most companies don't subscribe to one over-arching software platform strategy; many times, it's a grab bag of software products by different vendors.

"What we're trying to do is provide a basic framework that allows you to take your existing resources and have them talk to other resources in a way that's historically been difficult to do," he told internetnews.com.

To accomplish this goal, BEA is relying on its J2EE-based (define) software in the WebLogic suite to "wrap and re-use" existing software packages and portal.

For example, with disparate portal applications, a new Java standard -- Java Specification Request 168 (JSR-168) -- provides a common interface to allow them to speak with each other. Rather than "rip and replace" it, as BEA officials say, users can put a standards-based face on the application and bring it fully onto the WebLogic platform.

But even wrap and re-use has its challenges, which makes the BEA Business Value Assessment, a consulting component of WebLogic to help bring companies in-line with BEA vision of a services-oriented architecture SOA environment, crucial.

BEA consultants will visit a customer site to help then identify root causes for inefficiencies between disparate applications and portals. Then they will provide a best-practices solution and deliver the expertise to bring them together.

When asked if this services/software combination bears a strong resemblance to IBM's (Quote) own services-oriented architecture SOA platform via Rational, Gilman was quick to point out the differences.

"For IBM, they really have a services strategy; BEA has a software strategy around this," he said. "[With] IBM, their answer to Web sprawl is to walk into a customer site and say, 'listen, sign over your entire IT department for life, the journey is the endpoint.' BEA has a very different philosophy, we believe software itself can get you to a more rational future, you're going to be able to take your existing assets and reuse them using infrastructure software."

He went on to say that with BEA, you're not saddled with a billion-dollar, five-year contract like you would be with IBM; once a customer works with BEA's services team to streamline a business network, he or she is done -- and at a fraction of the cost.

BEA is working with several other services vendors to make their Web sprawl initiative and services components work. On Monday, the company announced marketing and sales agreements with consulting firms Accenture (Quote), Hewlett-Packard (Quote) Services and Enterpulse.

It's Time to Actively Manage Your SOA

It's Time to Actively Manage Your SOA Service Oriented Architecture by Eric A. Marks, AgilePath Corp.

April 19, 2004 (Computerworld) If you were the CIO or chief architect at a company and I told you that you are already running multiple Web services, how would you react? Pleasantly surprised? Shocked? Would you be upset?

Many firms today are just now considering whether to begin exploring Web services. They, like many others, are early in their planning for Web services, and yet in some cases they are farther down the road than they realized.

That's because many of their current software vendors have begun building Web services into their products, and these products are being installed in IT architectures without explicit knowledge and understanding of the implications by IT management. On top of this, many developers have been quietly experimenting with Web services under the radar, which means there may be many Web services already running in your business.

The good news is that these firms are adopting Web services and service-oriented architectures (SOA). The bad news is that their service-oriented architectures SOA is being defined by the software vendors through their software products as opposed to being based on a business perspective that assures that business objectives are supported with the service-oriented architectures SOA and Web services strategy.

Furthermore, they may have a proliferation of Web services running without any IT oversight or management, which can lead to an ad hoc service-oriented architectures SOA with poor interoperability and low services reuse potential. I call this "passive SOA management."

While many firms are very early in their adoption of Web services and SOA, I strongly advocate that these firms quickly develop a service-oriented architectures SOA strategy and governance model that helps them actively manage their service-oriented architectures SOA migration to support the corporation's business goals, on their terms, and independent of the vendor community. This approach will help ensure the appropriate business fit and maximum degrees of freedom to implement service-oriented architectures SOA to support the company's business and financial goals as well as IT strategy.

Today, the central issue is not whether to begin implementing SOA, but when to begin actively managing for service-oriented architectures SOA. While firms can watch the development of the Web services standards and service-oriented architectures SOAs from afar, the reality is that the firm already has some Web services operating somewhere in the organization, and the incumbent software vendors are already shipping Web services capabilities in their enterprise software applications. In other words, it's time to begin actively planning to operate and manage an SOA strategy on your terms, not on your vendors' terms.

Consider the following scenario. Company A is a financial services firm with a heterogeneous IT architecture characterized by a mixture of J2EE and Microsoft .Net technologies. It has J2EE application servers to support many of its enterprise applications and e-commerce initiatives. In addition, due to the mixture of legacy applications and stovepiped functionality in various business units, this firm has been deploying a popular enterprise application integration (EAI) platform. You can see that several classes of enterprise software applications would have been purchased in order to implement these architectural choices based on business needs.

However, depending on the vendors and their technology applications, they may support Web services and service-oriented architectures SOA to varying degrees based on how they align with the standards bodies, other vendors and architectural choices, as well as how they implement specific Web services standards in their products. Most J2EE application servers provide basic support for XML, Simple Object Access Protocol (SOAP), and Web Services Description Language-based services description. Most J2EE development environments, or integrated development environments (IDE), allow development of Web services within their environments to be deployed on the application server.

Consider the EAI strategy for Company A. Most EAI products today are rapidly adding Web services support into their offerings through acquisitions as well as through new features and functions. So, whether intended or not, the EAI strategy will implement a Web services stack that is integration-centric. Will the EAI SOAP stack be compatible with the application server SOAP stack? Will they implement SOAP messaging in a compatible fashion, e.g., document messaging vs. remote procedure call-style messaging? Do both software platforms support the WS-I Basic Profile? Do they implement the standards consistently to ensure interoperability?
And on the .Net side of their architecture, where much of the Web services support is built into the Microsoft applications, how will the various tools converge into a unified enterprise service-oriented architectures SOA based on a common SOA strategy, governance model and standards template?

The answer is that they won't unless CIOs begin to actively plan and manage their service-oriented architectures SOA now, ahead of and independent of their incumbent software vendors, and in time to achieve visibility of the services that may already be running within their enterprises.

This is not an attack on the software and platform vendors. The message here is that firms must have an service-oriented architectures SOA strategy that explicitly maps to business objectives, supports the IT strategy and goals, and can be implemented to drive real business initiatives today. Once that has been accomplished, a CIO can begin determining how current software vendors fit into their SOA, as well as how potential new vendors may fit into the service-oriented architectures SOA.

An service-oriented architectures SOA and Web services strategy must be developed based on the firm's business and IT goals, then mapped to the firm's current IT and application architecture. Then, based on how the incumbent vendors support the firm's SOA, they may or may not be part of the SOA for the long term.

Those are choices that must be made with the big picture of service-oriented architectures SOA and Web services in mind. And naturally, while most software firms will support Web services soon if they don't already, the question is, How well will they support your firm's SOA and Web services strategy as a unifying architecture for all of your technologies and applications based on clear and explicit support for the business?

Consider the following types of software offerings you may have in your IT architecture. Do a quick analysis from the vendors' Web sites on if and how they support Web services and SOA, or when they will support them.

Microsoft .Net framework
J2EE architecture
Application servers
Web servers
EAI
ERP architectures
CRM software
Messaging backbone
Systems management tools
IDE/development tools
Identity management/security software
Asset reuse software

You'll find a lot of information quickly from this quick assessment, but what you won't find is how SOA and Web services will support your business goals and IT objectives. That's why your service-oriented architectures SOA strategy must be developed independent of your vendor partners initially, and then you should open it up for discussion with your core partners to begin building your service-oriented architectures SOA.

IT executives must begin actively managing their service-oriented architectures SOA and Web services strategies now, based on their business goals and objectives and independent of their vendor partners. This will lead to the best overall service-oriented architectures SOA solution for your business.

Tactics, not strategy, drive SOA adoption

Tactics, not strategy, drive SOA adoption by Phil Wainewright

Few have one, but every enterprise seems to want one. Service Oriented Architecture (SOA) is IT's hot new strategy.

Adoption of web services is providing the impetus. But web services vendors are the first to admit that few implementations take place in the context of an Service Oriented Architecture SOA strategy.

"Many of the uses of web services today are fairly unsophisticated, and yet they're bringing a lot of value," says James Phillips, senior vice-president of products and marketing at web services software vendor Actional. "What we're seeing is just tactical utilization of the technology — a more pragmatic approach to get the things done that need to get done."

In a fully-fledged service oriented architecture, every software component makes its functionality available on demand, ready to be combined and rearranged with other participants in any number of different ways. The vast majority of today's web services deployments are but a pale reflection of this all-embracing vision, typically consisting of a simple link from one application to another.

"Inevitably a lot of the early web services projects are very much around point-to-point integrations," says John McGuire, vice-president of products at Cape Clear Software. "What they're getting is probably not ideal in terms of a service oriented architecture, but it's probably what they're trying to move towards."

Even those small first steps are providing evidence of the interoperability and flexibility claimed for Service Oriented Architecture SOA, he adds. "The reason customers talk about service oriented architectures is the early success of the point-to-point projects. They've shown that this kind of thing can work."

Service-oriented veneer
In part, the excitement stems from the realization that it doesn't take much to add a service-oriented veneer to existing infrastructure. Web services adapters now exist for the majority of legacy systems and enterprise application suites, while the J2EE-based web servers that run many heavy-duty e-business applications are even easier to convert for web services.

Once the functional logic has been exposed as a service, it remains available to other applications. "You only have to do the packaging as services once," explains Ishmael Ghalimi, co-founder and chief strategy officer of BPM vendor Intalio. "Everything appears as XML ... All your backend services are available as reusable services."

The unifying data model of XML is the key foundation. Irrespective of the original source or how it's being accessed, once the resource has been defined as a service it can be reused and combined in different ways. Provided the service definitions are standardized and consistent — which the use of web services standards such as SOAP and WSDL helps to ensure — then the promise of Service Oriented Architecture SOA can start to be realized.

Vendors are keen to point out that this doesn't require a huge development effort or a new layer of expensive middleware technology. Intalio maintains that in most cases its business process management suite will plug in directly on top of whatever's already in place. "That first step can be fairly simple," says Ghalimi. "We have the ability to integrate all the services and wrap them with a services interface." That allowed Intalio's customer BAe, the British aerospace and defense contractor, to skip a layer of EAI software when it automated a complex order management process, he says.

Becoming unmanageable
The ease with which a services infrastructure can come into being has left some customers scrambling to add a management layer to keep tabs on an expanding pool of services. "What customers tend to end up with is environments that are unmanageable," says Actional's Phillips, who points out that the ability to discover and use services on demand often puts unexpected stresses on the underlying systems.

That is the point at which the service oriented infrastructure has to become a properly managed architecture — when the SO gains its A. "The first manifestation of an SOA is usually the appearance of UDDI or something similar," says Ian Bruce, spokesman for web services vendor Systinet. "From having tactically deployed web services, a need grows for advertising and discovering these services — which also serves management's need for control and to promote reuse."

Some enterprises are not prepared to wait. A recent survey by specialist analyst firm CBDI found that 70% of its subscribers are already committed to using or adopting SOA. "Many CBDI subscribers are pursuing an Service Oriented Architecture SOA strategy without yet adopting web services," says principal analyst Lawrence Wilkes. "Service Oriented Architecture SOA is more about good design and architecture than it is technology."

But although web services is not a prerequisite, it makes the job a lot easier, he explains: "Web services adds the icing to the Service Oriented Architecture SOA cake by providing a better interface technology in which to make the services available. Besides platform independence it provides a richer specification, and is going on to provide a more complete set of protocols — for security, transactions, orchestration, etc."

Think big, start small
The middle way is to pursue both simultaneously. Vinod Khosla, general partner at leading VC firm Kleiner Perkins Caufield and Byers, advises rolling out web services within the context of an Service Oriented Architecture SOA strategy, but not as a single, all-embracing project: "I just don't think one can renovate the whole company. So the way to do it is in short 90 day projects that drive towards the target of an SOA."

The key, he says, is to "think big" in terms of the overall Service Oriented Architecture SOA strategy, but "start small" with a rapid succession of short projects that each achieve a defined objective. "It's much more guerilla warfare than a big war," he says. "Start doing it selectively and get to harder and harder things later."

Web services software vendor Systinet has its share of customers who discover a need for an SOA long after embarking on service-based implementations, says Gregg Bjork, senior vice president of products and services. "We also have those who have an effort in place to build an SOA as quickly as they can. But that doesn't obviate their ability to do tactical implementations. They can do both." For example, the company is working with the architecture group of a financial services customer to develop an Service Oriented Architecture SOA, at the same time as implementing a smaller departmental project within the organization.

Initiating an Service Oriented Architecture SOA strategy as early as possible seems to make sense. According to Intalio's Ghalimi, it can also make it easier to sell web services adoption within the enterprise.

"The ROI for web services is not clear," he says. But put it in the context of a service oriented architecture, and it becomes a foundation to enable more agile process automation: "You're selling continuous process improvement, and XML and Service Oriented Architecture SOA becomes just another technical detail."

Nor should an Service Oriented Architecture SOA strategy attempt to put a brake on web services adoption — just like earlier grassroots technology trends, it's unstoppable, insists Actional's Phillips. "This adoption's going to occur in an ad hoc manner. It's going to get into the organization regardless — like the PC got into the organization."

How do I know whether I should adopt SOA as a strategy?

How do I know whether I should adopt SOA as a strategy?

Because it is an architectural strategy, Service Oriented Architecture SOA involves much more than merely building software. Creating an architecture based on a portfolio of services asks that CIOs make a compelling case for enterprise architecture, a centralized development methodology and a centralized staff of project managers, architects and developers. It also requires a willing CEO and executive staff to pave the way for IT to dive in to the core business processes of the company. Understanding those processes and getting buy-in on enterprise sharing are the keystones of Service Oriented Architecture SOA-based business transformation.
Governance is critical. For services to be reused across the company, there must be a single, centralized software development methodology so that different areas of the business don't build the same service in different ways or use linkages that are incompatible. There must be a centralized warehouse, or repository, so that developers will know where to look for services—and so IT will know who is using them. The services must be well documented so that developers will know what they are for, how to link to them and the rules for using them. (For example, some companies charge fees to use the services and create performance agreements to make sure the services work well and don't put too much load on the corporate network.)

Most companies that have progressed along the path to Service Oriented Architecture SOA have created a centralized architecture group to choose processes that will be service enabled and to consult with different areas of the company to build the specific services. The centralized group also creates a convenient mechanism for governance. If all service requests have to go through the architecture group, the service development methodologies, projects and performance agreements can be more easily managed.

The companies that have had the most success with Service Oriented Architecture SOA so far are those that always have success with technology: big companies with big IT budgets whose business is technology-based (think telecom and financial services). They also tend to have supportive, technologically sophisticated business leaders. For companies without these advantages, SOA may not be the panacea it’s being made out to be.

For smaller companies, for companies that have made big bets on integrated application suites and for companies that already have solid application integration strategies in place, SOA isn’t a "when," it’s an "if." CIOs need to pursue an Service Oriented Architecture SOA strategy carefully because the service development and architecture planning pieces of SOA are distinct but not independent—they need to be considered and executed in parallel. Services built in isolation, without taking into account the architectural and business goals of the company, may have little potential for reuse (one of Service Oriented Architecture SOA’s most important benefits) or may fail outright.

Source: http://www.cio.com