SOA and Enterprise Applications

By Adam White, Senior Consultant

It’s frustrating to see the consistent mistakes enterprise and solution architects make when implementing and supporting Service Oriented Architecture (SOA).  The most common one is co-opting functionality that comes with a packaged product as an enterprise solution.  

One example is using CRM workflow as enterprise workflow.  Most products nowadays  come packaged with workflow capabilities.  This means that events can trigger a process and that processes can interface outside of the application to activate other events. The first inclination of many enterprise architects is to utilize that functionality to support the enterprise-class business needs.  The problem is that the functionality that comes with the product is designed to support the product, not the overall enterprise. 

However, there are workflow products that support the entire enterprise. The easiest way to tell is by applying two trusted rules of thumb.  The first is by mapping your functional requirements.  You will see that by using this yardstick, product level functionality is different than enterprise level functionality.  And the second simple rule is if you replace your packaged application (say, your CRM application) do you also have to replace or rebuild your workflow?  The answer should be no.  If it’s yes, then you have incorrectly repurposed the product’s workflow functionality. 

This also occurs in the integration world.  Just because an ETL solution provides integration and can call a web service does not mean it’s the product to use for your core applications. After all, these are systems that support business operations, the systems that you use to process your day to day customer transactions.  In the end, it all comes down to fleshing out your requirements, and using the right tool for  the right job.