IT architecture has matured significantly as an approach to successfully address typical IT problem domains. A relatively new subdiscipline in architecture that has gained significant prominence is the Service-Oriented Architecture (SOA). SOA, frequently touted as the elixir to an enterprise's problem of application inflexibility and high maintenance cost, is often considered as a recipe for a company to boost its IT return on investment (ROI). SOA is a key architectural style for approaching IT system design so that a company's business goals align with IT, enabling them to build resilient IT systems to meet new and changing business requirements.
The advantages of SOA, such as increased flexibility, interoperability, and lower IT maintenance costs, are well documented and have, so far, stood the test of time. This record of success is attracting more enterprises to jump on the SOA bandwagon in an effort to reap those benefits. The enterprise proclamation to become SOA-enabled has led to a proliferation of SOA initiatives such as legacy applications conversion and modernization to become service-centric and to follow the principles and best practices of SOA. But SOA evangelists and adopters need to keep a watchful eye when applying SOA because the reality of adopting SOA is that it's not always smooth sailing or completely free from problems. In this article, you explore a variety of common problems that architects and development teams can run into if they try to adopt SOA without taking a thorough, deliberate approach.
Just as patterns are obvious choices to obtain repeated success, antipatterns result in pitfalls that are clear recipes for failure. As developers and architects seek to fully understand SOA best practices, it is just as important to be aware of the common pitfalls of SOA adoption.
The most common pitfalls include:
- Beware of vendor proprietary service offerings. Do not get locked into SOA vendor offerings that are proprietary in nature; you could lose the interoperability and flexibility benefits of a true SOA.
- Seek stability in the use of open standards. The latest open standard specification in the industry is not always the most stable; as a result, it may not be mature enough for adoption.
- Carefully assess your legacy modernization. Take a holistic view of the enterprise when choosing particular legacy systems for modernization. Silo approaches for SOA transition may create redundancy.
- Avoid "waterfall" development and lack of service versioning. SOA transition should be iterative in nature. A service life-cycle management should possess the capability to maintain multiple versions of a service.
- Know the technical constraints of your legacy system. Consider all the technology limitations of a legacy system before jumping ahead into a legacy modernization effort.
- Don't equate SOA with Web services. Acknowledge the difference between SOA (an architectural style) and Web services (a set of standards for SOA implementation).
- Avoid the silo approach to service creation and ownership. Understand the paradigm shift between traditional application development and an SOA-based development.
- Steer away from the use of fine-grained services. A service is a higher-level abstraction than fine-grained application program interfaces (APIs). Services should be coarse-grained and business aligned.
- Avoid point-to-point invocation. Make an SOA ecosystem manageable and loosely coupled. Bring in a mediation layer that handles service discovery, invocation, and neutralizes underlying technical differences between different SOA implementations.
- Avoid lack of adherence to standards. Adopt stable and proven industry-specific standards. This approach will bring in interoperability benefits for your SOA.
- Use redundant data stores. Concentrate on a data consolidation strategy. Mask the data redundancy by creating a virtualized data service.
- Stay away from using a "Big Bang" approach. For complex SOA transitions, forget a Big Bang approach to the finish line. Acknowledge and respect that a smooth SOA transition is best achieved by adopting an iterative approach.
- Allocate service ownership. Do not orphan a service. Give it a home and make a line of business its owner. This ownership allows someone to be responsible to maintain the nonfunctional qualities of your services.
- Institute SOA governance. Empower a governance body to manage the entire service life cycle.
Vendor proprietary service offerings
One of the basic tenets of SOA is that it provides interoperability of services across various heterogeneous functional and infrastructure environments. Although a huge momentum is developing among SOA product vendors to offer both functional and infrastructure service components, these products often create proprietary forms of the services they offer. Enterprises that buy into these products and use them as the foundation for their SOA can soon find themselves locked into the proprietary nature of the vendor service components.
SOA is defined by its interoperability and flexible plug-and-play of services based on business needs. This flexibility should never be compromised by using proprietary vendor products whose services are not based on stable, open standards. Be aware that unless a vendor's SOA products comply with well-established open standards as the basis for the implementation of their offered services, you should be extremely cautious about using those products. To achieve long-term success of an SOA-based transition, the support, adoption, and implementation of open standards for its implementation is imperative.
So, to reap the true benefits of interoperability between services, your SOA implementation must adhere to existing open standards (for example, WS-* specifications) that are widely accepted, regardless of whether services are developed from scratch, reused, or purchased from a vendor.
Any SOA-based development effort must carefully analyze the set of open standards that are identified for adherence and adoption. If the identified open standards are only at a design or specification level and a mature, stable version has not yet been released and widely adopted, the SOA can suffer from traditional maintenance nightmares. With each new release of a standard's specification, the business applications will also need to be changed in order to keep up with the standard. The same problem can be more critical if the standards are either not widely accepted or are proposed by a single vendor and do not yet enjoy the recognition from the industry at large.
That promising, newest open standard in the market, however, is not always the best one to adopt. It still must go through its own phase of maturity and adoption by the mainstream. At the very least, it must have a well-defined roadmap toward a stable and mature version.
Legacy modernization is a significant aspect of an enterprise's adoption of SOA. Any enterprise with an IT presence during the past few decades is bound to have legacy applications that assist in running its business. Legacy systems can exist at the infrastructure level, as well as at the operational level; for instance, an IBM CICS® mainframe running an enterprise human resources (HR) system. Legacy systems can also exist as either outdated or poorly written software applications that run on specific infrastructure components and operational environments.
When an enterprise takes the initiative to modernize its IT infrastructure and align it with business requirements, the IT team needs to take a closer look at existing legacy systems before building a business case for the transition to an SOA-based portfolio. Such analyses are frequently performed in silos, which means that specific isolated business domains are picked up for impromptu legacy modernization.
If legacy modernization is performed without taking a holistic enterprisewide view or without the context of the dependent and related business domains or competencies, it opens the potential for creating duplicate services and application program interfaces (APIs). The duplication arises from a lack of detailed analyses of the existing service portfolio. Existing services must be carefully analyzed using an 80-20 rule: If an existing service satisfies at least 80 percent of the required capability of a current modernization requirement with only a 20 percent effort required to create it from scratch, then it is advisable to realize the new requirement by building around or on top of the existing service.
If the enterprise IT organization's method of operation is through the initiation of silo SOA legacy modernization efforts, the potential gains of SOA may be compromised. That is, if the modernization takes place without evaluating the entire system, chances are it will not result in attainment of an authentic SOA. In these kinds of business models, SOA is not a good approach to undertake. When all is said and done, the business value of SOA would be hard to justify to business stakeholders.
Waterfall development and lack of service versioning
Taking a waterfall approach can be one of the common pitfalls in an SOA undertaking. When applied to traditional application development, "waterfall" implies a strict development sequence (such as solution outline, macro design, micro design), which is then followed by develop, code, and unit test (DCUT). Taking such an approach with SOA can lead to the creation of services that can be deployed only once and cannot be reused subsequently.
SOA is not an approach that can be implemented instantaneously. An enterprise should make the transition to SOA iteratively, in a phased manner, through a well-planned transformation roadmap. The roadmap pinpoints the most vibrant areas of the business, where SOA adoption can align the needs of business and IT. This transition can happen at a business-domain level; the services that are identified and then developed similarly benefit from iterative development.
According to an iterative approach, a service must have a well-defined life cycle, as depicted in Figure 1.
Figure 1. Service life cycle of services in an SOA
Part of this life cycle involves versioning each service you develop. A versioned service ensures that an upgrade of that service does not necessitate a retest of all the other services that the application uses. Service versioning provides, among other advantages, the support of different levels of service-level agreements (SLAs) for different consumers of the service. Service versioning also allows for iterative development of a service and its continuous improvement and enhancement based on business function requirements.
For large service-oriented enterprises, service versioning should be an integral part of a service management life cycle. As a result, it is critical that the operational capabilities of an enterprise's IT environment have a robust SOA management infrastructure. If not, it can pose a serious limitation to the growth of a service-oriented enterprise.
Service versioning also belongs in any discussion of SOA governance, which you'll learn more about in a moment. However, the failure to consider versioning is such a common pitfall of those who are just beginning SOA development that I wanted to highlight it separately.
Understanding technical limitations of legacy systems
A significant number of SOA efforts depend heavily on existing data and applications that reside in legacy systems.
Certain features of legacy systems are often not a natural fit with the real-time nature of SOA-based applications. A classic example of this mismatch is a single-threaded legacy application, where a business function is implemented for only single-threaded access. Another example of legacy system limitations is the case of scheduled batch processes, which only run at fixed times. Today's competitive enterprise demands more real-time transaction requirements.
When deciding to make legacy applications or data become part of an SOA system, it is imperative to understand the limitations this can place on the overall SOA. The single-threaded nature of legacy application, like that just mentioned, is an example of a technical limitation of a legacy system. Business capabilities of the modern enterprise often warrant transactional capabilities from the infrastructure that are beyond the capabilities of the existing legacy system. In such cases, an approach may be to gradually phase out the legacy system by building SOA-based solutions that are built on a modern infrastructure portfolio. To do this, the organization needs to select the most business-critical functions and replace their existing legacy implementations with a solution based on a technologically modern infrastructure. This phase can then be followed by the modernization of the remaining business functions. Such an approach provides a viable option for a phased sunsetting of the legacy system.
Equating SOA with Web services
Equating a Web service implementation to an SOA is a classic SOA antipattern that is typically seen when an enterprise wants to quickly get on the SOA bandwagon without assessing the maturity of its IT systems (including both applications and infrastructure). Such businesses plow ahead and implement Web services for anything and everything. The advancement of integrated development environments (IDEs) has ensured that the technical part of creating Web services is seamless and does not require a steep learning curve, which makes it easy for the IT department to create Web services without much consideration about whether they are aligned with the business goals of the enterprise. The proliferation of Web services creates a management nightmare and adds unnecessary cost to infrastructure operations. So, if the vision of the enterprise is to simply implement a set of Web services and then try to reap the benefits of SOA, it is advisable to step back and reconsider.
The difference between architecture and implementation needs to be well understood and respected if an enterprise wants to exploit SOA. Web services is one of the most popular implementation techniques for realizing SOA, an architectural style that allows IT services to be aligned with business needs to assure the business value of IT. To take advantage of the benefits of SOA, the enterprise IT team needs to fully understand the difference between SOA and Web services. That is, the IT team needs to acknowledge SOA as an architectural discipline compared with Web services, which is currently the most popular SOA implementation technique.
When modeling and designing an SOA, it's highly recommended that the IT team follows a standard methodology. IBM's Service-Oriented Modeling and Architecture (SOMA) provides a prescriptive and detailed step-by-step approach toward service modeling and design. At the highest level, SOMA provides a three-step process for service identification, specification, and realization -- helping to create output which can be used for an SOA implementation. It's also recommended prior to designing an SOA that you assess the service integration maturity of the enterprise in various areas (such as business view, organization, applications, architecture, etc.). Assessing the maturity levels of these areas enables you to assess the current state of the enterprise; you can then create an incremental transformation roadmap toward higher levels of service integration maturity. To help you accomplish this, IBM provides a technique called Service Integration Maturity Model (SIMM). This SOA assessment can be immensely helpful for enterprises that are taking their SOA transition seriously. (See Resources for more information about SOMA, IBM's free assessment tool, and SIMM.)
Silo approach to service creation and ownership
SOA is a relatively new architectural concept that bridges the gap between IT solutions and business goals. SOA also represents a paradigm shift from the traditional concept and premise of application architectures. Application architectures are typically created as independent work efforts that are usually owned by a specific organizational domain or entity. Applications are usually built to automate business applications within a single organization domain. Those single-domain applications are said to be "siloed." The principles of silo applications, namely inception, design, and implementation, cannot be directly applied to SOA.
When an enterprise begins to embrace SOA, often the paradigm shift away from silo development is not well institutionalized. Services may be identified based on isolated applications, which can result in the identification and implementation of services (by different groups within the same enterprise) that are semantically similar but have different names. This duplication not only stands in the way of harnessing the true benefits that SOA promises, but this duplication also increases development and operational infrastructure costs.
The concept of shared services should be institutionalized in the enterprise and its benefits must be well understood. Services should be seen as cross-organizational entities where a true business process is realized by choreographing business flows using multiple services. The services in the flow can be owned by different lines of business within an enterprise.
Services must be universally published either for internal cross-organizational consumption or for external consumption in a service ecosystem where multiple enterprises take part. The organizational boundaries and constraints must be relaxed in order to realize the true benefits of shared services.
A working body must be put in place whose responsibility is to focus on identifying common services and establish a governance framework to help define the ownership, funding, and the life cycle of the services that are candidates for realization. If such a governing body is not in place, it can be difficult for an enterprise to stem the proliferation of silo services and realize the benefits of SOA.
The silo issue is a common pitfall for SOA adoptors; the greater issue of SOA governance is discussed later, but it's important to recognize that governance is the overarching solution to mitigate the disadvantages of the silo approach.
Even before you begin SOA activities, business intelligence (data) and application functions usually exist in the current enterprise IT portfolio. These traditional enterprise applications are usually
API based. Examples of typical API's to access customer information may be, for example, getFirstName(), getLastName(), or getCelPhone(). These APIs are usually very fine-grained and granular in nature.
A common SOA malpractice is the wrapping of this type of fine-grained APIs with service interfaces and exposing them through Web Services Description Language (WSDL) definitions. This results in an unfortunate degeneration of the service concept into nothing more than a "glorified API wrapped by a costly service facade." Not only do the resulting "services" communicate only a very small piece of business data, this practice also creates a huge proliferation of services. As a result, the onus is on the consumer to aggregate the services in the proper sequence in order to realize any high-level business functionality.
Keep in mind that services do not come for free: An application pays a premium in the form of performance with each service that is invoked. The malpractice just mentioned will result in chatty services with increased system overhead and a performance penalty that can be a significant setback to the adoption of SOA.
As we've mentioned several times, a service must be business aligned and provide real revenue potential (whether through cost reduction and savings or income generation) for the enterprise. Creating fine-grained services that simply mimic the API implementation is not going to help the cause of SOA -- or the enterprise.
A service may be implemented by aggregating the functionalities of multiple lower-level and granular API implementations. Instead of exposing each fine-grained API as a service; a coarse-grained, business-aligned interface should be abstracted from the APIs and then exposed as a service. This not only reduces the network overhead and chattiness between various application tiers, it also is a big step toward business alignment of service interfaces.
The concepts of service providers and service consumers are important to SOA. The consumption of a service by a consumer can be implemented in several ways. The most common pitfall in this area is to employ point-to-point service invocation. This approach leads to a combinatorial explosion of connections between the service consumers and providers in an SOA system. This type of point-to-point connection nightmare is shown in Figure 2. Perhaps you could get such a system to run, but how do you maintain it long term while keeping track of all the connections and having to make changes if even one of the services or applications is replaced or rewritten?
Figure 2. Point to Point service invocation between applications
A proper service invocation architecture needs to be put in place when an enterprise has a complex, tight coupling between the applications, especially when the number of applications in the portfolio is large. IT system design needs to create a logical architectural layer that encapsulates and performs transformation (of data), routing (of service invocations) and protocol mediation (between the possibly disparate implementations of the different services). This breakdown allow for loose coupling between service providers and consumers. Figure 3 depicts such a logical architecture where the service providers and service consumers communicate through a logical bus.
Figure 3. Hub and spoke communication pattern for service invocation
The figure shows how the service consumers are separated from the service producers through an intermediate layer. The consumers communicate with the logical bus, which keeps track of the available services from the providers, and in turn calls the appropriate provider. This mitigates the problem caused by point-to-point communications in a system with a proliferation of services. An architecture, like the one shown in Figure 3, should be conceptualized, if not defined, before jumping into service implementations. This rule is especially applicable for enterprises with a large number of applications and legacy systems that need service orientation and integration.
Lack of adherence to standards
When adopting SOA, it is imperative to adhere to open standards instead of trying to bypass them or create homegrown solutions. For example, it is advisable to create the enterprise infrastructure to use Universal Description, Discovery, and Integration (UDDI) as a future federated registry ecosystem rather than not using the standard or building a custom solution for service discovery (such as a database of service names and URLs).
During the specification of a service in a SOA, it is especially important to adhere to industry-specific standard XML specifications. Such industry-specific standards define message formats and business entities, and they must be used as the basis to define the message formats and data types you'll use when building the services.
There is an industrywide push to come up with XML specifications that define the enterprise information model and a set of standard service operations to be used with the model. Many vertical industries are ahead in the race toward this goal. For example, Agent-Company Organization for Research and Development (ACORD) is the XML-based standard for the insurance industry, Justice XML Data Dictionary (JXDD) is the XML-based standard for the incident management discipline used by the U.S. Department of Homeland Security, and OpenTravel Alliance (OTA) is the standard in the travel and transportation industry. These standards have been published as stable specifications, and more SOA-based endeavors are adopting them.
The adoption and adherence of such standards, through the compliance with a common vocabulary of message formats for information exchange, makes an SOA flexible enough to be shared among partners in an ecosystem. It also allows for plug and play of vendor SOA products that conform to and implement these standards. This flexibility is one of the pivotal elements of a well-defined and structured SOA, enabling the successful creation of a grand SOA ecosystem.
In enterprises with no such awareness and no serious effort toward analysis and adoption of industry standards, the development team needs to consider and institutionalize the importance of standards. A proper governance framework can be very helpful in communicating this message to stakeholders, helping to ensure compliance and adoption. In cases where there is insufficient attention to standards and SOA is still required, the organization will miss many of the key benefits of SOA.
In a typical large enterprise with an IT department that has churned out applications over the years, it is commonplace to find multiple data stores and database systems that contain duplicate information. The primary reason for this is the classic silo approach, where applications are isolated and focused on a single organizational unit within an enterprise.
When an enterprise begins the transition to an SOA, it is impractical to throw away all the existing systems and rebuild everything from scratch. Yet in such a circumstance it is not uncommon to see IT services that are built against different data sources, even though those sources contain identical data.
A more efficient approach is to consolidate the data so that disparate data systems form a single view of the data (for example, creating a single consolidated database to store customer information). Another way of approaching this problem is to create a virtualized data service that encapsulates the data redundancy in the enterprise information systems and use that from a higher-level service or a business process.
Creation of individual services for each data system is not a good way to use SOA for information aggregation from enterprise information systems, and it must be avoided.
SOA is defined differently, depending on your role in an organization. To a business executive, SOA creates a set of services that the business wants to expose to its customers and partners or to other portions of the organization. To an architect, SOA is an architectural style, which at a minimum, requires a service provider, requestor, and a service description. To a programmer, SOA is a programming model complete with standards, tools, and technologies such as Web services. It is not hard to understand and acknowledge that an SOA transition is a paradigm shift for the entire enterprise that cuts across both IT and business departments all the way to stakeholders. Such a paradigm shift is best realized through an iterative model where a set of business-critical and high-value functions are identified for service enablement. This model can then be followed by subsequent service-enabled projects and initiatives. Taking a "Big Bang" approach, where the entire enterprise portfolio is planned to be service enabled all at once, assumes too much of a business risk on the entire organization.
SOA can be distinguished from other architectures since it explicitly addresses many of the enterprises' nontechnical constraints. One such constraint is that large organizations tend to evolve in small, incremental steps. The organization's IT infrastructure should enable a similar evolution. Such an iterative evolution path addresses the following possible problems:
- Risk of failure. IT is increasingly considered to be the heart of the modern enterprise. Any major IT failure can lead to serious financial and operational consequences for the corporation. As such, IT projects must be undertaken and executed with great care. An iterative evolution mitigates the risk of failure by allowing the organization to modernize in small steps.
- Aversion to change. Any organization has a finite capacity to accept and incorporate change. The changes affect the day-to-day operations of an enterprise that touch both the manual and automated business processes. An evolutionary approach assures that the changes brought about by the introduction of new processes and systems are well within the capacity of the enterprise and do not wreak havoc with its people.
- Feasibility. The size of a new piece of functionality should be a factor of the feasibility of its implementation across the enterprise. In an SOA, a new piece of functionality or capability is not always constrained to a single line of business (LOB) and many cross-organizational dependencies need to be considered.
SOA is well suited for an iterative, step-by-step approach toward its final state because of two major characteristics:
- SOA enables an efficient deconstruction of large segments of functionality into more manageable and largely decoupled components. Big Bang approaches that are inherently risky can be easily broken down using the principles of SOA into subprojects that tackle specific functional areas of the enterprise. This ensures a smooth transition to the final state and also assures that a single failure, if one occurs, does not bring down the entire enterprise.
- SOA is mostly technology-agnostic and as a result, you can separate the business and technology aspects and treat them as separate entities capable of being amended in an independent manner. SOA links business functions and imperatives to IT capabilities in an agile manner so that neither the business nor its supporting IT is disruptive of the other.
Enterprises whose preference and imperatives are to get to a Big Bang transition may not be prime candidates to use SOA, let alone realizing its true benefits.
The need for business services is identified at the department or organization level, with each line of business having specific business functional needs. Some of these business functions are directly aligned with the enterprise business goals, which means they may be exposed as a service interface manifested through an externalized service definition.
A problem arises when there is no properly outlined service ownership model. Many enterprises emphasize the churning out of services, making them available to participate in a composition. Often, the need for ownership of these services is overlooked.
Each business service must have a well-documented and agreed-upon LOB that owns the business service. Ownership comes with the responsibility of meeting the nonfunctional requirements (NFRs) of the service and being accountable for its noncompliance. A typical result of an orphaned business service is noncompliance to the services SLA, which can make that service the weakest link in an enterprise-level service composition. This weakest link can even break the SLA requirements for the overall business process in which the culprit service is a participant and create adverse effects at the enterprise level.
While such requirements may seem to be overwhelming to the LOB owner of a given service, the LOB owner can create a positive impact from the service offerings. Imagine a scenario in which the LOB owner charges a small price to the consumers of the service from other departments. In turn, she maintains a perfect compliance of the stated service-level SLA and NFR. This may help her business unit repay the development costs of the service.
Business domain ownership is also important because the enterprise service portfolio should not be handed over to the IT department to develop and maintain. If IT drives an enterprise's SOA development, they usually, and understandably, aim for the most easily developed services first, without much attention to the business value of the services. This approach leads to misalignment between the business goals and the developed services. In such cases, the benefits of SOA are not being exploited.
Business unit ownership of services is critical to the success of an enterprise SOA initiative. When a business ownership model is not implemented, SOA can become a deterrent to the success of the enterprise SOA.
Governance is a decision rights and management framework which ensures that the right steps are taken at the right time by the right people who are empowered to take them.
As an enterprise undergoes an SOA transformation, it needs to take governance seriously because service ownership is often distributed across various LOBs. The proliferation of moving parts that must be maintained by various organizations, both within and outside the enterprise, makes governance a necessity. This cross-organizational nature of business services and the potential composition of services across organizational boundaries can function properly and efficiently if, and only if, the services are effectively governed for compliance to SLAs and NFRs (for example, in the areas of security, reliability, performance, and so forth).
Identifying, specifying, creating, and deploying enterprise services needs an effective service-oriented governance through a strong, efficient body that can oversee the entire life cycle of services of an enterprise's service portfolio. The policy rules and decisions and their enforcement, along with the requirement of a well-organized service life cycle management, means the implementation of SOA governance has to be part of the strategy and planning phase of an enterprise SOA transformation rather than an afterthought.
During the first wave of SOA, governance was merely a nice, optional discipline. But with the growing maturity and complexity of SOA implementations at real-world enterprises with complex and integrated value chains, SOA governance now plays a mandatory role in the overall SOA transition strategy.
An enterprise that fails to realize the importance of an effective governance structure may not stand to benefit much from SOA. In fact, an SOA implementation at such enterprises can prove to be disruptive in nature and lack the proper organizational structure to effectively follow the proper SOA principles and reap its benefits.
Enterprises should avoid the purchase of middleware products, database systems, and management solutions in order to create software components, infrastructure solutions, and services that cater to solving a single, specific business problem. Such specific, one-to-one, product-to-solution mapping can introduce redundancy or prove to be too cost prohibitive to allow for the implementation of an SOA. Instead, the focus should be on identifying commonalities between problems and then mapping them to technical solutions.
Excessive decoupling between problem domains should not be a hard and fast mandate for SOA development. Such excessive decoupling between fine-grained problem spaces can lead to excessive fragmentation in the overall service-based solution. Such fragmentation can cause a solution to be highly inefficient, especially when latency and performance is critical.
Without a proper SOA vision, SOA designers and implementers will be clueless about what the final state of the enterprise is supposed to be. Services must be traceable to one or more business goals to prove the reason for their existence. And if SOA benefits cannot be measured against some form of business metrics, then the entire purpose of an SOA transition stands to be questioned. Clearly, it not advisable to embark on a SOA initiative without the SOA vision, the business goals, and business agility metrics properly identified, defined, and documented.
And finally, an enterprise needs to understand its own agility requirements. Business agility requirements are not the same for every enterprise. They are driven by competitive and differentiating strategies, time to market, and various other factors. Agility needs to be realistically materialized through SOA; over-engineering for agility can cripple the IT system performance of an enterprise.
SOA is by no means a magic bullet that instantly solves every enterprise IT architecture problem. When adopting SOA, an enterprise should take a knowledgeable and pragmatic approach, one in which the theories of business value propositions of SOA meet the real-world complexities of its implementation. However, if implemented correctly and if you can avoid the pitfalls covered here, you'll discover there are more advantages to embracing SOA than not.
In this article you learned that a comprehensive understanding of common obstacles in an SOA adoption is as important as understanding its benefits and best practices. You explored real-world scenarios that show SOA being used in ways that not only fail to follow its guiding principles, but also show classic SOA antipatterns and misuses. By highlighting these common pitfalls, you and your team can more easily avoid them and, as a result, minimize the associated risks of SOA adoption.
Quick list of top SOA pitfalls
The following list recaps the top obstacles to creating a smooth transition to a true SOA. Click each link to go back to that section in the article.
- Beware of vendor proprietary service offerings. Do not get locked into SOA vendor offerings that are proprietary in nature; you could lose the interoperability and flexibility benefits of a true SOA.
- Seek stability in the use of open standards. The latest open standard specification in the industry is not always the most stable; as a result, it may not be mature enough for adoption.
- Carefully assess your legacy modernization. Take a holistic view of the enterprise when choosing particular legacy systems for modernization. Silo approaches for SOA transition may create redundancy.
- Avoid "waterfall" development and lack of service versioning. SOA transition should be iterative in nature. A service life-cycle management should possess the capability to maintain multiple versions of a service.
- Know the technical constraints of your legacy system. Consider all the technology limitations of a legacy system before jumping ahead into a legacy modernization effort.
- Don't equate SOA with Web services. Acknowledge the difference between SOA (an architectural style) and Web services (a set of standards for SOA implementation).
- Avoid the silo approach to service creation and ownership. Understand the paradigm shift between traditional application development and an SOA-based development.
- Steer away from the use of fine-grained services. A service is a higher-level abstraction than fine-grained application program interfaces (APIs). Services should be coarse-grained and business aligned.
- Avoid point-to-point invocation. Make an SOA ecosystem manageable and loosely coupled. Bring in a mediation layer that handles service discovery, invocation, and neutralizes underlying technical differences between different SOA implementations.
- Avoid lack of adherence to standards. Adopt stable and proven industry-specific standards. This approach will bring in interoperability benefits for your SOA.
- Use redundant data stores. Concentrate on a data consolidation strategy. Mask the data redundancy by creating a virtualized data service.
- Stay away from using a "Big Bang" approach. For complex SOA transitions, forget a Big Bang approach to the finish line. Acknowledge and respect that a smooth SOA transition is best achieved by adopting an iterative approach.
- Allocate service ownership. Do not orphan a service. Give it a home and make a line of business its owner. This ownership allows someone to be responsible to maintain the nonfunctional qualities of your services.
- Institute SOA governance. Empower a governance body to manage the entire service life cycle.
Learn
-
Read Part 1 and Part 2 in the developerWorks series, "Toward a pattern language for Service-Oriented Architecture and Integration."
-
Get an introduction to "IBM's Service Oriented Modeling and Architecture (SOMA) methodology."
-
Read the article, "Elements of Service-Oriented Analysis and Design."
-
Get an introduction to SOA governance.
-
Learn more about how to Increase flexibility with the Service Integration Maturity Model (SIMM).
-
A good treatise on the use of ESB as a logical bus in an SOA can be found in the article, "Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture."
-
Migrating to a Service-Oriented Architecture -- Develop a realistic plan for evaluating your current infrastructure and migrating it to a true SOA (developerWorks, December 2003).
-
Visit the
developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
-
Stay current with
developerWorks technical events and webcasts.
Get products and technologies
-
Build your next development project with
IBM trial
software, available for download directly from developerWorks.
Discuss
- Participate in the discussion forum.
-
Read more about ACORD specifications.
- Get more information about OTA specifications.
-
Find out more about JXDD specifications.
-
Participate in developerWorks blogs and get involved
in the developerWorks community.
Tilak Mitra is an Executive IT Architect at IBM. His recent emphasis, expertise, and interest is in the broader discipline of SOA. In addition to helping clients in their SOA transitions, Tilak influences aspects of the business direction of IBM's SOA growth plan. He also specializes in complex and large-scale enterprise architecture. Tilak lives in sunny South Florida. While not at work, he is engrossed in the games of cricket and table tennis. You can blog with him on SOA topics and contact him at tmitra@us.ibm.com.
Comments (Undergoing maintenance)
Table of contents
- Introduction
- Vendor proprietary service offerings
- Open Standards
- Legacy modernization
- Waterfall development and lack of service versioning
- Understanding technical limitations of legacy systems
- Equating SOA with Web services
- Silo approach to service creation and ownership
- Fine-grained services
- Point-to-point invocation
- Lack of adherence to standards
- Use of redundant data stores
- Big Bang SOA
- Service ownership
- SOA governance
- Other considerations
- Summary
- Quick list of top SOA pitfalls
- Resources
- About the author
- Comments
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
