SOA is the next step in software engineering. The service-oriented paradigm comes to an increasing degree of maturity roughly 5 years after what I consider to be the start of serious corporate adoption.
We migrated from procedural computing to object-based and object-oriented computing. Then we moved to improve the state of objects with component-based software engineering. Now, we have evolved our best-practices as an industry and in academia and have moved into the era of service-oriented computing.
The gradual adoption and service maturity can be seen to move along a spectrum we have depicted in the Service Integration Maturity Model.Here we have seven levels of maturity across 7 dimensions from infrastructure to the business architecture.
The implication of this paradigm shift is that the best-practices of service orientation need to be integrated into the fabric of software engineering to be utilized on projects that (this is important, so you may want to mute the TV for a second) SOA may either not be part of it or a very small part of the project. Still, you would use SOA PRINCIPLES such as using the service model for a specification of the required functionality within a project or an enterprise.
What are your views on the use of SOA principles on non-SOA projects?