To help answer these questions I will present four areas of value mature enterprise integration should promote.  In this thread I want to focus on the first.  It’s what I believe is the one of the most significant challenges facing your enterprise IT landscape today – Real Time Data Access.  Sometimes mistaken for just connectivity, together with R/T DA it becomes the life blood of integration.  You see just because you can call an API, read from a database or parse a file (all connectivity problems) does not mean you can “understand” the data.  It’s like getting on a conference call where everyone speaks different languages.  Is then the conference call even valuable?

You may argue you can pick up some things in inflection like attitude or seriousness, or maybe even jot down words to translate later, but no way can you really get out of that meeting what you would if they were speaking in a model you understood.  Your ability to react real-time to the conversation is removed: ask questions, comment or even take it in a direction most interesting to you.  For SOA it is no different.  R/T DA grants you both instant access and the understanding to engage in the conversation and get the most from your IT communications.

The integration message for Executive Management is about driving business functionality by enabling real time data access.  Here are six attractive topics that will resonate with both management and business users alike.

Data Connectivity

Although I purposely intended to diminish the value of “just connectivity”, it is joined at the hip with R/T DA.  With SOA today, we embraced the vast sea of interface options allowing your business to grow with little concern about application framework, technology stack or legacy abstraction.  This should now be fundamental and universal.  Whether it is a Mainframe or JBI, IT organizations should stop treating connectivity like its some untamed wild beast.  Embrace the heterogeneous environments and let true business decisions drive application selections not fear of missing core competencies.  The most basic value-add on SOA is to enable software functionality not possible without it.

Data Purity

Now that you can see the data (connect), you can verify and validate the data.  The former may be a series of tests ensuring you are looking or transferring the “right” data and the latter certifying its “legal” data.  Data purity is at the center of interface management, SLA compliance and stability.  Being confident in your data as well as now having the choice to cleanse or de-dup where appropriate can often be considered a major win in and of itself, and rightfully sits in the forefront of SOA ROI.

Data Enrichment

The most concrete value from data access in general is data processing.  In today’s world of R/T transactions, I favor the term data enrichment putting the emphasis on the data model rather than the business processing.  Enrichment primarily describes two types of utility often necessary for the business: Processing Engines and Entity Substantiation.  Engines are needed as “black boxes” of logic or computations critical to substantiation.  I am the first to advocate that wherever possible externalize functionality into meaningful and flexible business processes or leverage such functionality by consuming other end-system services.  However there is a place for exposing internal logic for computations that are more static.  I suppose in one sense these can been as fancy more “business visible” transformations like calculating balances, determining dates or shipping rates based on the current data entity.  This leads me to entity substantiation, a concept I use to put an emphasis on populating data entities that represent your business not just the transaction.  A true CDM will provide business entities available for transactions; in turn they may span multiple end-systems (or systems of records) and therefore require data enrichment to build out or substantiate that model.  The precursor to effective Complex Event Processing (CEP) is a valuable complex event – or maybe better stated a “complete event

R/T Decision Making

Decision making is useful and performing it real time to alter the business process path can be “wow”ing.  Think of airlines that readily change their rates per seat based on availability, incoming demand, and physical plane capacity.  Or campaign management that involves changes promotional discounts based on specifics of the sale.  Imagine advanced computations that detect potentially fraudulent transactions by scanning though past history and comparing to current events.  These are all pockets of extremely valuable logical processing engines – made possible with rich and pure business entities flowing through your integration layer.

R/T Business Intelligence and Trending

What happens when decision making meets business intelligence?  How about forecasting volumes spikes using advanced CEP signifying potential resource limitations?  Trending can now become something real-time you can baseline daily or hourly as opposed to the typically longer cycles.  This power combined with process automation (to be discussed later) can now help correct or prepare for the business events previously considered “unexpected”.  In short, the more real-time coupled with the more sophisticated you become in analyzing the data and trends important to you, the more accurate your predictability can become.

R/T Reporting and Monitoring

Sure we can do SLA metrics, reconciliation assessments, and KPI summaries today.  Now think if we could get those reports on-demand in intervals of minutes, real-time as they are happening.  Suddenly those executive dash boards and charts become alive and curiously give off a magnetic aura we are all drawn to.  “Oh, so that’s what happening!  I see it now.”  Again tie this data into a well-design exception handler (more on this later) and you have the potential for that self-healing infrastructure that can give operation guys a good night sleep.  Gone can be the days where the system itself inflicts more pain on the enterprise than the users, allowing its own transactions to bring it to its knees.

