Debunking the myths of SOA

Daniel Magid, Aldon Inc

Is service-oriented architecture (SOA) over-rated or one of the most important IT developments in recent times? Daniel Magid, president and CEO of Aldon Inc., takes a closer look at SOA and the reasons why it’s everywhere.

Do you think service-oriented architecture (SOA) is overhyped? Do you think you will just buy it and install it once the market matures? Or do you think your organisation will pass on SOA altogether and find a better way to accomplish the same thing?

If you answered yes to any of the above then you have officially fallen victim to some of the most prevalent myths about SOA. Today you are also most certainly not alone. In fact leaders in both business and IT are subscribing to many of the same beliefs about SOA. Unfortunately many of these beliefs are misguided.

It is critical you gain a clear understanding of SOA now, as analysts and industry leaders all agree that SOA is the single-most important IT initiative in the last decade. It promises new levels of innovation, sharpened business agility and key competitive advantages.

Myth 1

SOA is a technology.

SOA is an architectural concept. It is the way companies weave applications and processes together in a flexible manner so that they can reuse them. Think of SOA as a software development style that allows applications to be assembled from reusable components instead of being built from scratch.

If 'regular' coding resembles building a house, SOA is like putting a prefabricated house together in the sense that the pre-built pieces just have to be connected. A more technical definition might be that SOA is a collection of services that communicate with each other through standard interfaces.

The services are self-contained and do not depend on the context or state of the other services, and they work within a distributed systems architecture.

Myth 2

SOA will add complexities to my already complex IT environment.

SOA is about simplifying complexities. Rather than recreating every part of a software system from scratch, SOA lets you rapidly assemble pre-designed, prebuilt and pre-tested components into powerful new applications.

With SOA, application boundaries can be extended to include functions from anywhere inside or outside of the organisation. With SOA you plan, develop, manage, deploy and share automated services from a completely open IT architecture.

An SOA architecture helps you quickly and efficiently change applications to respond rapidly to evolving business and market requirements.

With SOA, you:

  • reuse application logic;
  • link business and IT through the adoption of standards;
  • eliminate redundancies;
  • link and leverage systems across the entire enterprise.

Through the use of interchangeable, reusable parts, standard containers and open interfaces, SOA should actually simplify application development and maintenance. Any complexities associated with SOA aren't from SOA itself but are more about changing how we think about software.

Myth 3

I'm using web services already so I must be doing SOA.

Even if you use web services and apply object-oriented approaches, you may not achieve the kind of loosely coupled, autonomous and reusable components that are essential to true SOA. Web services specifications have sped the enablement of SOA by defining a common, accepted style of interaction necessary to implement and expose services.

By using SOA to design distributed, enterprise-wide, market-driven applications, businesses can expand the use of web services from simple client-based functions to systems that better harness much of the latent potential and functions buried in legacy systems. While web services play a role in SOA, they're just one piece of the equation.

Myth 4

I will have to throw out my legacy systems and start over.

There's no need to abandon what you already have. SOA helps you leverage existing data and application assets so that you can reuse them rather than recreate them. Services can be introduced incrementally over existing legacy applications, preserving your investment while letting you take advantage of new opportunities.

Myth 5

I should wait until SOA concepts mature before I start.

As more and more companies begin deploying services as the preferred method for communicating with customers and vendors, the risk rises that organisations failing to adopt these services will be left behind.You should view SOA like you view your application development - with a 'life cycle' - and start carefully priming your IT departments now.

Your competitors may be doing SOA to some degree. You don't want to find out the wrong way how far ahead they might really be when they start offering services to customers and partners that you can't. Start SOA projects incrementally with a focus on scale and extensibility. Initial projects can be small and focused, and should deliver measurable business value at the close of each project.

First your organisation must identify an overall business process addressing how services will be evaluated, built, tested, deployed and updated. Identify the most developed service-centric applications and leverage them into business services that align with the goals of your business.

Then you need to create an IT environment conducive to crafting quality SOA - one that provides a detailed inventory of resources as well as structured development processes. This is easy with software configuration and change management solutions, which provide visibility and accessibility to IT resources as well as the process management oversight required for proper execution of SOA.

Because services can be described almost entirely by their metadata, it is imperative to have this complete, detailed and accessible inventory so you can find and reuse those key corporate assets. The structured processes help you manage the services throughout their entire life cycle rather than only through the initial development and deployment stage.

Now you can start thinking about designing a robust, open solution for defining and enforcing those processes that will manage all the resources stored in legacy systems. Eventually you can retool your applications from the outside in.

Myth 6

IT departments develop SOA and the business side approves it.

Services development must be a partnership between IT and end-users. The appropriate encapsulation of business processes into services and the building of a services-oriented architecture requires detailed knowledge of how the business processes work, how they are used and by whom.

The most important initial steps for SOA projects have nothing to do with choosing or deploying software but rather with establishing a clearly defined plan with business and IT collaboration. To make the best use of services, a single point of management and control - an enterprise view of the entire application ecosystem - is critical.

Companies will continue to simplify and consolidate their IT environments. While this is a good idea in a traditional IT shop, it is imperative in one beginning with SOA.

A major part of doing SOA right is to carefully study each type of application and planning service that can be reused across a particular enterprise or with outside organisations.

Myth 7

SOA is easy.

SOA demands commitment and tenacity. Although SOA can be easy to build and deploy, it also poses challenges.

There's a constant pull to meet new IT and business needs using the quickand-dirty approaches of the past. Sticking to SOA approaches and standards requires ongoing discipline, strong governance and support from rank-and-file IT and business managers as well as top executives.

The ease, rapidity and potential breadth of SOA implementation also means that a coding mistake in SOA, like in any other enterprise-wide IT endeavour, can wreak havoc on your business in a short space of time. Because applications are speaking directly to each other and increasingly performing transactional updates on their own, an error in an SOA application can extend farther than one in a more traditional environment.

Businesses must be willing to take responsibility for proper planning and management. Implementing best practices in design will ensure that systems are easily adaptable.

Myth 8

SOA is over-hyped.

SOA is everywhere for very good reasons. Analysts agree that SOA is the single-most important initiative in the last decade, and organisations need to embrace it or be left behind. Think like the eBay, Amazon and Google people, who clearly know the difference between hype and reality, and who are already successfully executing SOA projects.

Or fade back to the early 1990s and try to remember the names of the companies that thought the web was over-hyped. Their doors are now closed.

Daniel Magid is president and CEO of Aldon and a recognised authority on SOA and application lifecycle management (ALM) solutions. He has written a variety of articles for leading IT publications and is a regular speaker at technology conferences. Before becoming president, Daniel held several executive sales and marketing management positions at Aldon.