What are the challenges associated with SOA?

What are the challenges associated with SOA?

Service Oriented Architecture SOA confers obvious business benefits associated with integration and the creation of new services. However, insufficient attention to governance—the management and monitoring of services, their performance and reliability, and especially their security—can cause inefficiencies and disrupt business processes and the end users they support.

As business needs evolve, it is critical to have policies in place that help determine how to prioritize new business processes and services under consideration for implementation, who will be responsible for designing those processes, how they should be implemented, and how the success of the new implementations will be measured. This is especially important given the inherent cross-functional nature of Service Oriented Architecture SOA solutions.

Reuse of services, once touted as a primary Service Oriented Architecture SOA advantage, is really a byproduct of the approach rather than the goal itself. Reuse is also proving to be more challenging than expected. An existing service may not provide exactly what a different business process requires and so may call for additional work. And designing a service so that it can be reused in the future requires accurately predicting what future needs will be, something notoriously difficult to do.

What are the benefits of SOA?

What are the benefits of Service Oriented Architecture SOA?

Service-oriented architecture is, first and foremost, a means of attaining greater business agility from existing IT investments. Service Oriented Architecture SOA-based solutions connect systems and thereby automate previously manual information-transfer processes whether the goal is to develop new applications; to connect systems, workgroups, or geographically distributed subsidiaries; or to collaborate with trading partners. At the same time, Service Oriented Architecture SOA solutions build in the essential services required to ensure that the appropriate resources are accessed by the appropriate users.

Service Oriented Architecture SOA benefits accrue for the organization at two different levels, that of the IT organization and that of the business user; in the end, all benefits add up to a dramatic increase in agility and productivity.

From the IT department’s point of view, Service Oriented Architecture SOA-based integration simplifies management of distributed resources across multiple platforms, requires less hardware, is more reliable, is standards-based, and is less costly.

From the business point of view, Service Oriented Architecture SOA enables development of a new generation of dynamic applications addressing a number of top-level business concerns that are central to growth and competitiveness. Service Oriented Architecture SOA solutions promote:

• Stronger connections with customers and suppliers. By making dynamic applications and business services available to external customers and suppliers, not only is richer collaboration possible, but also customer/partner satisfaction is increased. Service Oriented Architecture SOA unlocks critical supply and demand chain processes—such as outsourcing of specific business tasks—from the constraints of underlying IT architectures, thereby enabling better alignment of processes with organizational strategy.

• Enhanced business decision making. By aggregating access to business services and information into a set of dynamic, composite business applications, decision makers gain more accurate and more comprehensive information. They also gain the flexibility to access that information in the form and presentation factor (Web, rich client, mobile device) that meets their needs.

• Greater employee productivity. By providing streamlined access to systems and information and enabling business process improvement, businesses can drive greater employee productivity. Employees can focus their energies on addressing the important, value-added processes and on collaborative, semi-structured activities, rather than having to conform to the limitations and restrictions of the underlying IT systems.

Reaping the Big Business Benefits of SOA

Reaping the Big Business Benefits of Service Oriented Architecture SOA By Christopher Koch

July 02, 2007 — CIO — In an exclusive interview with CIO, Andy Baer, CIO of Comcast, talks with Christopher Koch about maximizing the benefits of service-oriented architecture (SOA), including reusing assets and cutting time to market. His expertise stems from developing the internal IT strategy that aligns technology to meet overall business needs and objectives, including oversight of the company's customer care, billing and ordering systems; data centers; desktops; internal telephony; and other corporate systems. He also oversees the integration of the IT organizations in former Time Warner and Adelphia cable systems recently acquired by Comcast.

Christopher Koch, CIO: What do you see as the primary business reason for doing an SOA?

Andy Baer: What you're really getting out of service-oriented architecture SOA are a couple of really big business benefits. You're getting reuse of a lot of the assets which you're spending money to develop. So you're getting much more value out of the dollar that you're investing in technology because you're able to use things more easily. That's number one.

