The Council agreed and I prepared a proposal that the board would have to agree to, since it was going to radically change the product and would take time and money to implement.
They said "No, too risky"
What if they had said yes?
Several new acquisitions occurred over the next couple of years and if they had said yes, then those acquisitions would have much more easily been integrated into the product line.
A large percentage of the revenue for the company came from professional services doing integration work or custom solutions, and if they had said yes, all of those would have been easier, taken less time and made our customer happy.
So today, all these years later, they are still a monolithic platform with a bolt on SOAP/REST api, but the core product is basically unchanged.
SOA is no transforming a growing number of Enterprises into a coherent suite of services that can be composed into new applications, reused and integrated easily.In the recent past I was CTO of Corent Technology, where we built a product that allowed existing web applications to be converted from single tenant shrink wrapped applications into Software as a Service (SaaS) multi-tenant application. With applications built as SOA they would be much easier to convert either by Corent or by their own staff.
What other benefits would a SOA Based product have?
- The product would place a priority on business value over technical strategy.
- The product would more easily fit into the core Enterprise architecture with a strategic value beyond the initial application values.
- The product would be intrinsically interoperable with the other applications and SaaS solutions the Enterprise was using.
- The Shared Services the product would offer could more easily be used to augment, extend and customize the Enterprise solutions.
- The Enterprise itself would be more flexible and provide a better return on investment.
- With current cloud technologies, performance is obtained as needed with horizontal scaling, this allows optimization to be done at the service level instead of the application level greatly reducing the time and effort to build and deploy new applications.
Having one product that is SOA Based does not make an Enterprise Architecture SOA, but it can serve an an initial foray into SOA. If a SOA based product is also based on an Enterprise Service Bus (ESB) then that ESB can also serve as an integration platform for the rest of the Enterprise to use.
The Open Group has an excellent page devoted to SOA Features and Benefits at http://www.opengroup.org/soa/source-book/soa/soa_features.htm
CIOs should be adding SOA to their evaluation criteria for new products, whether build or buy. Today few Enterprise Applications offer true SOA, but many have seen the light and have at least added SOAP/REST interfaces. The day will come with entire software products are themselves based on SOA and when they do I am sure they will cause a paradigm shift to SOA.
Being really old, I can remember when products were developed in procedural languages, and Object Oriented Programming hit. It was a while before products started being designed and developed around OOP, and those that didn't make the transition largely went away. I predict that same evolution of SOA based products.