SOA Antipatterns January 21, 2014Posted by anywhereinfo in SOA.
Key Issues: Below are some key issues that I have faced during implementation of services based architecture.
- Underestimate time, budget and effort: Though this seems obvious as most IT projects are hard to estimate, but it becomes particularly important when implementing SOA. Due to SOA’s unique requirements, it requires a top down analysis to assess the current state, it requires analysis of existing applications to map which business function is being met by how many applications, it requires analysis of various data stores in the enterprise to determine redundant data stores and different representations of same business entity, it requires analysis of existing infrastructure to determine if it would be adequate for the distributed nature of SOA and the extra traffic that would be generated by it and finally it requires analysis of how nonfunctional requirements are being met across enterprise and standardize them such as security, monitoring etc.
All of the above requires funding, resources and time, which cannot be attributed to a particular business project.
- Adoption of SOA without a proven reference architecture: A reference architecture should provide
- Architecture blueprints
- Technology stack
- To create a reference architecture, a representative set of business requirements should be chosen that can represent key technical challenges. POC would be required to determine build vs buy decisions or to determine right set of technologies. Examples of build vs buy vs adopt open source and other POC decisions:-
- Determine ESB framework/vendor
- Determine HA architecture for ESB
- Determine caching architecture
- Determine Security frameworks/vendor
- Determine service monitoring solutions
- Determine SOA governance frameworks/vendor
- Determine service implementation approach such as SCA vs java Pojo
- Determine service monitoring tools
- Determine service testing tools
- Jump into identifying services without understanding business processes and their inter-relationships. This can result in set of services that are not aligned with business architecture and consequently, the “Business Agility” or the ability to create new products from existing services is hampered. My recommendation is to follow IBM’s SOAM(service oriented modelling architecture) approach which lays guidelines for identifying and categorizing services.
- Not identifying the right scope for the service. Too coarse grained impacts performance, especially in constrained environments such as mobile. Too fine grained results in large number of services which become a maintenance and transactional nightmare.
- Not isolating business services from technical bindings such as SOAP, HTTP, JMS etc. A lot of companies who wrote services without such isolation had hard time adopting to newer architectural approaches such as REST.
- Performance issues. For example, should each and every service be a remote process or should a component based service model be adopted where services can be collocated within a process.
- Not thinking about exception handling and transaction boundaries while designing services. Distributed transactions should be avoided where possible.
- Not planning for Service governance such as SCM, service lifecycle process, service retirement, service versioning. Appropriate checks are required during software lifecycle development such as architecture review, design review etc. to ensure service reuse and that service would meet SLA. A service directory is needed that allows services to be easily located and provides documentation for the service usage, including contact of the development team who owns the service.
- Lack of infrastructure and network capacity planning. With distributed services, network traffic tends to increase dramatically.
- Lack of service monitoring. Services are remote and reusable. A downtime or degrade of service SLA can impact many clients. Hence, it is critical to implement a service monitoring.
- Implementing enterprise SOA without mapping business process and existing applications. As a consequence, rather than elimination/merging of duplicate functionality across applications, SOA creates yet another duplication.
- Not scoping out entity Harmonization if different representations exist between applications such as user identity, product definition etc. The lack of data ownership results in complex data integration, which ultimately hinders building new products quickly.
- Organization structure change: Typically business division have their own vertical development silos, whereas SOA typically looks horizontally across the enterprise. To adopt SOA, existing teams need to be aligned with services as opposed to business divisions. This can cause quite a stir as it may imply change in responsibilities.
- Not identifying correct testing tools for SOA. SOA brings some unique challenges to testing such as
- Non UI Components
- Tools that can cope up with subscriptions to ESB
- Tools that understand security protocols such as OAuth, SAML etc
- Service Exception handling
- End to End testing