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.

Innovate2014 Panel - Best Practices on Implementing Integrations

1,975 views

Published on

Published in: Technology
  • Be the first to comment

Innovate2014 Panel - Best Practices on Implementing Integrations

  1. 1. © 2014 IBM Corporation Panel: Best practices on implementing integrated tools 1863
  2. 2. Integrations consume more of the IT budget: integration failures are the top 2 causes of software project delays* Integrations consume more of the IT budget: integration failures are the top 2 causes of software project delays* The Integration Problem Point-to-point Integrations don’t scale Monocultures lock you in Maintenance, management, and change costs go up over time Creating new integrations is unpredictable Ongoing and unexpected costs drain resources Past choices restrict present action and future vision * Commissioned study conducted by Forrester Consulting on behalf of IBM.
  3. 3. Meet Your Panelists 3 Dave West Chief Product Officer Tasktop Technologies Steve Speicher OSLC Lead Architect IBM Rational Bill Chown Product Marketing Director Mentor Graphics Axel Reichwein Independent Consultant Koneksys
  4. 4. • Experimented with RESTful point-to-point integrations • Not only own product integration problems • Jointly formed Open Services for Lifecycle Collaboration (OSLC) to address these problems • Ton of experience with bus/replication-style integrations • Personally joined effort in late 2008 as part of CQ and RTC development team IBM: Context 4 Steve Speicher OSLC Lead Architect IBM Rational
  5. 5. • Skill gap can’t be underestimated • SDK, test suites and reference implementations go a long way • Develop and test with at least 2 implementations • Start small, iterate, don’t push off hard stuff (OAuth, query) • Support what you need (supporting the full spec should be the goal but may not be necessary) IBM: Lessons learned 5 Steve Speicher OSLC Lead Architect IBM Rational
  6. 6. • UML-based and SysML-based integration solutions to bridge the gap between systems engineering and discipline-specific engineering • Implementation of (open-source) OSLC-based solutions including OSLC adapters for MagicDraw SysML, Simulink, AMESim, and PTC Integrity • Co-Chair of the OMG OSLC4MBSE Working Group to apply OSLC beyond software engineering Koneksys: Context 6 Axel Reichwein Independent Consultant Koneksys
  7. 7. • Integration of multi-disciplinary information in a common modeling language is difficult • Interest to apply OSLC beyond software engineering is rising • Potential to convert existing standards (SysML, STEP, FMI) into OSLC specifications • Open-source OSLC solutions benefit everyone • Eclipse Lyo very useful to get started with OSLC Koneksys: Lessons learned 7 Axel Reichwein Independent Consultant Koneksys
  8. 8. • Thanks for including my product name in everyone’s title! • OSLC point to point – good • OSLC point to focal point – better • Several years experience with numerous tools and use cases across the design space, and creation of new toolsets • Context™ Server stores and manages the links – Organizes links, builds history, enables traceability and reporting – Original data remains with original tools and repositories • Context™ SDM plugins augment design tools – Integration available for any Mentor tool – Also supports other vendors’ or internal design tools • Web-based Product Manager accesses data and analytics Mentor Graphics: Context 8 Bill Chown Product Marketing Director Mentor Graphics
  9. 9. • It’s a people problem – Fear of change colors opinions – Tools are sacred to the current expert users • Technically, most design tools can be connected – Most commercial tools support extensibility – in some form – A set of libraries and generated APIs enable integration – In-house solutions are sometimes more challenging – Some vendors seem reluctant to enable integrations • Values observed are diverse, and span the use cases well Mentor Graphics: Lessons learned 9 Bill Chown Product Marketing Director Mentor Graphics
  10. 10. • Have been pushing the need for lifecycle tools for over 20 years • But still VERY disappointed – Still the need for email and spreadsheets to run projects • Saw the need for integration between tools whilst a Forrester – Legacy tools hard to change – Tools strong affinity to disciplines and platforms – Developer driven innovation • Driving product at Tasktop that provides an integration bus for lifecycle tools based on the success of Mylyn – Enables process flow between tools – Supports cross tool traceability and reporting – Encourages collaboration in context • OEM’d by IBM at Rational Lifecycle Integration Adaptors – Tasktop Edition (catchy title hey ) Tasktop: Context 10 Dave West Chief Product Officer Tasktop Technologies
  11. 11. • Integration is more complex than it looks – Process / Flow complexity – Structure complexity – Need for transformations / translations • Vendor APIs change frequently and that is increasing – Robust solution requires significant testing • Integration patterns raise the abstraction – Provide way to introduce standards and concepts • Point to point integration solutions are brittle – Need for a bus model – Map to common abstraction (ALM data model) • OSLC is a great starting point but incomplete – Need to support closed systems – Need to enable flow and collaboration Tasktop: Lessons learned 11 Dave West Chief Product Officer Tasktop Technologies
  12. 12. Thank You

×