Modeling for Smart Ecosystem Architecture

In a new CBDI Journal report this month I have been looking at the modeling requirements to support our Smart Ecosystem Architecture (SEA) concept.

It is evident there are two major architectural patterns in play – service oriented and event driven. But in addition we need to recognize a new dynamic which we might characterize as “post enterprise” including cloud computing, Web 2.0 and so called smart IT that encourages ecosystem collaborations over internal enterprise processes.

There is a lot of superficial (marketing) noise suggesting a close relationship between Event Driven Architecture (EDA) and SOA, Actually the two domains are in practice islands of automation. SOA is much more widely used, whereas EDA is still largely restricted to narrow focus, point solutions. This is changing, but slowly as there are considerable complexities to deal with in an integrated world. Not least event data availability, architecture contention and difficulties in testing. Of course the solution to broader utilization is integrated modeling approaches.

Similarly cloud, Web 2.0 and smart IT are separate domains and narrowly focused and capturing the requirements for either still tends to exist in two separate domains. However, to recognize the real opportunities in the smart ecosystem requires us to take a more coordinated view of modeling that spans all of these considerations.

CBDI has a vast amount of business modeling guidance and advice; much of it has pioneered thinking around modeling services, events, capabilities, meta data, dynamic business intelligence and ecosystems. See for example the CBDI report series on Business Modeling for SOA that begins specifically with the event-response concept at a high level as part of business modeling , and the report Event Driven Service Architecture that examines the convergence of EDA and SOA.

In this new report Modeling for Smart Ecosystem Architecture I advise on how to integrate these different perspectives across the broader set of architectural views. We also explore the dual requirements to consider both events and services, and also consider some of the meta model impacts.

On that last point it is interesting to note the lack of any 'standard' meta model for EDA, and hence similarly the EDA/SOA relationship. Whilst OMG have been working on a RFP for an ‘Event Model and Profile’ (EMP), this has yet to be issued.
Today, the requirements are quite likely to be captured directly into a format prescribed by proprietary event management products used for the EDA implementation.

We are currently evaluating how we add the necessary concepts to support EDA and SOA convergence in the SAE Meta Model and our associated UML profile, and discussing how we may contribute to emerging standards activity in the same way as we have done with SoaML.