What Is Service-Oriented Architecture (SOA)?

Service-Oriented Architecture (SOA) – is a term that explains two very different things. The first two words explains a methodology for software development. The third word is a picture of all the software assets of a company, like an architectural plan is a representation of all parts that together form a building. Therefore, service-oriented architecture is a strategy that proclaims the creation of all software assets of a company using methodology-oriented programming services.

What is a service?

Services are portions – or components – software, developed so that they can be easily linked with other software components. The idea behind these services is simple: Technology should be expressed so that business people can understand, and not as an application enigmatic.

At the heart of the concept of services, it is the idea that makes it possible to define parts of the software code portions which is significant enough to be shared and reused in different business areas. Thus, some tasks become automated – for example, send a query to a credit reporting website to find out if a customer qualifies for a loan. If the programmers at a bank can abstract all that code to a higher level (ie, take all the code that was written to perform the verification of credit rating and package it into a single unit called “get credit rating” ), they can reuse that portion for the next time when the bank decides to launch a new loan product that requires the same information, instead of having to write code from scratch.

To achieve this, the developers created a complex wrapper around the bundled code. This wrapper is an interface that describes what the chunk does and how to connect to it. It is an old concept, dating from the ’80s, when the object-oriented programming has emerged. The only difference is that, today the software objects are much larger and more sophisticated.

In the U.S., for example, the service “get CSR” (get or obtain customer service record) is a complex clutter of software actions and data extractions that uses the infrastructure of enterprise integration to access more than 25 systems in four data centers around the country. Before creating the service “get CSR”, developers who needed that critical piece of data had to create links to all 25 systems – adding their own links on the complex web of links already hanging off the popular systems.

There are a lot of different ways to connect to the services, as like custom programming links or integration software suppliers, but from a couple of last years, a set of communication mechanisms to software known as web services, built upon the ubiquitous World Wide Web, has become a increasingly popular method for integrating software components.

What is the difference between SOA and Web services?

SOA is a comprehensive architecture for building applications within a company – think of an architectural project – but in this case, the architecture requires all that  programs which are created with a methodology for developing specific software, known as service-oriented programming. Web services are a set of standard mechanisms of communication that are created on the World Wide Web ie, Web services are a method to connect and communicate. While SOA is an IT strategy.

How do I know whether I should adopt an SOA strategy?

Being an architectural strategy, SOA involves more than mere software development. The creation of an architecture based on a portfolio of services demand that CIOs make a compelling case for enterprise architecture, a centralized development methodology and a centralized team of project managers, architects and developers. It also requires a CEO and an executive team ready, prepare the ground for the IT staff can dip into core business processes. Understanding these processes and getting buy-enterprise sharing are the cornerstone of a business transformation based on SOA.

Governance is critical. For services to be reused across the enterprise, there must be a methodology for developing single, centralized software so that different areas do not create the same service in different ways or use incompatible connectors. There must be a centralized repository so that developers know where to look for services – and IT will know who they are being used. The services must be well documented so that developers know what they are, as it integrates them and rules for using them. Some companies, for example, charge fees for use of services and create performance agreements to ensure that the services work well and do not burden the corporate network.

Most companies that have progressed on the path to SOA has created a centralized architecture group to choose processes that will be trained to service and see different areas of the company to create specific services. The centralized group also creates a convenient mechanism for governance. If all service requests have to go through the architecture group, the methods of service development, designs and performance agreements can be more easily managed.

Companies that have had more success with SOA so far are those that always have success with technology: big companies with big IT budgets whose business is based on technology (telecommunications and core banking services). They also tend to have business leaders involved in the IT field and willing to support their projects. For companies without these advantages, SOA may not be everything it promises.

For smaller companies, companies that bet the farm on integrated packaged applications and companies that adopt sound strategies for application integration, SOA has nothing to do with “when”, but “if.” CIOs must be careful because in service-oriented architecture, the elements of “service development” and “architecture planning” are distinct but not independent – must be considered and executed in parallel. Services that are reared in isolation, without taking the goals and architecture of the business into account, may have little potential for reuse (one of the most important benefits of SOA) or fail completely.

What are the benefits of SOA?

First of all, the benefits of service-oriented architecture must be contextualized. If your company is not large or complex, that is, if not more than two primary systems that require some level of integration, it is unlikely that the model provides great benefits. Amid all the hype around SOA today, can be forgotten that the development methodology in itself is not useful – is the effect it has on a redundant infrastructure and complex that it does. The architects say that creating a good service-oriented application involves more work than the usual application integration. (Research shows that SOA is being used to integrate traditional application in most companies.)

