With so many different tools at our disposable, how do you pick which ones to learn? At our latest meetup for Denver Code Club, we explored some best practices on evaluating new technology and how you can choose the right tools for you.

1. Staying current in a
changing marketplace
Denver Code Club Meetup Craig Martin, Vice President of
Engineering
January 19th, 2017

2. Agenda
● Changing market
● Approach and Adopting a new
technology
● Staying Current
● Evaluation Process
● How Kenzan does it:
○ Tech Radar
○ Skills Matrix / Badge Board
○ Internal Projects
○ Open Source Projects

3. 2003
SOAP Webservices
becomes popular
Technology
changes really
fast.
2005
Google
Maps & YouTube 2006
Initial AWS Cloud offerings
2008
RESTful Webservices
take hold
2013
March
● React released
● Initial Docker release
2011
● Google Cloud Platform
● January - Kafka
● December - Hadoop
2010
● February - Azure
● October - Angular
2014
● May - Apache Spark
● June - Initial
Kubernetes release
● October - HTML 5 2015
● January - Swagger
2016
● January - Serverless
architectures
● September - Angular 2
● July - Apache Mesos

4. Approaching a new technology
To keep in mind!:
Perseverance will pay off
You never stop learning
Different technologies and
starting points have different
kinds of learning curves

5. Adoption Expectations

6. How to stay current?
In a changing market
In Technology, standing still means falling behind
• Two main perspectives
Individual or Company
• Correct attitude
Embrace the change
Create a culture or an attitude of looking forward
• Be critical
For every good product there is a “Clippy”
• Apply in real world situations
• Evaluate the alternatives
Is there a market need?
Why is it better?
• Review from many perspectives (not just technology)

7. Technology evaluation
● Updating/modernizing
existing legacy
applications
● Comparing “old” vs
“new” technologies
● Evaluating emerging
technologies
COMMON
DRIVERS
COMMON
PITFALLS
● Resume driven
development
● Treating technology
stacks different than
architectural patterns
● Lack of consistency in
approach
● Stuck in the theoretical
- Start Building!

8. Modernizing existing application
Common Use Case: Company has an existing legacy application that needs a major feature overhaul or
needs an upgrade.
1. Start with an honest
evaluation of existing
application stack
a. What does it do well vs
not so well (e.g.
scalability, modularity,
releases, extensibility,
support, etc)
b. How much of the
challenges is related to
the technology?
c. Maybe code/arch
cleanup would be
better?
d. Understand the
architectural patterns
2. Determine list of potential
technology replacements
3. Use the Pros and Cons
as a template for each
technology
a. Evaluate each pro
and con against the
potential technology
b. Suitability fit with
development team(s)
4. Evaluate the “activity” of
the the technology
a. Lots of committers?
b. Open Source vs Closed
Source
c. Release Cadence
d. Available tooling and
Plugins
5. Overall technology
evaluation
a. Ease of use, code
management, cost,
complexity

9. Comparing Old vs New
Common Use Case: Company has a new tool or feature that needs to be built and we want to choose the right
technology.
Objective evaluation of pros
and cons:
● Differences in paradigm
or architecture
approach
● Features and gaps in
tech
● Performance
● Extensibility
● Activity & popularity =
resources and support
Compare costs of each
technology
● Open source
technologies vs
licensed technologies
● Maintenance costs are
expensive and will most
likely rise
Team Dynamics
● Skills of team
● Code handoffs Likelihood of longevity
● Judge by popularity
over time
● Extensibility
● Voodoo Magic

10. Evaluating Emerging Technologies
Common Use Cases:
● Helping clients to determine the correct strategic direction for their organization.
● Determining the technologies in market verticals and help establish the direction of the organization.
Identify POC to get hands
on with technology
● Focus on risk areas
● Establish checkpoints
along the way
Understand and the market or client
needs:
● Problems that need solving (industry
gaps)
● Challenges unique to the vertical
● Current competencies in the
organization or marketplace
● Competition evaluation
Builds on the technology
evaluations from above:
● Pros and Cons
● Costs
● Team Dynamics
● Longevity
Develop adoption plan and
implementation strategy
● Switching over legacy apps
● Training Staff
● Rollout strategy

