Common SOA Pitfalls
IT architecture has matured significantly as an approach to successfully address typical IT problems. 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 stood the test of time. This record of success is attracting more enterprises to jump on the SOA bandwagon. 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. As developers and architects seek to fully understand SOA best practices, it is important to consider the common pitfalls of SOA adoption.
These pitfalls include:
- Beware of vendor proprietary service offerings. Do not get locked into SOA vendor offerings that are proprietary in nature; you risk losing the interoperability and flexibility benefits of a true SOA by doing so.
- 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.
- Stay away from using a “Big Bang” approach. For complex SOA transitions, forget a Big Bang approach to complete your transformation. 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.
QAT’s approach to SOA is founded on our practical experience in building working products and solutions for enterprises across the globe. In short QAT assists enterprises in making the right business and technology decisions.
Download: Common SOA Pitfalls
Latest posts by Rich Barndt (see all)
- The Path to Service Oriented Architectures (SOA) – QAT Global - November 19, 2012
- SOA Business Value for Enterprise and Government Agencies - November 19, 2012
- Is SOA the Answer? - November 19, 2012