Enterprise Architecture Demystified

Sethuraj Nair’s Enterprise Architecture Thoughts

Archive for the ‘EA Requirements’ Category

EAI, EDI, Convergence (and Convenience ! ).

Posted by snair007 on July 27, 2008

Integration Methodologies: Melting Frontiers Or Age of Divergence ? – Part II

 

In the first part of this discussion, we have seen quite a hatful of interesting jargons and acronyms ‘basking’ under both EAI and EDI, the niche of each is apparently unique and delimited. There are overlaps – pardonable ones. But our core discussion is not on these subsections anyway; we are here to know how appropriate it is to address data and application integration problems separately, where they converge – if at all- , and where down the road the industry and integration solution providers want to see each of them.

In IT architecture, the greatest rule of thumb says that if a problem baffles you, state it in business terms before addressing it. Our problem thus reads as to (1) what the users want to see after integration and (2) how far data and application integration methods can work together or in isolation to bring about what they want to see. So, yet again, it all boils down to the obvious center of enterprise universe – requirements.

Here too, the classical classification of requirements is invariably applicable – ‘business’ and ‘technical’. (I would always choose to call them more broadly and sensibly as operational requirements and enabling requirements – but that’s another discussion, anyway). Assuming that the business requirements heavily depend on the pertinent domain, and that it is not all that worthwhile to delineate some across-the-board pattern in business requirements that drive the integration, we’d better focus on the technical ones. But it will be even better if we combine the requirement in a need-and-fulfillment model. Let’s do that.

Hitting The Object(ives)

So, what is it, in simplest terms, a typical enterprise ‘E’ expects out of enterprise integration methodologies in general and how these methodologies meet the expectations?

·          To integrate business processes by facilitating enhanced interaction among ‘relevant’ enterprise components in IT spectrum (data, departments (business units, sub- organizations), actors( human resources), applications, interfaces, locations, services, sub-processes, functions, standards, rules  and infrastructure).

·          To broaden the business perspective across the enterprise by collating/ aggregating/re-organizing/re-structuring/re- representing relevant enterprise data segments.

·          To widen the ambit of enterprise’s functional standards, business policies, operational rules and governance models by unifying/centralizing/federating the hosting and management of business rules.

·          To assist effective and seamless co-ordination/mergers/amalgamation processes among business-units by improving connectivity, inter-operability and communication across disparate platforms and technologies.

·          To improve the enterprise’s adaptability to changes in line with business goals and objectives by establishing enough  ‘channels’  in terms of configurable mappings between business logic and technology for efficient change- propagation.

·          To optimize the efforts involved in altering(adding/removing/updating) an ‘enterprise component’ by optimizing degree of coupling among components

·          To reduce the cost of maintaining and scaling the enterprise IT framework by standardizing and reusing enterprise-wide interfaces or other middle-ware infrastructure and by reducing the number of “point-to-point” connections.

·          To ensure functional and informational consistency in the enterprise by unifying/standardizing transferring protocols in tandem with an increased usage of business semantics while defining interfaces.

Now that we have seen the expectations of integration, we are in a very good position to sum up the “KSAs( Key Solution Areas)” that could be used to appraise the role and effectiveness of integration methodologies to position them accurately :

·          Process Orchestration  : Components’ Coordination (broadly : Functional Co- ordination)

·          Enterprise Perspective : Data Organization

·          Governance : Business Rules Management

·          Business Scalability and Technology Portability : Platform Independence

·          Agility/Change Management -: Change-Propagation

·          Agility/Flexibility  : Coupling Optimization

·          Cost Control: Interface and Components Reusability

·          Consistency :Message Standardization

 

EAI to Bear The Torch

The distribution of applicability of EAI and EDI methods (that we have seen in Part-1 of this discussion) across each of these KSAs would look somewhat like this:

·          Components’ Coordination  – EAI , EDI

·          Data Organization – EDI

·          Business Rules Management -EAI , EDI

·          Platform Independence EAI , EDI

·          Change-Propagation-  EAI

·          Coupling Optimization – EAI

