From Project Management to Program Management to the "Network Organization"
In computing, a service-oriented architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration. A deployed SOA-based architecture will provide a loosely-integrated suite of services that can be used within multiple business domains.
SOA also generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages; their respective clients will benefit from a well understood, well defined interface to access them. XML is commonly used for interfacing with SOA services, though this is not required.
SOA defines how to integrate widely disparate applications for a world that is Web based and uses multiple implementation platforms. Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point for such an SOA implementation.
Service-orientation requires loose coupling of services with operating systems, and other technologies that underlie applications. SOA separates functions into distinct units, or services[1], which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services and their corresponding consumers communicate with each other by passing data in a well-defined, shared format, or by coordinating an activity between two or more services[2].
One can envisage SOA as a sort of continuum, as opposed to distributed computing or modular programming.
Discussion
*Benefits
Some enterprise architects believe that SOA can help businesses respond more quickly and cost-effectively to changing market-conditions. This style of architecture promotes reuse at the macro (service) level rather than micro (classes) level. It can also simplify interconnection to – and usage of – existing IT (legacy) assets.
In some respects, one can regard SOA as an architectural evolution rather than as a revolution. It captures many of the best practices of previous software architectures. In communications systems, for example, little development has taken place of solutions that use truly static bindings to talk to other equipment in the network. By formally embracing a SOA approach, such systems can position themselves to stress the importance of well-defined, highly inter-operable interfaces.
Some[who?] have questioned whether SOA simply revives concepts like modular programming (1970s), event-oriented design (1980s) or interface/component-based design (1990s)[citation needed]. SOA promotes the goal of separating users (consumers) from the service implementations. Services can therefore be run on various distributed platforms and be accessed across networks. This can also maximize reuse of services[citation needed].
SOA is an architectural and design discipline conceived to achieve the goals of increased interoperability (information exchange, reusability, and composability), increased federation (uniting resources and applications while maintaining their individual autonomy and self-governance), and increased business and technology domain alignment.
Service-Oriented Architecture (SOA) is an architectural approach (or style) for constructing complex software-intensive systems from a set of universally interconnected and interdependent building blocks, called services.
SOA realizes its business and IT benefits through utilizing an analysis and design methodology when creating services. This methodology ensures that services remain consistent with the architectural vision and roadmap, and that they adhere to principles of service-orientation. Arguments supporting the business and management aspects from SOA are outlined in various publications.
A service comprises a stand-alone unit of functionality available only via a formally defined interface. Services can be some kind of "nano-enterprises" that are easy to produce and improve. Also services can be "mega-corporations" constructed as the coordinated work of sub-ordinate services.
Services generally adhere to the following principles of service-orientation:
abstraction
autonomy
composability
discoverability
formal contract
loose coupling
reusability
statelessness
A mature rollout of SOA effectively defines the API of an organization.
Reasons for treating the implementation of services as separate projects from larger projects include:
separation promotes the concept to the business that services can be delivered quickly and independently from the larger and slower-moving projects common in the organization. The business starts understanding systems and simplified user interfaces calling on services. This advocates agility. That is to say, it fosters business innovations and speeds up time-to-market.
separation promotes the decoupling of services from consuming projects. This encourages good design insofar as the service is designed without knowing who its consumers are.
Documentation and test artifacts of the service are not embedded within the detail of the larger project. This is important when the service needs to be reused later.
An indirect benefit of SOA involves dramatically simplified testing. Services are autonomous, stateless, with fully documented interfaces, and separate from the cross-cutting concerns of the implementation. The industry[which?] has never been exposed to this circumstance before.
If an organization possesses appropriate defined test data, then when a service is being built, a corresponding stub is built that reacts to the test data. A full set of regression tests, scripts, data, and responses is also captured for the service. The service can be tested as a 'black box' using existing stubs corresponding to the services it calls. Test environments can be constructed where the primitive and out-of-scope services are stubs, while the remainder of the mesh are test deployments of full services. As each interface is fully documented, with its own full set of regression test documentation, it becomes simple to identify problems in test services. Testing evolves to merely validating that the test service operates according to its documentation, and in finding gaps in documentation and test cases of all services within the environment. Managing the data state of idempotent services is the only complexity.
Examples may prove useful to aid in documenting a service to the level where it becomes useful. The documentation of some APIs within the Java Community Process provide good examples. As these are exhaustive, staff would typically use only important subsets. The 'ossjsa.pdf' file within JSR-89 exemplifies such a file.
*Challenges in adopting SOA
One obvious and common challenge faced involves managing services metadata[citation needed]. SOA-based environments can include many services that exchange messages to perform tasks. Depending on the design, a single application may generate millions of messages. Managing and providing information on how services interact can become complex. This becomes even more complicated when these services are delivered by different organizations within the company or even different companies (partners, suppliers, etc.). This creates huge trust issues across teams, and hence SOA Governance comes into the picture.
Another challenge involves the lack of testing in SOA space. There are no sophisticated tools that provide testability of all headless services (including message and database services along with web services) in a typical architecture. Lack of horizontal trust requires that both producers and consumers test services on a continuous basis. SOA's main goal is to deliver Agility to Businesses[citation needed]. Therefore it is important to invest in a testing framework (build or buy) that would provide the visibility required to find the culprit in the architecture. Business agility requires SOA services to be controlled by the business goals and directives as defined in the Business Motivation Model (BMM).
Another challenge relates to providing appropriate levels of security. Security models built into an application may no longer suffice when an application exposes its capabilities as services that can be used by other applications. That is, application-managed security is not the right model for securing services. A number of new technologies and standards have started[when?] to emerge and provide more appropriate models for security in SOA. See SOA Security entry for more information.
As SOA and the WS-* specifications practitioners expand, update and refine their output, they encounter a shortage of skilled people to work on SOA-based systems, including the integration of services and construction of services infrastructure.
Interoperability becomes an important aspect of SOA implementations. The WS-I organization has developed Basic Profile (BP) and Basic Security Profile (BSP) to enforce compatibility. WS-I has designed testing tools to help assess whether web services conform to WS-I profile guidelines. Additionally, another charter has been established to work on the Reliable Secure Profile.
Significant vendor hype surrounds SOA; this can create expectations that may not be fulfilled. Product stacks continue to evolve as early adopters test the development and runtime products with real-world problems. SOA does not guarantee reduced IT costs, improved systems agility or faster time-to-market. Successful SOA implementations may realize some or all of these benefits depending on the quality and relevance of the system architecture and design.
Internal IT delivery organizations routinely initiate SOA efforts, and some of these improperly introduce concepts to the business[citation needed] so it remains misunderstood[by whom?]. The adoption starts meeting IT delivery needs instead of those of the business, resulting in an organization with (say) superlative laptop provisioning services, instead of one that can quickly respond to market opportunities. Business leadership also becomes convinced that the organization is executing well on SOA.
One of the most important benefits of SOA is its ease of reuse. Therefore accountability and funding models must ultimately evolve within the organization.[citation needed] A business unit needs to be encouraged to create services that other units will use. Conversely, units must be encouraged to reuse services. This requires a few new governance components:
Each business unit creating services must have an appropriate support structure in place to deliver on its service-level obligations, and to support enhancing existing services strictly for the benefit of others. This is typically quite foreign to business leaders.
Each business unit consuming services accepts the apparent risk of reusing services outside their own control, with the attendant external project dependencies, etc.
An innovative funding model is needed as incentive to drive these behaviors above.[citation needed] Business units normally pay the IT Organization to assist during projects, and then to operate the environment. Corporate incentives should discount these costs to service providers, and create internal revenue-streams from consuming business units to the service provider.[citation needed] These streams should be less than the costs of a consumer simply building it the old-fashioned way. This is where SOA deployments can benefit from the SaaS monetization architecture.
