Start Small for SOA

This article brings up an interesting point that it may be best to start small when it comes to introducing SOA to an enterprise. While the initial reaction maybe to begin with projects that are high profile, oftentimes without the cooperation from the IT and business departments such projects have the potential to lead to frustration, and ultimately may make individuals feel that SOA failed. To prevent this feeling, it could be beneficial to start on smaller projects where there is plenty of cooperation in order to build “momentum”. With one successful project, it becomes easier to show the benefits in order to gain cooperation on the second, and thereby gaining trust in the usefulness of SOA for organizations.

The Government’s Incremental Move Towards SOA

This latest post on the SOA Network details how the latest report from Input, a leader in the authority of government business, discusses that the government’s growing adoption of SOA practices will fundamentally change how it delivers internal citizen-facing services. The federal market can benefit from increased agility and better IT alignment that SOA brings to the table.

Deniece Peterson, senior analyst at INPUT mentions:

"SOA shifts the concept of the application into a highly dynamic and fluid marketplace of plug-and-play services. A function previously performed by one vendor's application could now be completed by a number of discrete services provided by a multitude of providers. The standardized environment required to make this happen could severely impact the provider who relies heavily on proprietary elements for competitive advantage."

It is still early in the process to see a dramatic change in the federal SOA market as SOA solutions are slowly being integrated into the customer’s environment. The findings from Input can be found here, “Service-Oriented Architecture: Implications for Government and Industry”.

Reasons Why People are Responsible for SOA Failure

Mike Kavis from Techworld posted this informative article on what makes SOA fail in businesses. In summary he provided these 10 reasons of why people are responsible for the failure:

1. Fail to explain SOA’s businesses value
2. They underestimate the impact of organizational change
3. They fail to secure strong executive sponsorship
4. They attempt to do SOA “on the cheap”
5. They lack the required skills to deliver SOA
6. They have poor project management
7. They think of SOA as a project instead of architecture
8. They underestimate the complexity of SOA
9. They fail to implement and adhere to SOA governance
10. They let vendors drive the architecture

It was interesting to see his opinion on what needs to change in the way in which people incorporate SOA into their respective organizations. What are your viewpoints on what makes SOA work in the workplace? Can you think of any improvements you would recommend for individuals within companies?