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
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.