Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

EAI: myths & reality


Published on

Presentation about Enterprise Application Integration at

Published in: Technology, Business

EAI: myths & reality

  1. 1. Levente Veres2012.08.30 @ Cluj-Napoca 1
  2. 2. Agenda What is EAI? The True Story. EAI frameworks EAI Patterns & Technics Toolset on Battlefield Myths & Reality The future 2
  3. 3. Whoami …What I do :• Design LeadPast:• Solution Consultant• Business Process Management• IT Manager, PM, Developer• System administrator, Freelancer Hobby: • Reading and apply: Leadership skills, Motivational approaches, Innovations • Continuous learningDont tell people how to do things, tell them what to do and let them surprise you with their results. George S. Patton 3
  4. 4. Organization vs Enterprise the organisation is a legal structure, primarily conceptual/physical in nature, defined by rules, roles and responsibilities – the organisation does – it provides action, ‘how?‘ the enterprise is a social structure, primarily emotive/aspirational in nature, defined by vision, values and mutual commitments – the enterprise is – it provides motivation, ‘why?‘ 4
  5. 5. Enterprise Application? Can you define? 5
  6. 6. Enterprise Application EA: is a business applicationComplex, Scalable, Distributed, Component based Mission-critical Used on different platforms Data centric & user friendly Stringent on Security and administration Hundred requirements must be satisfy difficult to understand or predict 6
  7. 7. The StoryAt the beginning : Data processing focus.• Collect the data (financial, numeric, statistical)On the way: Functional focus• Calculate the salary, bonuses, incomes• Create invoices, generate reports• HR problems resolve (Resource management)• Logistical/Provisional problems resolve (ERP)At the end: Process Focus• Enhance the business efficiency (BPM)• Predict more accurate the Income/Outcome (BPO)• Smart and fast decisions (BI) 7
  8. 8. EA base domainsBusiness architecture Information system architecture Technical architecture. Data architecture (IS) Application architecture (IS) 8
  9. 9. The Time Line1960 1980 1992 1991 2001 2003development of A Framework for Extending and TAFIM -> ‘95 TOGAF OBASHI framework DODAFinformation Information Systems Formalizing the (The Open Group for Business and ITarchitecture by P. Architecture” Framework for Architecture digrams Department ofDuane (Dewey) developed by John Information Systems Framework) (Ownership,Business, Defense ArchitectureWalke Zachman at IBM; Architecture" John F. Process, Application, FrameworkThe architectural published in 1987. Sowa and John System, Hardware,documents base of Zachman Infrastructure)Business SystemsPlanning (BSP) Zachman Framework 9
  10. 10. The Zachman FrameworkFocus on fundamental questions What How Where Who When Why The The data The function The Network The people The time motivation description description description description description description • (Why) Goal List – primary high level organization goals • (How) Process List – list of all known processes Contextual • • • (What) Material List – list of all known organizational entities (Who) Organizational Unit & Role List – list of all organization units, sub-units, and identified roles (Where) Geographical Locations List – locations important to organization; can be large and small • (When) Event List – list of triggers and cycles important to organization • (Why) Goal Relationship Model – identifies hierarchy of goals that support primary goals • (How) Process Model – provides process descriptions, input processes, output processes Conceptual • • (What) Entity Relationship Model – identifies and describes the organizational materials and their relationships (Who) Organizational Unit & Role Relationship Model – identifies enterprise roles and units and the relationships between them • (Where) Locations Model – identifies enterprise locations and the relationships between them • (When) Event Model – identifies and describes events and cycles related by time • (Why) Rules Diagram – identifies and describes rules that apply constraints to processes and entities without regard to physical or technical implementation • (How) Process Diagram – identifies and describes process transitions expressed as verb-noun phrases without regard to physical or technical implementation Logical • (What) Data Model Diagram – identifies and describes entities and their relationships without regard to physical or technical implementation • (Who) Role Relationship Diagram – identifies and describes roles and their relations to other roles by types of deliverables without regard to physical or technical implementation • (Where) Locations Diagram – identifies and describes locations used to access, manipulate, and transfer entities and processes without regard to physical or technical implementation • (When) Event Diagram – identifies and describes events related to each other in sequence, cycles occur within and between events, without regard to physical or technical implementationThe Models • (Why) Rules Specification – expressed in a formal language; consists of rule name and structured logic to specify and test rule state • (How) Process Function Specification – expressed in a technology specific language, hierarchical process elements are related by process calls Physical • • • (What) Data Entity Specification – expressed in a technology specific format; each entity is defined by name, description, and attributes; shows relationships (Who) Role Specification – expresses roles performing work and workflow components at the work product detailed specification level (Where) Location Specification – expresses the physical infrastructure components and their connections • (When) Event Specification – expresses transformations of event states of interest to the enterprise • Rules detail for (Why); Detailed • • Process detail for (How); Data detail for (What); • Role detail for (Who); Representation • • Location detail for (Where); Event detail for (When). 10
  11. 11. TOGAF Business Application Data Technicalarchitecture architecture architecture architecture Figure 7. The TOGAF Architecture Development Method (ADM) 11
  12. 12. Where are we?Relationship between the Enterprise Continuum and the Architecture Development Method 12
  13. 13. Federal Enterprise Architecture (FEA) Published in September 1999 “ designed to ease sharing of information and resources across federal agencies, reduce costs, and improve citizen services” 13
  14. 14. Other Framework focus point MODAF DODAF OBASHI (base of NAF) Capabilities Integration and Strategic Viewpoint (StV) Ownership Development (JCIDS)Planning, Programming, Budgeting, Operational Viewpoint (OV) Business Process and Execution (PPBE) Service Orientated Viewpoint (SOV) Acquisition System (DAS) Application Systems Viewpoint (SV) Systems Engineering (SE) System Acquisition Viewpoint (AcV) Operations Planning Hardware Technical Viewpoint (TV)Capabilities Portfolio Management All Viewpoint (AV) Infrastructure (CPM) BPM, BTO, CM, ITIL, ITS … 14
  15. 15. What & where :Top 10 15
  16. 16. RUP & TOGAFMore at: 16
  17. 17. What we integrate? 17
  18. 18. What is a integration? In engineering, system integration is the bringing together of the component subsystems into one system and ensuring that the subsystems function together as a system. In information technology, systems integration is the process of linking together different computing systems and software applications physically or functionally, to act as a coordinated whole. 18
  19. 19. But the EAI?Enterprise application integration is an integration framework composed of a collection oftechnologies and services which form a middleware to enable integration of systems and applications across the enterprise. lack of communicatios Inefficiencies identical data are stored in multiple locations unautomatizable processes Existence of information silos Inefficient business processes 19
  20. 20. Why we need EAI?Purpose  Data integration  Transaction management  Process integration  Security management  Vendor independence  Multiple Technology  Common FaçadeBenefits Real time information access Streamlines business processes Integrity across multiple systems 20
  21. 21. EAI: Patterns & Technologies Patterns Topologies• Integration patterns • Hub/spoke • Mediation (intra-communication) • Federation (inter-communication)• Access patterns• Lifetime patterns EIP - Camel: • Bus Technologies• Bus/hub• Application connectivity • Point 2• Data format and transformation Point• Integration modules• Support for transactions 21
  22. 22. The interpretationsPoint-to-point integration Broker-based integration ESB-based integration 22
  23. 23. Integration ModelsInvoking Services Accessing Services Coupling Method-based Synchronous Tightly Coupled (COM/CORBA) Message-based Asynchronous Loosely Coupled 23
  24. 24. The languageMessage/event • SOAP: Simple Object Access Protocol • WSDL: Web Services Description Language oriented: • UDDI: Universal Description, Discovery and Integration Workflow • BML: Business Modeling Language oriented: • BPMN: Business Process Model and Notation • EDI: Electronic Data InterchangeB2B Integration • XML Trade Vocabularies 24
  25. 25. The solutions provider Oracle Fusion Middleware (all in one, ETL, BPM, SOA, Data Oracle Integration, BI, IM, WebCenter), Siebel , solution for all major problems, Cloud solutions SAP NetWeaver, SAP Discovery system, solution for all major SAP problems, Cloud solutions BizTalk 2010 (messaging, a rules engine, EDI, BAM, LoB, HIS), Microsoft: Dynamics, SharePoint InfoSphere Platform, WebSphere (BPM, SOA, Portals, Data IBM Management) Tibco SOA, BPM, BO, CloudSoftware AG: BPM, SOA, Others: Adeptia ESB Suite, Spring, Metastorm EAI, 25
  26. 26. From the base …Java:• JMS• OpenJMS• Open MQ• JBoss ESB• Oracle Enterprise Service Bus• Mule.NET (ESB)• NServiceBus• BizTalkOther• RabbitMQ (Erlang) 26
  27. 27. What saying Gartner about tools? 27
  28. 28. What saying Gartner about providers? 28
  29. 29. The benefits (Myths)Operational: Managerial•Productivity increase •Better control/ overview•Cost savings •Better and fast decisions•Data consistency, Data access •Automations on decisions•Focus on Process •Performance evaluation (KPI)•Workflows /Automations •VISIBILITYStrategic IT•Long term planning (more companies can be integrated) •Control•Knowledge sharing •Scalability, Maintainability•Past, Present, Future informations (BI) •Data transparency •Real Time data access •Standardize and organize systems and data •Robustness, High availability Organizational •Less work /more efficiency •Better reaction to market changes •Focus on Business •New oportunities 29
  30. 30. The truth (Reality)Financial problems Pitfalls• 2002 : 70% of EAI project failed • Missing integration strategy• 2003 : 25-30% of IT budget is allocated for EAI • Combine EAI with other• HIGH COST on start, slow and invisible benefits projectAdded value problems • Lack of recognition that EAI is an architecture• Lot of companies follow the trend, not the business• Long term running projects, no added values • Neglecting security, performance and• CONSTANT CHANGES –Never ending stories monitoring;Make organization efficient Internal politics• The EAI doesn’t reduce the complexity • poor communication• Competing standard, doesn’t appliedKnowledge• Loss of details /focus point (Why we need this?)• Lot of DESIGN/ARCHITECTURAL/NEGOTIOTION TIME• Lack of specialist• Lack of managerial knowledge 30
  31. 31. Technical Reality Multiple interfaces give flexibility / irreplaceability ? Different applications can re-use the interfaces?. Services exposed over web can be easily decoupled. The IT/SW/HW doesn’t resolve the business problems. Lack of software response to Inconsistent data structure is transferred as a NORMALIZED? EAI helps a better reusability? Maybe freezing the interface. One Scope / One interface ? Knowledge on BUSINESS side affects the technical implementation Lack of ANALYSIS (business & system) Lack of feasibility analysis & risk analysis. 31
  32. 32. TIPS: Aks! Ask! Ask! SCOPE of EAI? Why do you what to do this? Why this EAI add value and how can materialize in COST (for ROI calculation)? How many applications do I need to integrate? Will I need to add additional applications in the future? How many communication protocols will I need to use? Do you what to maintain the old systems? Why? Infrastructure, locations, peoples who access? How important is scalability to organization? Security? Critical factor? What is you uptime? Process/Workflows : Do my integration needs include routing, forking, or aggregation? Does my integration situation require asynchronous messaging, publish/consume messaging models, or other complex multi-application messaging scenarios? Decision makings: BI/ data aggregation, data collection, modelling? 32
  33. 33. The Future Cloud Migration / Integration Cloud & Premise Integration Enterprise Social Networking Integrations Focus on Business Process Focus on: – Human centric Proces – Document Managent – Comprehensive integration (integrate the twitter with facebook and CRM and financial systems) Collaborations between Enterprise in real time. 33
  34. 34. BPM? Time to change … 2003 : Smith and Fingar Business Process Management (BPM): The Third Wave 34
  35. 35. Quotes“Nature laughs at the difficulties of integration.” Pierre-Simon Laplace “A goal without a plan is just a wish.” Antoine de Saint-Exupéry “Vision without execution is hallucination.” Thomas A. Edison . 35
  36. 36. Thanks! Levente Veres | Software Design LeadMail: levente.veres@gmail.comTwitter: @bergermanusLinkedIn: 36
  37. 37. References1. Enterprise Architecture: Microsoft Enterprise: gb/enterprise/default.aspx5. Thanks for Google Search ;) 37