·          Interface Reusability – EAI,EDI

·          Message Standardization  – EAI , EDI

 

This is as much an interesting result as an important one. EAI by its definitions and for all its accepted forms/types can be found to be ‘wider and deeper’ in its scope. In other words, EAI turns out to be a definitely broader area, or at least to be more significance to the enterprise in terms of meeting its expectations out of  consolidating its  IT ‘ingredients’.

EAI also has its firm footprints on many layers of integration where data integration methodologies lack obvious and explicit applicability – be it Presentation Layer and Network Layer ( No, not OSI reference – just the implementation layers). If someone wants to adulterate the scopes and definitions to argue otherwise, well – s/he should be an awfully loyal EDI fan. Recommended 3-step algorithm for him/her  is –  start with that assumption , use Reductio ad absurdum and get disappointed.

Shared Pains

 Sarcasm apart,  there are a lot of common integration problems where there is enough room for solid give-and-take between these methodologies. Some of them are,

·          Need for Independence/transparency of platform heterogeneity

·          Data Exchange Requirements and formalized Data Formats.

·          Need for message integration and workflow management

·          Need for Control and coupling

·          Usage of common business integration middleware.

·          Repository-driven Meta Data management requirements

·          Need of Federated Models (in some scenarios)

·          Common security challenges.

·          Distributed data manipulation and concurrency control.

·          Usage of integration assistants like APIs, XML,RMI Service Interface standards such as WSDL and HTTP/SOAP.

·          Desired common traits of integrated framework include Scalability, reliability, consistency and availability.

Role Convergence  

To hone our discussion, we need to have a look at two more distributions – this time to affirm the activity-overlaps across the integration methodologies :

(1) Distribution of EDI presence across EAI categories : The amount of Data Integration activities typically performed as part of the majot EAI types we have seen in Part-1 of this discussion (Functional Integration , User Interface Integration and Data-level integration)

 

 

(2)  Distribution of EAI presence across EDI categories : The amount of Application Integration activities typically performed as part of the major EDI types we have seen in Part-1 of this discussion (( EDR,ETL,ECM,EII,MDM,CDI,BPI and EAI itself))

 

Conclusion

Presence of several monolithic integration approaches may slim down over the years as evolving paradigms would either supersede them or make them completely redundant. Still at lower strata of activities, these changes would prove to be nothing more than surges of ‘terminological feats’ , for, from an Enterprise Architecture perspective, both Application and Data Integration methodologies will forever be considered as key enabling techniques for all broader enterprise technical programs such as mergers and acquisitions, strategic architecture reorientations, SOA implementations, service clustering, business process integration and enterprise activity monitoring.

A good example is what the enterprise integration arena has seen with the advent of ESB or SOA – many schools of thought preferred to see them in mutual exclusion with EAI.  EAI, despite its terminological advantage in terms of ‘interpretive flexibility’ that should have qualified it to be considered as a functional superset of even SOA, was demeaned to deal with sheer point-to-point integration (hub-and- spoke, at best). Fact of the matter is that SOA as a conceptual framework and ESB as a middleware infrastructure ( or as a common information model) could all be a part of EAI union that should help a grand classification of like-minded models. But then,  the proponents of each new model want to see them in isolation, properly insulated from the ‘adulterating  influence’ of their less sophisticated technological ancestors. So things never so happened that SOA had been added to EAI concepts, but rather, SOA has been ‘introduced in place of’ EAI concepts. Of course, only then it’s convenient to present the world with a roadmap so strikingly titled as ‘From EAI-to-SOA’!

My feeling is that EAI is the only term with enough historical and semantic potential to accommodate ESB-based approaches, most of data integration methods, Composite/Federated Applications, Saas, Service Oriented approaches as well as those “inter-silo mashups” ( for which EAI is unfairly synonymous with). I am hardly a name junkie, but I do believe that consistent categorization and evolutionary traceability are important – very important.

Posted in Architecture Process, Data Integration, EA Requirements, Enterprise Application Integration, Enterprise Architecture, IT Architecture | Tagged: , , , , , , , , , , | Leave a Comment »