Innovate2014 Panel - Best Practices on Implementing Integrations
•Download as PPT, PDF•
1 like•3,652 views
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Innovate2014 Panel - Best Practices on Implementing Integrations
Similar to Innovate2014 Panel - Best Practices on Implementing Integrations (20)
More from Steve Speicher
More from Steve Speicher (11)
Recently uploaded
Recently uploaded (20)
Innovate2014 Panel - Best Practices on Implementing Integrations
- 1. © 2014 IBM Corporation Panel: Best practices on implementing integrated tools 1863
- 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. 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. • 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. • 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. • 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. • 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. • 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. • 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. • 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. • 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. Thank You
Editor's Notes
- What we have been illustrating, we can call “the integration problem.” The integration problem has been around since the first user wanted two programs to work together. It has only got worse since software got more capable (and more complex), since groups of users wanted to work together across the different tools, and since businesses became more dependent on software. 1. (blues) Traditional (point-to-point) integrations are based on proprietary APIs. This places burdens: On all vendors to invent their own good API (re-inventing the wheel each time), and On all integrators (whether they be vendors, IT administrators, or end users themselves) to understand at least two APIs to create any integration. Experience has shown these integrations to be brittle and difficult to maintain. For IBM: Our traditional assumption: 12 months, 6 developers; prototype in 2-3 months A starting point like that indicates quite a bit of uncertainty about the effort. 2. (blues) Software monocultures and the “hub-and-spokes” integration pattern, emerged as a way to minimize the negatives associated with traditional integration techniques. Unfortunately, many ecosystem users then suffer from: The inability to use the tools they prefer from within the ecosystem, and The high cost of quitting that ecosystem all together. In the long run, the ecosystem can become a burden to the dominate vendor as they bend to customer pressure to make sure dozens of external integrations work too. Whatever software choices we’ve made in the past, integrations have been yet another proprietary data format that has locked us in. 3. (blues) As time goes by, it isn’t only the visible costs of maintenance, management, and migration that go up: Users also get frustrated, affecting morale and productivity, and The lack of agility can result in lost business opportunities. The costs of supporting these integrations can be near-fatal too! For IBM: Integration PMRs are difficult to diagnose (let alone solve!), consuming resources from new initiatives, and making our clients shoulder the burden of investments that are not showing returns. Customers with low trust that our own products will integrate with each other, let alone 3rd-party tools Cost (“Integrations consume …”) (see backup slide for stat details): Special skills required to maintain the integrations Risky to change any part of the system Frustrating for IT staff who work to keep the system running for the present instead of innovating for the future Copy and synchronization problems can be difficult to diagnose Productivity Better software either unavailable because it isn’t integrated, or used without being integrated May result in missed business opportunity Copy and synchronization problems can effect business decisions Change The strength that was an integrated software system can become a weakness in the face of smaller, younger, competitors who don’t have to support dozens of special case integrations. Today’s, and tomorrow’s, profits and competiveness are reduced by the effects on IT spending and user productivity.