SOA vs. SOA
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
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