Service Oriented Architecture (SOA) continues to gain momentum in the business world, with more and more businesses seeking to lower operational costs and improve customer service and data sharing with agile, streamlined SOA business processes. But with every groundbreaking movement comes a group of naysayers. Read Integrella’s responses to the most common SOA objections.
Although the popularity of Service Oriented Architecture continues to rise worldwide, there are plenty of voices in the IT community who have very little to say about SOA that is positive. There are a few reasons for this rash of negativity toward SOA – for one, it is a relatively new concept in IT, and many traditionalists see it as a threat to the status quo.
Another reason is that not all SOA Consultants are reliable stewards and service providers of SOA best practices. Very often, unreliable support teams and consultants lead companies down the wrong path of implementing SOA, which results in unintended consequences and wasted effort. Other times, companies are not given a full perspective on what adopting SOA will exactly mean to their corporate structure long term.
The fact is, if a company who wishes to implement SOA into their business processes engages with a reliable SOA Consultant and faithfully follow the SOA Maturity Model, many of the perceived pitfalls of SOA can be avoided or overcome. Here are a few of the most common objections to SOA:
1. SOA Shakes Up a Company’s Organizational Structure
One of the biggest criticisms of SOA is that its company-wide implementation can create division in the organizational structure. There are two reasons for this idea – first, SOA usually establishes a kind of quality-control team, known as the Center Of Excellence (COE), which oversees the implementation and management of SOA from the bottom up. Because the COE has discretionary power to make changes in order to maintain optimal performance of the system, it becomes a power broker within the organization.
Second, this addition to the organizational structure often results in a realignment of the power structure as well, with new players in the organization having more control over business processes and established players being marginalised to some extent. All of these changes can result in strained interpersonal and managerial difficulties that SOA naysayers say aren’t worth it.
However, this condition is purely a result of bad SOA management from the beginning of a project.
A key component of successful implementation of SOA is to ensure that the business fully understands the implications of employing SOA standards. Part of this requires that the stakeholders in a company’s organizational structure are all effectively invested in the SOA approach. As Oracle’s SOA Maturity Model demonstrates, the first two steps in SOA implementation are deliberate and careful, leading an organization carefully into the new territory of service oriented architecture. If the foundation for a new system is not properly established, then the company will not be able to handle the organizational changes associated with SOA.
2. SOA Leads to Failed Expectations
Many SOA naysayers will claim that, more often than not, SOA implementation results never live up to the promises and expectations made by their purveyors. Often times, SOA is judged on the vision of a fully-realized SOA and BPM landscape, wherein a company has adopted a kind of SOA “ecosystem” that allows it to function with idyllic fluidity and agility. As a result, if an SOA project never reaches that pinnacle, it is often deemed to be a failure by critics.
In response to this criticism, however, it should be noted that, even though there are a fair share of failed SOA implementations throughout the world, failure is not exclusive to SOA; software development as a whole features a high failure rate across all IT methodologies, especially when “failure” is defined as, “an unhappy department, senior management that is unhappy with the results, a general feeling of failure, unable to demonstrate and most likely without ROI, and an impression that Integration is in-the-way and provides unsufficient (sic) benefit versus the effort to engage the process,” (courtesy of the MakingSoaWork blog).
But most of the IT failures in the world today, whether they are SOA implementations or traditional, “waterfall method” software development projects, occur primarily because of unclear goals and expectations. Again, going back to the SOA Maturity Model, it can be seen that SOA must be implemented slowly and deliberately in order to deliver not only long-term results that lead to the ultimate SOA ecosystem, but as short- and medium-term results that make a quantitative, measurable, and positive impact along the way. This approach gives business proof-positive that SOA delivers results, thus encouraging them to move forward with more in-depth SOA investment.
3. It is Impossible for SOA to Deliver 100% Unified Data
The thrust behind Service Oriented Architecture is the unification and intelligent sharing of data, and linking disparate systems together to allow this flow of data sharing to happen. SOA naysayers will tell you that data unification is rarely achievable with SOA, and because of this, it is a waste to invest in an SOA structure that cannot truly deliver on this promise.
No one in SOA will argue that each data integration project poses unique challenges, and sometimes getting disparate systems to communicate with one another is either impossible or requires such a sophisticated system that it runs of risk of being too expensive to create and manage. Even still, pushing these kinds of problematic data sharing nodes can also result in “dirty data” that would negate the value of SOA as a whole.
However, successful SOA implementation isn’t necessarily an all-or-nothing proposition. The SOA Maturity Model, which allows businesses to enter it at whichever stage they currently find themselves in, also concedes that businesses will exit the maturity model at different stage as well. Not all businesses are called to achieve SOA nirvana. There very well may be data sharing challenges that SOA cannot bridge – but the end result is always bound to be exponentially more streamlined and agile than what an organization with no SOA has in place.