(work in progress, more coming...)
- A shift in corporate IT's interests and spending - with more frequent references to Cloud/Grid computing - and less mention of SOA.
- SOA Consultants, Vendors, Writers...will attempt to drive a whole new set of buzz-words, perhaps abandoning the term SOA altogether, as they struggle to generate Sturm and Drang in their quest to sell more software, articles, books, and generate billable revenue.
- UDDI will finally be recognized for the bloated pig that it is.
- Business managers will be driven to define an ROI for their SOA initiative before obtaining continued funding of the program.
- IT management of large-scale enterprise organizations will realize that they can't obtain the benefits of agility and reuse if their fundamental software development processes are still mired in chaos.
Premise: Many corporate IT departments are already stretched thin with existing obligations and responsibilities to support their existing infrastructure and deployed applications.
SOA is more complex.
The effort to establish, communicate, train, support, sustain, and manage the infrastructure necessary to implement a SOA-enabling environment is an additional cost - in terms of staff time and budget costs.
That additional complexity/cost/effort impacts the total cost required for the management of development, testing, and production environments.
That additional cost/effort will exceed the technical capacity and financial budgets for many IT departments.
Many organizations will be driven to offload the cost and burden to a 3rd party (Cloud/Grid vendors) - where the operating overhead can be spread across the subscriber base.
Premise: Without a strong perceived need/mandate for change, organizations are less likely to perceive a need for expensive consultants.
Observation: Too many consultants appear to be mired in waging religious debates over their differences in defining the The One True Definition of SOA. The focus of the conversation needs to be refocused on the business value - not on the techno-mumbo-jumbo.
Premise: The business need to get things done in as simple and painless a way as possible will finally convince the major SOA solution vendors that they need to deliver a registry-repository solution that is affordable, understandable, simple to use, and doesn't consume a significant percentage of the total SOA program budget. A "light" version of their products will be offered (which will more likely than not be based on a RESTful service model).
Premise: The cookie jar lid will be slammed shut on IT folks that just want to play with the latest software toys (just because it is "cool technology").
I am extremely doubtful of any SOA justification based upon the claim/expectation of a high-level of service reuse. Loose coupling, perhaps (if you spend enough time getting the semantics of the messsage models right).
Focusing on improving the processes and efficiencies of Enterprise Value Chains seems a better candidate approach for ROI justification.
Premise: If you don't have the fundamental processes nailed (e.g. Source Code Management, Iterative/Agile Development, Automated Testing, Continuous Integration Build, Issue/Bug Tracking, etc.) - then all that adopting SOA will do (with its greater complexity and number of moving parts) - will simply decrease the organization's agility and increase its inefficiencies.