Second, you're getting quicker time to market. Because you're able to assemble components more easily, you can extend those components more easily so that as the business changes, you're able to react more rapidly to those changes in the business.

I can give you some specific examples here at Comcast. For example, we have two billing systems-60 percent of customers are billed on one and 40 percent are on the other-mostly as a result of our acquisition of AT&T Broadband. We had applications that needed access to the billing system; developers had to write the same APIs [Application Programming Interfaces] twice to access each of the billing systems.

One of the first things we did was to create what we call a billing services mediation layer. Now the developers write the APIs once, to the service layer, rather than to each billing system. That saves money, but it also gives my staff the opportunity to add functionality into the Web services layer themselves without having to go to my billing vendors, which is a lot more cost-effective and a lot more timely.

And, if at some point in time I need to change anything with my back-end billing systems, I can do it without having to change the other applications that link to it because they are connected to the service layer rather than directly to the billing systems.

How do you distinguish between SOA and enterprise architecture?

I don't believe that service-oriented architecture SOA is enterprise architecture. SOA is an enabling technology, but it's not enterprise architecture. You need to have a vision of your business and describe your business in an enterprise architecture, which can be implemented by a Web services SOA service-oriented architecture or not. I think service-oriented architecture SOA is an enabling technology for that enterprise architecture, but it isn't by itself enterprise architecture. Enterprise architecture is required regardless of whether you implement that by SOA or not.

Source: http://www.cio.com

What are the advantages of SOA?

What are the advantages of SOA?

First, put the benefits of Service Oriented Architecture SOA in perspective. SOA is a scythe that slices through complexity and redundancy. If your company is not large or complex—i.e., more than two primary systems that require some level of integration—it's not likely that SOA will provide much benefit. Lost in all the hype about Service Oriented Architecture SOA today is the fact that the development methodology itself brings no real benefit—it's the effects that it has on a complex, redundant infrastructure that bring the rewards. Architects say there is more work involved in creating a good service-oriented application than there is in doing traditional application integration. (Surveys show consistently that Service Oriented Architecture SOA is being used for traditional application integration at most companies.) So there is actually an extra cost being generated by Service Oriented Architecture SOA development up front. For there to be a benefit from that work, therefore, it must eliminate work somewhere else, because the methodology in and of itself does not create business benefit. Before considering whether SOA has benefits, you first must determine whether there are redundant, poorly integrated applications that could be consolidated or eliminated as a result of adopting SOA. If that's the case, then there are some potential benefits.

To get the entire picture of benefits being sold with Service Oriented Architecture SOA, you have to look at it on two levels: first, the tactical advantages of service-oriented development and second, the advantages of SOA as an overall architecture strategy.

Advantages of service-oriented development:

1. Software reuse. If the bundle of code that constitutes a service is the right size and scope (a big if, say Service Oriented Architecture SOA veterans), then it can be reused the next time a development team needs that particular function for a new application that it wants to build. For example, a telecom company may have four different divisions, each with its own system for processing orders. Those systems all perform certain similar functions, such as credit checks and customer record searches. But because each system is highly integrated, none of these redundant functions can be shared. Service-oriented development gathers the code necessary to create a version of "credit check" that can be shared by all four systems. The service may be a wholly new chunk of software, or it may be a composite application consisting of code from some or all of the systems. Regardless, the composite is wrapped in a complex interface that hides the complexity of the composite. The next time developers want to create an application that requires a credit check, the developers write a simple link to the composite application. They don't have to worry about linking with the individual systems—indeed, they don't need to know anything about how the code has been bundled or where it comes from. All they need to do is build a connection to it.

In a company that constantly builds new systems that rely on similar functionality—an insurance company with many different divisions, each with slightly different products, for example, or a company that is constantly acquiring new companies—the time saved in developing, testing and integrating that same bit of software functionality can add up.

