Multi-Team/Multi-UI Development

@Interactive Intelligence

Who Am I?• Senior Developer @

Interactive Intelligence

• Member of the Ember Learning Team

• twitter: @tddjordan

• github: toddjordan

• Ember Slack: todd.jordan

Who Are We?• Cloud-based Global Contact Center Software• …plus Realtime Collaboration (chat, webrtc, telephony)• Headquartered in Indianapolis• Development Lab in RTP• https://www.inin.com/careers

3 Web Frameworks

One Cohesive UI

Dreams within

Dreams

Large Scale Development:

Its hard.

The more people on a team, the harder to

manage.

• Unwanted dependencies (Tangles)

• Inconsistent coding standards• Build breakages/bugs• Maintenance

Autonomous Teams Want

• Own release cadence• Own coding standards• Protection from each other

An Oral History

Our Story BeginsCirca 2012

Ember 0.98@OrgSpan

Engage2013

Code Repo

Core application code / common services

Code RepoSub-App

Core application code / common services

Code RepoSub-App

Core application code / common services

Code Repo(s)Sub-App

Core application code / common services

Angular Admin2014

Acquisition2014

Initially, we were thinking lets treat apps separately and access them

with a launcher

Think Google Apps

Single App Look/Feel2015

IFRAME, Cross Document Messaging, and You

Window.postMessageWindow.on(‘message.x’, …)

EmberKnockout

KnockoutEmber

EmberAngular

EmberAngularEmber

Why Ember as the App Platform?The OrgSpan App was a logical “Decorator” to our customer servicing product

line…

But choosing ember as the shell paid immediate advantages :-)• Robust Routing• Rich Addon ecosystem• A helpful and passionate community• Semver - Steady, predictable releases (no rewrites?)

Embedded App Component

Embedded App Service

• Routing• Sending Events Back• App State around the sub-app (is it active,

etc)

Incremental Rewrites

1. UX or significant change from Product Team2. Create a feature flag (in our feature flag service)3. Implement it in Ember (preferably/eventually engines)4. Flip the switch when ready

2016

Engines• A namespaced, routable addon• Allows for accessing shared services• Like an addon, can run in a dummy app• No Cross Document Messaging needed• Can be Lazy loaded (future)• Currently Piloting with our Engage Queues

App

Engine!

Challenges• Not quite ready for Prime-time• Lots of time currently spent on getting

engine dependencies right. Most common complaint is that there’s not a good way to manage add-on dependencies between parent and child.

• No Lazy Loading (yet)

Apps

We want to consolidate…• but it makes no business sense to stop and rewrite• We want to continuously deliver on a cadence and as we do

that…• Keep developing our Ember shell into a robust application

platform• Incremental conversion• Continue developing Common Components as Addons!!• Utilize our Common App Platform?• Stay with Engines and contribute to its maturity

Parting Thoughts• Autonomy and Standards• Continuous Delivery and Ambitious Change • Choosing the best Tech and Maintenance Concerns• Customization and Reuse• Pragmatism and Idealism

Truth is, we constantly balance between

We are not special snowflakes in this

Thanks!!!!