4. Enterprise Application Integration Uses a hub-and-spokes model Point-to-point Service-oriented Integration –Bus –Service Bus –Enterprise Service Bus

5. C2C1 P1P2

6. ABB’s Architecture Building Blocks –(Generic) Types of Components –Responsibilities –Defines responsibilities of generic components in your architecture

7. Components For every architectural style –(Generic, Style-specific) Components that define the style –Connectors, Constraints For a given application… –(Functional or Operational) Components… When we are building or evaluating an architecture we need to have guidance on what TYPES of components we should be looking for…

8. N-tier

9. 12-2-2008

10. SOMA 5 constructs of SOA: –Services –Components –Flows (processes) –Information –Rules and Policies

11. SOMA identification Helps identify, select, discover (synonyms) the 5 constructs of SOA

12. SOA SOA Paradigm (way of thinking) separate from SOA Implementation (web servcies) You can do analysis and design with SOMA WITHOUT implementing ANY web services!!!! –Not all implementation in an SOA is web services!! Design (arch, Design decisions)  (Realization, Arch, Design ) Decisions  Implement (code, test, integrate, verify)  Deploy

13. The Tail wagging the Dog!!! The package and its underlying business process is forced on the company, regardless of the company’s business processes P = s1, s2, s3, s4 Package vendor: –P = s2, s4, s3, s1

14. Steps to evaluating a package Identify (candidate) services –Service portfolio (service model) –List of services that this company provides and needs –Client needs: S1, S2,.., Sn Investigate what “services”, functions, features, processes, APIs, etc., “things you can do”, P1, P2, …, Pn Can you provide a mapping between the services needed (required) and those offered by the package vendor? –S1  P1??, S2  P3, S4  P6, –There will be a gap (fit-gap analysis) –S1-P1 = 0 there is no gap this is a very good fit –S2 – P3 > 0 = “a”; a is a gap

15. Gap Analysis and Realization Decisions “a”, this gap –Buy as is and change YOUR process to fit the gap –Adaptor (adornment, wrapper), decorator, S1 = (P3 + code you write to “decorate” ) –Configure P3 to support S1 External file –Template Method Package asks for a method to call to calculate interest, you write the method

16. Identification Business involvement Solution Management

17. SOMA phases mapped to RUP Solution Management

18. Relation between SE and SA Software Engineering Software Architecture

19. Goal-service Modeling Ensure that the services are aligned and traceable to business goals Make sure the business cares about the (functions, capabilities or) services you are proposing to build

20. Process Decomposition Start with a high level process Decompose it by process steps

21. Common services found by both techniques are better services GSM PD

22. Service Rationalization Justify why you chose these services Meet with the client Describe the service portfolio you have to date Get their input Refactor the service portfolio

23. Category –S1 –S2 –S3 Category 2 –S4 –S5 –S6 –S7

24. RUP and SOMA

25. Dec 3, 2008

26. What is the next paradigm? If SOA is the current state of SA, then what comes after SOA? –Yonas M SIMM – Service Integration Maturity Model –http://www.ibm.com/developerworks/webservi ces/library/ws-soa-simm/http://www.ibm.com/developerworks/webservi ces/library/ws-soa-simm/ Context-aware Services, Dynamically Reconfigurable Styles

27. Increasing maturity of architectural styles over time silo integrated component services Composite services BPEL WSDL Simple One at a time Function exposed as services Composition Of services to Form an app Represents main flow Of control APIs Libraries Frameworks Functionality Applications 30201052 Composition Configuration decoupling Maturity: Entire the roadmap for applications in an enterprise (EA). When do I stop? Planning; Governance Accountabili ty  business needs / arch

28. Increasing maturity of architectural styles over time silo integrated component services Composite services BPEL WSDL Simple One at a time Function exposed as services APIs Libraries Frameworks Functionality Applications 30201052 Composition Configuration decoupling Virtualized services Grid computing Cloud Computing Virtualized Infrastructure Operations (NFR) Virtualization Context-aware/ Dynamically reconfigurable services

29. Infrastructure Architecture Discussion based on notes in –http://softwarearch.pbwiki.com/Lecture+Notes +for+12-3-2008http://softwarearch.pbwiki.com/Lecture+Notes +for+12-3-2008 Proxy, Virtual Host, Clustering, Sessions, Load-balancing/failover/availability

30. Maturity –EA consideration SIMM –App Arch consideration Release management (how you choose to iterate and release sw) How you divide work among your teams How you test applications

31. Risk Mitigation Deadline or time risks are mitigated through –Planning –Continual Monitoring of Status PM – compares status/actuals to planned Arch – compares actual results with the design Scope creep –PM manages communication –Arch manages what it takes to deliver the new functionality, estimation, technical feasibility, integrity of the design

32. Risk Mitigation Integration Risk (Big Bang of Integration) –TFE –Includes one or more POC – proof of concept, prototype (extensible) vs throw-away prototype Running code

33. Integration Big Bang! UI Biz Db scope UI Biz Db scope 2 2 1 1 2 3 UI Biz Db scope integrate Interfaces Interactions Finish components

34. Integration Big Bang! UI Biz Db scope integrate Build enough functionality To support one service across All tiers in the arch Feature, services, Simple Use-case

35. Integration based on a fractal approach UI Biz Db Scope = uc1, uc2,.., ucN Uc(i). integrate Build enough functionality To support one service across All tiers in the arch Feature, services, Simple Use-case Uc(i) 1.Integration first 2.Required to support uc(i) 3.Uc(i) is selected based on A combination of user-priority,

36. Release Dependencies Functional Enter Purchase UserAccount Category Least dependent – low risk

37. Release Dependencies Technical – Operational DB Schema What are the arch decisions around INTEGRATION ISSUES That are MOST likely to FAIL@! Start with those… Start with the highest risk item FIRST Item = technical THEN functional

38. “Technical Feasibility” Exploration TF: Can I technically do this? Technically, is this possible to do? Manage Risk; Mitigate Risk