Thus, the development of SOA generates an extra initial cost. For this work produces benefits, SOA has to work on eliminating any other point, since the methodology itself does not generate benefits for business. So the first step is to find out if there are redundant and poorly integrated applications that could be consolidated or eliminated as a result of adoption. If this is the case, then there are potential benefits.

To understand the overview of the benefits touted by SOA, you need to examine it at two levels: first, the tactical advantages of service-oriented development and, second, the benefits of SOA as a strategy of global architecture.

Advantages of service-oriented development:

Software reuse: If the code package is a service that has the size and scope right (a big if, say veterans SOA), then it can be reused for the next time when the development team need a specific function for a new application that wants to develop. Say a telecommunications company has four different divisions, each with its own system for processing requests. All these systems perform some similar functions, such as credit checks and searches of client records. But, considering that each system is highly integrated, none of these redundant functions can be shared. The service-oriented development is gathering the necessary code to create a version of “credit check” that can be shared by all four systems. The service can be a totally new piece of software or a composite application consisting of code or some system of them all.

Anyway, the ‘composite’ is wrapped in an interface that hides its complexity. The next time when that developers need to create an application that needs credit check, will create a simple link to the new application. They don’t need to worry about connecting to individual systems – in fact, need not even know how the code has been included or where it comes from. Only need to create a connection to it.

In a company that constantly develops 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 getting ever more – the time saved in the tasks of developing, test and integrate this same functionality of software is an advantage.

But reuse is not guaranteed. If developers in other parts of the company did not know that services exist or do not trust that they are well built, or development methodologies vary within the company, services may decline and not be repeated. Companies adept at re-developed mechanisms of governance – development teams, centralized, single methodology for developing repositories and services – to increase your chances of reuse.

Sometimes, however, the service is simply not well designed. It does not perform operations enough to be widely applicable in business or attempts to perform other operations. Either the developers did not take into account that others may want to use the service in different ways. For professionals in the business, proper sizing of services – also known as granularity – is as much an art as a science, and bad granularity can dramatically reduce the possibilities for reuse. A research estimates that only somewhere between 10% and 40% of services are reused.

Increased agility: Even if services are not reused, they can add value to facilitate the modification of IT systems. There are no redundant applications or multiple business units clamoring for services. But with the division of the application process in discrete services, each component can be isolated and modified as necessary to cope with peak demand. In the system, a server responds to spikes in activity during each phase of the application process, transferring capacity to the specific service that needs it most.

Benefits of an SOA strategy:

1. Better alignment with the business. The service-oriented architecture is an overview of all processes and flows of a company’s business. It means that business people can visualize, for the first time, as the company is built in terms of technology. When IT projects are presented in terms of activities and business processes and not in the form of complex applications, the business people can better appreciate and support IT projects.

The grand vision of SOA is that, when fully enable IT services to the important processes of a business, business people can take control of change and merge the different services in new combinations of the process itself. But this view is still many years away.

2. A better way to sell architecture to the business (and IT). There are times that enterprise architecture has been the concept that dare not speak its name. Some CIOs get to the point of not using the term with colleagues for fear of scaring them, lose them or simply bore them. EA has always been a big undertaking, costly and complex. Your ROI, it is often unclear to the business. Standardize, map and track IT assets clearly does not make the business more flexible, capable and profitable. As a result, IT architecture efforts often fail or become completely IT-centric. The service-oriented architecture provides value to the business, enterprise architecture in the old, rarely was just a vague promise. Reuse, increased productivity and agility in IT infrastructure and a set of software for specific business processes are the bait to sell an enterprise architecture initiative for the business. But remember that architecture is not for everyone. Small or extremely decentralized companies may be unable to justify a centralized team of project managers, architects and developers.

How to balance the need for planning in SOA architecture with the need to prove the business value quickly?

Architectural planning is time consuming. The service-oriented development based on principles of programming known and widely available technology standards (SOAP, HTTP and so on), can be much faster. But the two have to happen in parallel, the experts teach.

How will SOA affect IT group?

If you have a decentralized company, be prepared to fight. SOA leads to centralization. In fact, ask centralization. You need someone to lead, you must have an individual or a small team managing the architecture. You need a group, a series of research and someone to ensure that development groups should adhere to the methodology for service development.

As the portfolio of services grows, the development process can begin to resemble an assembly line. “It turns into a factory”.

According to a survey of CIOs, only 25% of respondents have the teams they need to adopt service-oriented architecture – 49% plan to have or already have training programs for current staff to work at full steam.