But reuse isn't assured. If developers in other parts of the company don't know that the services exist, or don't trust that they are well built, or development methodologies differ around the company, the service may languish as a one-off. Companies that get reuse have developed governance mechanisms—such as centralized development teams, a single development methodology and service repositories—to increase the chances for reuse.

But sometimes the service just isn't designed properly. Perhaps it doesn't perform enough operations to be widely applicable across the company, or perhaps it tries to do too much. Maybe the developers didn't take into consideration all the different ways that others might want to use the service in applications. Service Oriented Architecture SOA veterans say that sizing services properly—also known as granularity—is as much art as science and that poor granularity can dramatically reduce the possibilities for reuse. Research company Gartner estimates that only 10 percent to 40 percent of services are reused.

2. Productivity increases. If developers reuse services, that means software projects can go faster and the same development team can work on more projects. Integration becomes a lot cheaper (at least 30 percent cheaper, according to estimates by Gartner) and faster, too, taking months off development cycles for new projects. Shadman Zafar, Verizon's senior vice president for architecture and e-services, says his catalog of services lets him skip forming a project team for the development of a phone-line ordering process, because the services necessary to compose the process were already in place. "With point-to-point integration, we would have had a central project team to write the overall integration, and local teams for each of the systems we needed to integrate with. With [the phone-line process], we had a single team that was focused almost entirely on end-to-end testing," he says. That saves time and resources and improves the quality of new applications, because testing is no longer the last hurdle of an exhausting application development process; instead, it's the focus.

3. Increased agility. Even if services will not be reused, they can offer value if they make IT systems easier to modify. At ProFlowers.com, for example, there are no redundant applications or multiple business units clamoring for services. But splitting the flower ordering process into discrete services means each component can be isolated and changed as needed to handle the spikes in demand that occur around holidays, according to ProFlowers CIO Kevin Hall. When ProFlowers had a single, monolithic application handling the process, a single change in the process or a growth in transaction volume (on, say, Valentine’s Day) meant tearing apart the entire system and rebuilding it.

In the new system, a server farm responds to spikes in activity during each phase of the ordering process by transferring storage capacity to the specific service that needs it most. The system is much more predictable now, and there have been no outages since the service-enabled process was rolled out beginning in 2002, according to Hall. "Because we can scale horizontally [more servers] and vertically [splitting up services], I don’t have to buy all the hardware to serve every service at its peak load," he says. "You don’t have to be able to eat the elephant in one bite anymore."

Advantages of an Service Oriented Architecture SOA strategy:

1. Better alignment with the business. SOA is the big picture of all the business processes and flows of a company. It means business people can visualize, for the first time, how their businesses are constructed in terms of technology. When IT projects are put in terms of business activities and processes rather than complex software applications, business people can better appreciate and support IT projects. "When I said we have 18 slightly different versions of 'credit check' buried inside different applications in different agencies," says Matt Miszewski, CIO for the state of Wisconsin, "the agency heads could understand why having all those different versions was a problem, and they could support creating a single version that everyone could use." The grand vision for Service Oriented Architecture SOA is that when IT fully service enables the major processes of a business, business people will someday be able to take control of modifying, mixing and matching the different services together into new process combinations on their own. But that vision is still many years away.

2. A better way to sell architecture to the business (and IT). Enterprise architecture has long been the concept that dared not speak its name. Some CIOs go to great lengths to avoid using the term with their business peers for fear of scaring, alienating or simply boring them to death. Enterprise architecture has always been a big, difficult and expensive undertaking, and its ROI has often been opaque to the business. Standardizing, mapping and controlling IT assets do not make the business obviously more flexible, capable or profitable. As a result, IT architecture efforts often fail or become completely IT-centric. Service Oriented Architecture SOA provides the value to the business that in the old enterprise architecture was rarely more than a vague promise. Reuse, improved productivity and agility in IT and a software infrastructure tuned to specific business processes are the lures to sell an enterprise architecture effort to the business. But remember that architecture is not for everyone. Small companies or highly decentralized companies may not be able to justify a centralized staff of project managers, architects and developers.

Source: http://www.cio.com