Who doesn’t love debating software architectures? After a long day at the office, there’s no better way to decompress than hanging out in a pub with your peers loudly arguing about, say, whether mobile apps are better when built native or browser-based. Last week, we spent the entire Ohio State vs. Siena matchup (BTW, who won?) discussing whether to include a row-identifying GUID in our clustered indexes. It was fun – and the other patrons kindly gave us plenty of debating space. After an hour or so, the bartender was completely relaxed, sitting on the floor, ear against the dishwasher, asking us to please move on to politics.
SOA – Service-Oriented Architecture – is a reasonably simple concept the software industry has now begun blowing to bits. There is an active debate about whether SOA really works. We like to associate our products with SOA, so that’s a debate that hits our radar. It turns out that terminology is colliding, which is adding to confusion – if you like metaphors, here is a picture. So debating SOA needs to start with knowing what it is.
In talking about SOA, my advice is to separate SOA into “service-orientation” and “Big SOA”. The first is an application design approach used by many smart people (yes, including this company). The basic goals of service-orientation are:
(a) to make an application easily accessible for diverse callers and
(b) to segregate the application’s capabilities from business processes.
Big SOA started as a simple methodology to put multiple applications under a single IT umbrella architecture, but has now become responsible for the emergence of a complete industry. That industry is dominated by large vendors and even larger customers, which is where the name “Big SOA” comes from.
Big SOA is about wrapping all of your enterprise applications inside an overarching set of software and tools to create a “single system view”. In practice, this is often an expensive and complex undertaking. Truly incorporating all your critical systems means changing things that already work (always a red flag). Success means you’ve fooled a bunch of dissimilar constituent applications into unknowingly working together. But business situations can change more violently and in shorter timeframes than expected. Sometimes the resulting system is more fragile than the original approach. So, the software industry is actively debating whether Big SOA projects result in enough value.
Personally, I don’t really care how this part of the debate turns out. Our priority is to make an application that, ideally, avoids the situation altogether. Implementing an ERP system does not require a Big SOA project. But for our customers who have a SOA mindset, our app should be the best possible citizen in that strategy.
When Epicor talks about being service-oriented, we are describing product features built on six pillars:
- Individually-addressable components (900 of them)
- Standard wire protocols
- Customizable components
- Configurable BPM (to control/re-sequence logic)
- Engines for global operations (rounding, tax, books, etc.)
- Distributed data (multi-plant master data management or simple replication).
So, let’s be crystal clear. Big SOA involves bringing together lots of applications. Service-orientation, on the other hand, is an architecture for building a single application. Service-orientation predates SOA, but companies that sell Big SOA – ESB toolkit producers and the large consulting organizations – succeeded in branding “SOA”. They can have it, especially now that the industry noise seems to be turning against how Big SOA projects are designed and executed. Our priority is to continue improving features based on the pillars mentioned above. On top of that, our emphasis is now focused toward resource-based access to the system as opposed to the traditional interface-based APIs. I’ll be describing that (hopefully) in the next post.
Posted by Erik Johnson, Senior Director of Product Research, Epicor