More then Just a Connection

Consider your internet connection (Information Bus).  Even with best throughput, it means little without a web browser (System Interface).  Add your browser of choice and you are not going very far without specific web addresses or Google (Service Discovery and Definitions).   Once you determine your desired URL, you then need to manage potential user credentials, maybe even VPN requirements and at a minimum play tip-toe around your local anti-virus software ensuring you can even get access (Governance and Security).  If you are lucky enough to make it through all that, you land on your page of information and then what?  Well in today’s 2.0 world of portals, viral advertising, RSS feeds, blogging and other “features” designed to provide data; you quickly navigate and disseminate (Process Engine) to extract the thoughts that are the most important to you.  So you still think you can get around with just connectivity?

Maturity Model

So is SOA about connectivity, or the data?  Is about interfaces or standards?  Does it have anything to say about governance or process improvement?  SOA is a guideline to all these challenges and purports to deliver a clear roadmap to tying these concepts together.  Oshyn’s approach is one that boxes SOA into distinct degrees of maturity growing an integration landscape from the “Connected-App” to the “Complete-App”.

Every integration project starts with the need to connect.  Delivering a Connected Middleware Application is valuable but is greatly limited in its overall enterprise relevance.  Its value increases significantly at this point in a ratio indirectly proportional to its maturity.  It’s a rite of passage from the Connected-App to the Consolidated ESB Application, but one that immediately demands attention from the business community (after all its their attention we want – they hold the budgets).  From there, the proposition evens out, where each step adds the as much value as the next.  What this diagram does not show is level of respective efforts.  In truth, the amount of work to move from step to step is more of a function of architecture (understanding SOA as a collection of practices) than it is anything else.  A properly planned, designed and executed SOA should be able to move through maturity model with increasing efforts – not decreasing where the first step is this insurmountable endeavor, but just do it so you can reap all these benefits a year down the road.  Quite the opposite, SOA infrastructure is fairly straightforward and with current toolsets fairly easy to implement.  SOA Value-Add can typically involve much iteration to get it right from designing the Enterprise Service Layer (ESL) to agreeing upon composite application ownership and scope.

The Evolving App

The Connected-App is just that – an application landscape that is able to cross-communicate.  The focus is on both interface management and data modeling.  This is the first degree of integration maturity – data level problem solving.  Here we apply adaptor patterns, common data models (CDM) and mapping translations along many other techniques to achieve enterprise plug and play.

The Consolidated-App is maybe the most critical maturity milestone to reach, and interestingly often of the most overlooked – in favor for delivering the “Composite-App” as soon as possible.  However doing so will also most certainly be a recipe for low ROI ignoring the most significant advancements in integration from the last decade.  Consolidation origins are birthed out the evolution of data-level integration through message and event driven interoperability to true process execution.  Consolidation is to solidify and unify an integration landscape with both message and process architecture that defines the organization scaling across the enterprise.  The focus here is not just the use of an ESB, rather defining its place as simply an enabler for the events that make up the process, with the emphasis being on the later.  Integration maturity and, in turn SOA ROI, is as much about process engineering as it is connectivity.

The Composite-App is the SOA playground.  The next step with plug and play processes is to leverage them.  Often touted as agility, the composition is the icing on the integration cake enabling those rich and necessary consolidated business processes to be used over and over in a multitude of use cases.  Truly this is the “service” oriented allure of SOA – its technical versatility to provide value to the ever-changing business.  Composition is a landscape where the library of services and access to the system’s they represent allow the freedom of erecting powerful business solutions quickly despite technology stacks (new or old) that are part of your organizations core competencies.

The Complete-App is a today’s representation of a mature integration landscape.  As with any software deliverable it must be production ready and enterprise robust to withstand the flurry of diverse transactions it is to encounter.  For SOA this can take on various forms to meet the needs of industry verticals, but usually focuses on one more of the following: Business Activity Monitoring, Policy Management and Governance, Security measures as well as actions for High Availability (HA), High Performabilty (HP) and what I call High Maintainability (HM) for production support.  The most mature SOA implementations include all of the above as implicit architectural decisions early on as opposed to add-on after thoughts.

At this point it is essential to note, that maturity model expressed here is not meant to be understood as a project plan methodology.  As a matter of fact, if a integration project was to start by delivering the “Connected-App” without first architecting the “Consolidated App” as well as defining the “Composite App”, that project has little hope of delivering ROI on its SOA, and has taken a time machine backwards doomed to make the same mistakes that eventually made speaking letters E.A.I. forbidden and punishable.