The whole Web 2.0 and Enterprise 2.0 initiative, as well as Enterprise Architecture, point to two key strategies that will need to be implemented by IT departments (if they have not already done so). These are:

• To establish software as a service. This means designing all of the functions of future applications as serves, at the same time as beginning to take this approach in existing applications. This implies establishing an Enterprise Architecture to guide both the implementation of new applications and migration from existing ones, as well as steering the firm through the four phases of silos, standardized IT, standardized business processes and business modularity identified by the MIT’s CISR (Center for Information Systems Research). By making the functions of the various applications available as services, it is possible to achieve business modularity, which is to attain the necessary technological maturity for the firm to align its IT with the business strategy.
• To develop custom software aimed at two key issues. The first of these is to support the core business processes that represent a differentiating factor for the firm in the marketplace. The second is to use customer developments to transform third-party proprietary applications into services and integrate them into the company's service bus.

At the most basic level, it could be said that SOA seeks to align software and data services with business processes allow specific services to be mixed and reused at will.

SOA is now in, and as often happens in such cases, the term is often used erroneously, causing confusion in the market. This is compounded because SOA is a term that describes two very different things. Service orientation describes a software development methodology, while Architecture refers to the company’s software components model, representing all of the existing software parts that together make up the enterprise edifice. SOA, then, is in fact a strategy that seeks to build all of a firm’s software components using a service-oriented development methodology and the necessary technological support to achieve this goal.

In terms of the development methodology, it could be said that the SOA idea is as old as programming itself, given that applications development has always used different ways of modulating code, initially with includes, then with libraries, later with objects then components and ending with SOA and Web Services. The concept is thus far from new. What is new, however, is its scope, because it affects a firm’s entire technological architecture.

SOA holds out the promise of many benefits, some of which will be discussed below. However, SOA is not something that is within the reach of all companies. In the first place, it only makes sense for large IT departments formed by more than one primary system. SOA provides the greatest benefits within complex, diverse systems, and it is therefore unlikely to add any direct value in small firms. Even in large corporations using complex, diverse technological systems, SOA will not always have the same results.

As mentioned above, the MIT’s CISR (Center for Information Systems Research) defines four stages through which firms must pass in the paper “IT Architecture as Strategy” and “IT-Driven strategic Choices”. These stages are silos, standardized IT, standardized business processes and business modularity. Only when all four are completed will SOA add its full value, and the majority of the firms included in the study were no further along than the first or second. Hence, it is very important to analyze the consequences of implementing an SOA strategy with care.

As the word Architecture indicates, SOA is much more than merely building software. The decision to implement SOA requires a clear commitment to a well-defined Enterprise Architecture, to the creation of a centralized development methodology and to the appointment of a team of architects to set the guidelines for the development of services. It also requires involvement at the level of the CEO and executive staff to facilitate access by the IT team to the company’s core business processes. Understanding the business and sharing strategy is the keystone of Enterprise Architecture and, therefore, of SOA.

Another key issue is Governance. As explained above, it is necessary to establish a centralized development methodology in order to reutilize services throughout the firm and ensure that diverse business areas do not develop the same service in different ways. This umbrella therefore covers all processes, tools and other factors required to develop the technology strategy. A centralized repository is therefore necessary, and it must be well documented. Otherwise, SOA will produce only disorder, because any services developed in isolation, ignoring the centralized Enterprise Architecture, will have low reusability potential.

At Kynetia we help our clients created their own Service-Oriented Architecture, which naturally forms a part of the sub-set of key initiatives to establish the Enterprise Architecture.

Advantages of SOA

As defined at the beginning of this discussion, SOA involves two quite distinct aspects: development methodology and architecture. Hence, the benefits will be felt in both areas.

SOA as a development methodology

• Reusability. The objective is to group business functions into services that can be used whenever necessary by the application in question. This saves both time and money because the same thing does not need to be developed in different ways.
• Productivity gains. If business functions are accurately broken down into their components, development times for new projects will be slashed, because many of the functions requiring development can be reutilized. Where it was once necessary to recode the function, it is now necessary only to establish a link to the service provided.
• Agility. Even if the service is not reutilized by other applications, SOA allows complete functions to be isolated. This makes modification much more straightforward (because inputs and outputs are isolated and known) and maintenance more agile.

Service architecture as a strategy

• Enhanced business alignment When the software is broken down into business functions, the application becomes much more flexible, because the component processes can be easily changed provided functions are isolated. Within a few years, moreover, the firm’s business staff should be able to control, mix and match the different services (functions) available, giving rise to new business processes. Some vendors of SOA products in fact promise this today, although the reality of the current situation shows that we are still far from attaining this goal.