11. WHO?
Find the right
people!
WHAT?
The training!
WHEN?
Project!
● Not all people love
picking up new
technologies
● Prove out critical challenges
● Dedicate a percentage of the
week/month to learn the new
technology
● Leverage online resources and
provide training when needed
● BUILD, BUILD BUILD!
● Join meetups and conferences in
town
● Present a tech talk or teach to others
● Start building immediately
● Don’t be afraid to jump “too early”
into the project
● Working on it is part of the
learning curve, and will shorten
the productivity dip time
Tips on How

12. How Kenzan does it....
• Tech Radar
• Skills Matrix
• Badge Board
• Building Skills
• Internal Projects
• Open Source Projects

13. Tech Radar
Subject Matter Quadrants
● Languages and Frameworks
● Tools
● Techniques
● Platforms
Evaluation
Adopt (2 rings)
Technologies in use, or
recommended to clients.
Trial
Technologies should be used on
internal projects or open source
projects to gain practical experience.
Evaluation
Technologies worth putting effort
toward investigating, pursued to
generate a proof-of-concept.
Hold
Technologies not yet ready, out of
date, or too risky to be used

14. Tech Radar Maintenance
Tech Radar
Maintenance
Starts with the right people:
● Attitude and desire is
importance
● Honest and critical (no
ego’s)
Routine meetings with tech
leadership
● Monitor and discuss
new technologies
● Discuss P.O.C. for
emerging technologies
● Monitor existing legacy
technologies
● Evaluate in progress
P.O.C’s
Author competencies for
relevant emerging
technologies
Routine “checkpoints” for
projects and people
● Project completion
● employee project
rolloff
● Manager & employee
checkins

15. Skills matrix and competencies
● Skills matrix is the sum of all the skills that we have
● Each skill has a set of competencies
● Typically broken into 3 different levels (Beginner, Intermediate, Expert)
● Goal is to have the “Kenzan Standards” of competencies
● Will be established once it is added to the tech radar
○ Only filled out when it becomes relevant

16. badge board
The goal of the board is to have an
accurate representation of all the
skills within Kenzan.
Functions:
● Provide the resourcing team a
mechanism to determine which
employees are best suited for a
project
● Provide tenured employees a
set of skills to work towards
and competencies to meet
those skills
● Set and track the "technology
stack" within Kenzan's
organization
It’s expected and encouraged that
the badge board will evolve over
time. This will happen both from a
tech stack perspective and from a
employee skills perspective.

17. Open Source
Projects
Open Source and Internal projects
are strongly tied to Tech Radar and
Badge Board
Open Source:
● Kenzan benefits a lot of the open
source community
● Open source projects are Kenzan’s
contribution to the community
● Usually created as Proof-Of-Concepts
and experimentation with emerging
technologies spotted in the Tech
Radar.
Internal Projects:
● Internal projects are for internal
Kenzan IP
● They are created by “bench”
employees
● Opportunity to pick up new
technologies and earn badges
Examples of Open Source Projects:
● MSL (Million Song Library) -> Angular + Java +
Netflix + Cassandra:
https://github.com/kenzanlabs/million-song-library
● Keystone (Front End Build Tool) -> Node + Gulp +
Yeoman:
https://github.com/kenzanlabs/keystone
Internal Projects:
● Kenzan.IO -> React.JS, Wordpress API:
http://kenzan.io
● Tech Radar -> React.JS + Redux + Node

18. Want to learn more?
Follow us!
@kenzanmedia
www.linkedin.com/company/kenzan-media
techblog.kenzan.com
www.facebook.com/kenzanmedia/