lustratus LiteBytes

The second Integration Consortium conference call on EDA was held yesterday – kicked off with a short presentation by Lustratus.

These conference calls are primarily discussions by practioners and how the discussion pans out can be very different to what might be expected at the beginning. Yesterday was no exception, the starting point was how to build a business case for EDA but moved to a more specific issue: How do you (and even should you) introduce the concept of EDA to an organisation already committed to and busy with a SOA strategy.

There is no simple answer to this: Much of what a good SOA programme brings to an organisation in terms of enterprise architecture and governance is immediately transferable to EDA. And I have previously written about how EDA can be used in conjunction with SOA. The more general issue is how do you translate a technical architecture into business benefit. Much has been written about this in the context of SOA over the last couple of years and it is easy to formulate generic approaches that sound plausible (my favourite in SOA arena is the recipe proposed by some that starts “get a senior management sponsor” – sounds easy, right?).

However at the end of the day, business cases are business specific and quite often EDA or SOA will slot into an unexpected project (as is highlighted by Mike Kavis here – ) because the capabilities EDA or SOA delivers match the project goals, not because having SOA or EDA is a requirement. If you want to get a EDA or SOA kicked off, it is often a matter of understanding the value delivered and matching these values to projects that have to happen anyway.

Ronan