How do I know whether I should adopt SOA as a strategy?

How do I know whether I should adopt SOA as a strategy?

Because it is an architectural strategy, Service Oriented Architecture SOA involves much more than merely building software. Creating an architecture based on a portfolio of services asks that CIOs make a compelling case for enterprise architecture, a centralized development methodology and a centralized staff of project managers, architects and developers. It also requires a willing CEO and executive staff to pave the way for IT to dive in to the core business processes of the company. Understanding those processes and getting buy-in on enterprise sharing are the keystones of Service Oriented Architecture SOA-based business transformation.
Governance is critical. For services to be reused across the company, there must be a single, centralized software development methodology so that different areas of the business don't build the same service in different ways or use linkages that are incompatible. There must be a centralized warehouse, or repository, so that developers will know where to look for services—and so IT will know who is using them. The services must be well documented so that developers will know what they are for, how to link to them and the rules for using them. (For example, some companies charge fees to use the services and create performance agreements to make sure the services work well and don't put too much load on the corporate network.)

Most companies that have progressed along the path to Service Oriented Architecture SOA have created a centralized architecture group to choose processes that will be service enabled and to consult with different areas of the company to build the specific services. The centralized group also creates a convenient mechanism for governance. If all service requests have to go through the architecture group, the service development methodologies, projects and performance agreements can be more easily managed.

The companies that have had the most success with Service Oriented Architecture SOA so far are those that always have success with technology: big companies with big IT budgets whose business is technology-based (think telecom and financial services). They also tend to have supportive, technologically sophisticated business leaders. For companies without these advantages, SOA may not be the panacea it’s being made out to be.

For smaller companies, for companies that have made big bets on integrated application suites and for companies that already have solid application integration strategies in place, SOA isn’t a "when," it’s an "if." CIOs need to pursue an Service Oriented Architecture SOA strategy carefully because the service development and architecture planning pieces of SOA are distinct but not independent—they need to be considered and executed in parallel. Services built in isolation, without taking into account the architectural and business goals of the company, may have little potential for reuse (one of Service Oriented Architecture SOA’s most important benefits) or may fail outright.

Source: http://www.cio.com