Barriers to a successful SOA service oriented architecture project

Barriers to a successful SOA service oriented architecture project

If you're getting the idea that using service oriented architecture SOA principles will require more time and effort initially, you're right. While the basic concepts of service oriented architecture SOA are fairly simple to understand, actually doing the work required to architect a solution that uses service-oriented principles will require more effort than using traditional point-to-point methods to architect a solution.

We've already discussed some of the benefits of service oriented architecture SOA. While the promise and perhaps the hype will motivate many to undertake service oriented architecture SOA projects, several barriers can stand in the way of their success. This failure to achieve optimal results doesn't have to be your experience. Before you dive in to your own service oriented architecture SOA plans, consider how your organization will handle the following barriers:

Reluctance to collaborate across teams and organizations. Interdepartmental politics is one of the largest barriers to realizing a successful service oriented architecture SOA project. Such politics can keep teams from working together to define an architecture of services that may cross departmental boundaries. These services may in fact need to cross development team boundaries. Services also may require lines of business and IT to work together more closely than they may have before. To make projects succeed, development teams must be rewarded not only for how well they implemented their own part of the architecture, but also for how well those pieces participate in the greater architecture.

Unwillingness to learn a different approach and/or lack of background understanding. Many of us tend to cling to the known and resist shifting to the unknown. On the other hand, many architects and developers may be willing to learn but lack the basic education required to understand the service oriented architecture SOA approach. Architecting solutions using service-oriented principles will require both the willingness to learn some additional skills and the basic background needed to help acquire those skills. This means that if your organization is new to SOA, you should account for the need for education as part of your service oriented architecture SOA adoption plans. And plan for this education both in terms of the cost needed to ramp up, and the time needed to ramp up. Because service oriented architecture SOA is relatively new, formal educational opportunities will be few. As a result, many teams today are finding it most effective to learn through direct experience.

Focusing on technologies rather than architecture. It's tempting to immediately start looking at Web services and imagine how you'd start mapping existing functionality to service interfaces. Slow down—while some in the SOA field believe that it's effective to approach service oriented architecture SOA in a bottom-up manner, doing so can run the risk of creating services that are only of limited use in other projects. Jumping immediately to focusing on technologies also runs the risk of creating services that are less loosely coupled than may be desired.

Unwillingness or inability to make necessary investments. The nature of the business and the need to deliver solutions on a tight time schedule often makes it difficult to use service oriented architecture SOA, especially if you're starting from scratch. As we've addressed, you should expect to make a substantial initial investment in time and possibly in platforms and frameworks in order to realize benefits on your successive efforts. The worst situation occurs when business or IT teams launch an service oriented architecture SOA initiative without fully counting the cost. Acknowledging these costs and planning for them up front can increase your business' chances of launching a successful SOA initiative.

Taking on too large of a project. Avoid taking on more than you can handle at once. For instance, trying to convert an entire organization's application functionality over to an service oriented architecture SOA at once can be problematic. It is important to make sure you determine the appropriate services to enable based on potential cost savings, reusability and revenue. In other words, start small. Then build out your services in an incremental fashion. This will give you time to learn, succeed, and realize increasing returns on leveraging services you've already created.