7 Things You Need to Succeed at SOA

Service-oriented architecture (SOA) has a lot to offer when it is understood and its principles applied consistently and incrementally. In fact, it forms the foundation for cloud computing.

As an SOA instructor and consultant for many years, I have seen many organizations struggle with SOA adoption. SOA adoption is an organic, evolutionary process; and it is unique to every organization, since every organization has a unique combination of culture, business, and technology. Here are what I believe to be the most important factors that impact whether you will succeed or fail at SOA.

1. Buy-In from Senior Management

Let me put this very simply: If you do not have support from upper management for your SOA efforts, and if they do not share your long-term vision, you will not succeed, so don’t even attempt it.

2. Education First

In every case where I have stepped into an organization that claims to be “doing SOA,” I have discovered a large degree of ignorance and many misconceptions around what SOA is all about, why it is needed, and how to go about doing it. The solution: Educate the organization. Include a full vertical slice in the scope of this effort—from testers, developers, and programmers in IT, to business analysts and sales reps, all the way up to project managers and the executive team. Be sure to include representatives from both the technical and the business side of the organization. This is critical. Without a shared language and vision arising from a shared understanding of SOA, communication between technical and non-technical people will not be effective, and a dysfunctional relationship will be the result.

Of course, you must match the type of education to each role. Formal SOA education can effectively bridge the business/IT gap and is the first step towards creating a productive environment where SOA can thrive.

3. Standards Next

A large part of what SOA is all about involves a strong commitment to the use of enterprise-wide standards. I use the term “standard” in its broadest sense. I’m talking not only about technical standards, such as SOAP, XML, or WS-BPEL, but also about process and enterprise standards, such as TOGAF, ITIL, or PMI. It is important to establish and agree upon the standards that everyone must adhere to within the organization when contributing to an SOA.

4. A Small Start

Do not attempt to introduce SOA globally all at once. The amount of fear, uncertainty, and doubt (aka FUD) that would be generated among your employees would surely paralyze all forward motion, bringing your SOA journey to a screeching halt.

Everyone needs to feel comfortable with the principles and policies around SOA, and that can only happen gradually as initial suspicion and doubt give way to trust and acceptance.

So, start small. The best way to get started is to show SOA be effective and useful with a pilot project that showcases what SOA has to offer. The most effective pilot project will solve an existing issue within the organization, preferably something the business has been struggling with for some time.

5. An Incremental and Iterative Approach

Extend the success of your pilot SOA project by attempting a slightly larger or more complex one. Evolve your approach using the lessons learned from the pilot project; keep what worked and change what did not work. In this way, you build confidence in the approach, while honing both your understanding and expertise in SOA.

6. Remember: It’s All About Design

Many organizations believe that the path to full SOA adoption begins with the development of web services, typically as a way to layer a standards-based communication framework over an existing legacy API. They are not completely mistaken. This is known as the “bottom-up” approach and can be successful if it is handled correctly. More times than not though, this approach is mismanaged with predictable results such as:

Poorly designed and technology-dependent interfaces
Services that are two “close to the machine” and fine-grained, exposing deep technical details that create a tightly coupled system
Competing/duplicate services
Rogue services (services that were put into production without a mandate or by bypassing internal policies and procedures)

7. Governance Is Key

Governance is policy. Management is governance in action. In other words, it’s the enforcement of policy and procedures. Governance gives us control over the many artifacts that are generated when adopting an SOA. This control is paramount. Without it, we have chaos; but sometimes this chaos takes time to emerge and organizations have the illusion of control… at least for a while.

Retroactively introducing governance is more painful than doing so from the start.

Sometimes the idea of introducing SOA governance policy is overwhelming to organizations if they take the view that current policies need to be thrown out in favor of new SOA-based ones. This is never the case. Often, existing policies, procedures, and processes simply need to be tweaked to cater to this new service paradigm and all its associated artifacts. It is not a reorganization; it is simply extending what the organization already does into the SOA way of thinking, and it is imminently doable.

If you stay true to the principles of service orientation and ensure that everyone in your organization understands them, then you have a great chance of success with SOA, enabling your organization to be more adaptable and more agile and improving the quality of your services.

This content was adapted from the Global Knowledge white paper How to Succeed at Service-Oriented Architecture.

About the Author
Global Knowledge instructor Dr. Adrian M. Rossi has been an IBM contractor since 2003. An IBM Certified Instructor for WebSphere, SOA, and JEE, Dr. Rossi helps organizations by providing guidance and strategic direction on the use of SOA and BPM methodologies, techniques, processes, standards, and best practices.

Please support our Sponsors here :