The document discusses the challenges an organization faces in establishing an effective API program. It describes Swisscom's journey to transition from a project-centric to API-centric approach. Key lessons learned include the need to develop reusable APIs, segregate data delivery from management, and create a northbound map to guide API development and avoid complexity. Speaking a common language between business and technology units and establishing an API program team to act as a proxy were also important steps.
Why we wrote this booklet…
We created this booklet in order to share our experiences in becoming a state of the art API provider. The Swisscom API program started in September ‘13 in cooperation with Apigee. We went through all the typical difficulties that come along with such a big change process.
We are still learning and would like to start a discussion to find new ways to cooperate beyond the past “thinking in silos” in order to move forward to a connected world.
The Swisscom API team ~ Zurich, August ‘14
The right way to influence behaviour with technologyThe App Business
TAB Strategist Jean Francois Hector recently gave a talk at Mobile UX London. Here is a summary version of his deck and presentation, where he breaks down the importance of understanding user behaviour, and how to elicit the behaviours you want using the MAT model with our handy tips on how to apply it.
sitNL masterclass - (handson) session - Create your first chatbotWim Snoep
introduction slides on the exercises, and short theory on the nature of a chatbot, and terms in SAP Conversational AI, and typical possible architecture setup.
The release of Android Marshmallow is drawing closer, and as with any new OS release, our team at TAB is excited about what this means for our clients and their users alike. Getting stuck into the Beta version of M created lots of discussion and deliberation at TAB HQ, especially for our product owners and Android engineers as they explore how these updates impact our current and future projects.
Here is a quick summary of the key features and changes expected from Android M.
iOS 10 has been billed as the biggest software update that Apple has ever released. It promises to fundamentally change and expand the ways in which we use the iPhone. Here is everything you need to know about one of the most exciting updates to Apple's operating system.
Making Telecoms the Essential Spice of Every Business Ecosystem: The Slow, Pa...Alan Quayle
Presented at SDP Asia 2012, the presentation reviews the importance of APIs to telecoms.
Fundamental Misconceptions: Its about Business not Technology, Its across the Tail, not the Long Tail, Why Service Exposure matters: Quantifying the opportunity, Why all businesses are moving to APIs
Understanding the Telecom situation
BlueVia Case Study
Verizon Case Study
Wondering what Apple's release for iOS 8 has in store? Getting ready for Apple's upcoming Special Event this autumn?
Download and read our pre-release briefing on some of iOS8's key themes and features from WWDC14, ahead of the next big reveal on 09/09/14.
PSMG Annual Conference: Integration or isolation? Precedent
Presented by Darren Amer and Mark Russell at PSMG's Annual Conference 2011, this talk considers the need for professional services to adopt a fully integrated digital strategy.
Why we wrote this booklet…
We created this booklet in order to share our experiences in becoming a state of the art API provider. The Swisscom API program started in September ‘13 in cooperation with Apigee. We went through all the typical difficulties that come along with such a big change process.
We are still learning and would like to start a discussion to find new ways to cooperate beyond the past “thinking in silos” in order to move forward to a connected world.
The Swisscom API team ~ Zurich, August ‘14
The right way to influence behaviour with technologyThe App Business
TAB Strategist Jean Francois Hector recently gave a talk at Mobile UX London. Here is a summary version of his deck and presentation, where he breaks down the importance of understanding user behaviour, and how to elicit the behaviours you want using the MAT model with our handy tips on how to apply it.
sitNL masterclass - (handson) session - Create your first chatbotWim Snoep
introduction slides on the exercises, and short theory on the nature of a chatbot, and terms in SAP Conversational AI, and typical possible architecture setup.
The release of Android Marshmallow is drawing closer, and as with any new OS release, our team at TAB is excited about what this means for our clients and their users alike. Getting stuck into the Beta version of M created lots of discussion and deliberation at TAB HQ, especially for our product owners and Android engineers as they explore how these updates impact our current and future projects.
Here is a quick summary of the key features and changes expected from Android M.
iOS 10 has been billed as the biggest software update that Apple has ever released. It promises to fundamentally change and expand the ways in which we use the iPhone. Here is everything you need to know about one of the most exciting updates to Apple's operating system.
Making Telecoms the Essential Spice of Every Business Ecosystem: The Slow, Pa...Alan Quayle
Presented at SDP Asia 2012, the presentation reviews the importance of APIs to telecoms.
Fundamental Misconceptions: Its about Business not Technology, Its across the Tail, not the Long Tail, Why Service Exposure matters: Quantifying the opportunity, Why all businesses are moving to APIs
Understanding the Telecom situation
BlueVia Case Study
Verizon Case Study
Wondering what Apple's release for iOS 8 has in store? Getting ready for Apple's upcoming Special Event this autumn?
Download and read our pre-release briefing on some of iOS8's key themes and features from WWDC14, ahead of the next big reveal on 09/09/14.
PSMG Annual Conference: Integration or isolation? Precedent
Presented by Darren Amer and Mark Russell at PSMG's Annual Conference 2011, this talk considers the need for professional services to adopt a fully integrated digital strategy.
The API-Kitchen, scaled & Agile!
This book describes, our experiences in scaling Agile. Pick your printed copy at the 'I love APIs' conference 2015 in San Jose . 12-15 October Best, Kay Lummitsch
Get the latest announcements on Microsoft and NVIDIA's HGX-1 platform for artificial intelligence cloud computing, Facebook's new AI server, and the launch of Jetson TX2 for AI computing in cameras, sensors, and more.
PDF, audio, and voiceover are now available on designintechreport.wordpress.com
Today’s most beloved technology products and services balance design and engineering in a way that perfectly blends form and function. Businesses started by designers have created billions of dollars of value, are raising billions in capital, and VC firms increasingly see the importance of design. The third annual Design in Tech Report examines how design trends are revolutionizing the entrepreneurial and corporate ecosystems in tech. This report covers related M&A activity, new patterns in creativity × business, and the rise of computational design.
Developer Garden war ein Sponsor der IT Profits 2009. Im Rahmen dieses Engagements stellte Christian Krassowka, Mitarbeiter von Developer Garden, das neue Entwicklerportal der Deutschen Telekom auf dem Monetisation Camp 2009 vor.
Set Your Content Free! : Case Studies from Netflix and NPRDaniel Jacobson
Last Friday (February 8th), I spoke at the Intelligent Content Conference 2013. When Scott Abel (aka The Content Wrangler) first contacted me to speak at the event, he asked me to speak about my content management and distribution experiences from both NPR and Netflix. The two experiences seemed to him to be an interesting blend for the conference. These are the slides from that presentation.
I have applied comments to every slide in this presentation to include the context that I otherwise provided verbally during the talk.
Python Utilities for Managing MySQL DatabasesMats Kindahl
Managing a MySQL database server can become a full time job. What we need are tools that bundle a set of related tasks into a common utility. While there are several such utility libraries to choose, it is often the case that you need to customize them to your needs. The MySQL Utilities library is the answer to that need. It is open source so you can modify and expand it as you see fit.
This is the presentation from OSCON 2011 in Portland.
Revolutions have a common pattern in technology and this is no different for the API space. This presentation discusses that pattern and goes through various API revolutions. It also uses Netflix as an example of how some revolutions evolved and where things may be headed.
Conférence présentée le 19 janvier 2016, qui présente les différents enjeux liés à la webanalytics pour les publishers (sites média) : adblockers, segmentation et interaction avec le contenu, performance, écosystèmes de contenu déporté, vision user centric.
This presentation highlights automotive applications for AGC's AFLAS Fluoroelastomers, FLUON Filled PTFE Compounds, FLUON ETFE, LUMIFLON FEVE Resins and AsahiGuard E-Series. For more information, go to www.AGCchem.com or call 800-424-7833. You can also follow AGC on Twitter @AGCChem_Amer. Thanks for viewing!
Where did early humans start and where did they end up? Explore the migration patterns of humans throughout the world.
Register to explore the whole course here: https://school.bighistoryproject.com/bhplive?WT.mc_id=Slideshare12202017
Breve presentación que expresa algunos criterios por la Agenda diseñada por CEPAZ y la necesidad de vincularla al sistema internacional de protección de los DDHH
How Houwzer Speeds Growth and Innovation by Gaining Insights Into API Use and...Dana Gardner
Transcript of a discussion on how a cloud-based home-brokerage-enabler, Houwzer, constructed a resilient API-based platform as the heart of its services integration engine.
The Open Commerce Conference - Premature Optimisation: The Root of All EvilFabio Akita
This is the talk I presented in NYC at the Spree Conference. It's about how we may be making bad decisions out of blindly following misleading pitches. To avoid it, we just need to go back to the basics of CS: Don't optimize prematurely. Here's how.
The API-Kitchen, scaled & Agile!
This book describes, our experiences in scaling Agile. Pick your printed copy at the 'I love APIs' conference 2015 in San Jose . 12-15 October Best, Kay Lummitsch
Get the latest announcements on Microsoft and NVIDIA's HGX-1 platform for artificial intelligence cloud computing, Facebook's new AI server, and the launch of Jetson TX2 for AI computing in cameras, sensors, and more.
PDF, audio, and voiceover are now available on designintechreport.wordpress.com
Today’s most beloved technology products and services balance design and engineering in a way that perfectly blends form and function. Businesses started by designers have created billions of dollars of value, are raising billions in capital, and VC firms increasingly see the importance of design. The third annual Design in Tech Report examines how design trends are revolutionizing the entrepreneurial and corporate ecosystems in tech. This report covers related M&A activity, new patterns in creativity × business, and the rise of computational design.
Developer Garden war ein Sponsor der IT Profits 2009. Im Rahmen dieses Engagements stellte Christian Krassowka, Mitarbeiter von Developer Garden, das neue Entwicklerportal der Deutschen Telekom auf dem Monetisation Camp 2009 vor.
Set Your Content Free! : Case Studies from Netflix and NPRDaniel Jacobson
Last Friday (February 8th), I spoke at the Intelligent Content Conference 2013. When Scott Abel (aka The Content Wrangler) first contacted me to speak at the event, he asked me to speak about my content management and distribution experiences from both NPR and Netflix. The two experiences seemed to him to be an interesting blend for the conference. These are the slides from that presentation.
I have applied comments to every slide in this presentation to include the context that I otherwise provided verbally during the talk.
Python Utilities for Managing MySQL DatabasesMats Kindahl
Managing a MySQL database server can become a full time job. What we need are tools that bundle a set of related tasks into a common utility. While there are several such utility libraries to choose, it is often the case that you need to customize them to your needs. The MySQL Utilities library is the answer to that need. It is open source so you can modify and expand it as you see fit.
This is the presentation from OSCON 2011 in Portland.
Revolutions have a common pattern in technology and this is no different for the API space. This presentation discusses that pattern and goes through various API revolutions. It also uses Netflix as an example of how some revolutions evolved and where things may be headed.
Conférence présentée le 19 janvier 2016, qui présente les différents enjeux liés à la webanalytics pour les publishers (sites média) : adblockers, segmentation et interaction avec le contenu, performance, écosystèmes de contenu déporté, vision user centric.
This presentation highlights automotive applications for AGC's AFLAS Fluoroelastomers, FLUON Filled PTFE Compounds, FLUON ETFE, LUMIFLON FEVE Resins and AsahiGuard E-Series. For more information, go to www.AGCchem.com or call 800-424-7833. You can also follow AGC on Twitter @AGCChem_Amer. Thanks for viewing!
Where did early humans start and where did they end up? Explore the migration patterns of humans throughout the world.
Register to explore the whole course here: https://school.bighistoryproject.com/bhplive?WT.mc_id=Slideshare12202017
Breve presentación que expresa algunos criterios por la Agenda diseñada por CEPAZ y la necesidad de vincularla al sistema internacional de protección de los DDHH
How Houwzer Speeds Growth and Innovation by Gaining Insights Into API Use and...Dana Gardner
Transcript of a discussion on how a cloud-based home-brokerage-enabler, Houwzer, constructed a resilient API-based platform as the heart of its services integration engine.
The Open Commerce Conference - Premature Optimisation: The Root of All EvilFabio Akita
This is the talk I presented in NYC at the Spree Conference. It's about how we may be making bad decisions out of blindly following misleading pitches. To avoid it, we just need to go back to the basics of CS: Don't optimize prematurely. Here's how.
Strange but True: Counterintiutive Paths to Building a Business on APIsThomas Bouldin
After 6 years working on developer experiences, these are my rules of thumb for building a business on APIs:
1. Don't build a business on APIs
2. Don't be Creative
3. Treat Customers like (Your) Children
4. Do Fewer Things
5. Focus on the Docs Nobody Reads
6. Sweat the Small Stuff
Traceable.ai Debuts Platform for Building API Knowledge that Detects And Thwa...Dana Gardner
Transcript of a discussion on a new platform designed from the ground up specifically to define, manage, secure, and optimize the API underpinnings for so much of what drives today’s digital business.
VARS - the way we make money as independent entrepreneurs...Gordon Kraft
In the days of the minicomputer and PC's VARS Value Added Resellers provided turnkey solutions to Business. They still do to Large End Users LEU's, but with the economy creating more and more Entrepreneurs, one man bands a new yet solution is required. Pooling of Interests is required... Collaboration is required. This can be done by Google Hangouts. Or of course one can Offshore their requirements to India.
Silicon Valley can create Pooling Interest in and city, even Lake Tahoe...
Digitalisation of financial supply chain some trends 2015 to 2016Jos Feyaerts
2015-2016 WHAT IS GOING ON IN THE FINANCIAL SUPPLY CHAIN 50 Statements and a lot more thoughts
Dear digitalisation fans,
2015 was the year where “Back to the Future” definitely moved into the past. The fax machine, for which the film devoted a lot of credentials, did expand fast but it in 2015 it is after all gone in the day-to-day life. In the digitalization of the financial supply chain, the fax did play an important historical transition roll. How many orders, order confirmations were going faster due to the fax?
But now we are in another age. We are in the age where ‘The network always wins”,(Peter Hinssen), Let’s realize a more connectivity in 2016. Stop fighting for the word “open” but realize the interconnectivity and interoperability a little more. It isn’t simple and we should not deny the complexity to realize it on a large scale, but yes we can go further.
You can find our E-Book counting ca. 30 pages with thoughts, reflections and trends, which we will elaborate in the coming period year even more in details in separate posts.
Here you can download the whole report for free.
2015-2016 WHAT IS GOING ON IN THE DIGITALISATION JOURNEY OF THE FINANCIAL SUPPLY CHAIN WITH HIS POWERFUL E-INVOICING ENGINE?
2016 the year to talk back
We wish you an inspiring year-end of 2015 and a successful 2016 where you can realize the impact you want to achieve, but above all a lot of fun and a good health.
Keep on focusing, registering and crystalizing your journey
See you in 2016!
Jos Feyaerts
Your digitalization guide
InCoPro bvba, ‘Design for Margin’ (D4M)
The tech recruiting tactics of long ago (headhunters and classified newspaper ads) simply don’t work anymore. Discover why these outdated practices don't work and how to create a more modern developer hiring strategy.
Kay Lummitsch's keynote was a real wake-up call to Sri Lankan organizations to adapt to Digital. He shared his wide experiences on almost every aspect of a Digital Journey.
The Audience realized that the most common pitfalls on the path towards Digital, are industry agnostic and surprisingly to more than seventy percent not reliant on technology issues. Lummitsch stated that organizations would fail if they focus on technological and structural change only (What they typically do ˜ Lummitsch).
His advice is to engage equally in every aspect of any ‘Living System. [Organisation]
Changing the Mindset. Coaching, mentoring and personal development are his preferred tools here.
Changing Behavior & Communication We should rethink how we work and communicate with each other in the future.
Technology & Structures. Of course!. Adopt to modern team setups and bleeding-edge technologies.
Changing the organization's Culture. If we won’t change our organization’s culture, we’ll never adapt to Digital ˜Lummitsch
Furthermore, he emphasized that the main difference from past leadership models to Digital Leadership roles is, that Digital Leaders have to love people whereas past leaders were impelled to feel superior.
QUOTE:
There is no change towards Digital if it doesn't hurt you in every bone and questions your personal role on a daily base - Kay Lummitsch (The Digital Journeyman)
http://linkedin.com/in/lummitsch
The Competition Of Knowledge Is Dead - Let’s welcome the competition of Cetitiravy!
Subtitle: Where Bullerbü meets Digital
After passionately driving API programs for years, accelerating digital programs in Telco, Finance and Automotive industries, and after talking to countless teams, experts and managers in both Business and IT, I can see a common pattern.
Our organizations are making huge investments in new technologies, expecting almost immediately new revenues based on old business models.
They are introducing pseudo-agile methodologies to people who do not have an agile mindset and putting agile teams to the very end of their waterfalls. They are establishing shining Incubator Hubs, pretending to teach their customers on how to leverage Digital - without being Digital at all.
HR departments are still hiring people who are stabilizing the organizational status quo - still applying old-world-metrics to new-world-people. Enterprise Architecture departments are mainly acting as Digital Show-Stoppers. And last but not least, the most digital approaches are still lagging real Executive backing.
How can it be? What are the hidden mechanics to make us stepping on our bootstraps on a daily basis?
My speech will clarify why our organizations are doing so - even with the best intentions - even with brilliant people. - AND - will show a radical way out of the Digitalization trap.
Synopsis
After passionately driving API programs for years, accelerating digital programs in Telco, Finance and Automotive industries, and after talking to countless teams, experts and managers in both Business and IT, I can see a common pattern.
Our organizations are making huge investments in new technologies, expecting almost immediately new revenues based on old business models.
They are introducing pseudo-agile methodologies to people who do not have an agile mindset and putting agile teams to the very end of their waterfalls. They are establishing shining Incubator Hubs, pretending to teach their customers on how to leverage Digital - without being Digital at all.
HR departments are still hiring people who are stabilizing the organizational status quo - still applying old-world-metrics to new-world-people. Enterprise Architecture departments are mainly acting as Digital Show-Stoppers. And last but not least, the most digital approaches are still lagging real Executive backing.
How can it be? What are the hidden mechanics to make us stepping on our bootstraps on a daily basis?
My speech, “Why Organizations Are pretending To Leverage Digital Successfully, Whilst Failing Along The Line?” will clarify why our organizations are doing so - even with the best intentions - even with brilliant people. - AND - will show a way out of the Digitalization trap.
Synopsis
After passionately driving API programs for years, accelerating digital programs in Telco, Finance and Automotive industries, and after talking to countless teams, experts and managers in both Business and IT, I can see a common pattern.
Our organizations are making huge investments in new technologies, expecting almost immediately new revenues based on old business models.
They are introducing pseudo-agile methodologies to people who do not have an agile mindset and putting agile teams to the very end of their waterfalls. They are establishing shining Incubator Hubs, pretending to teach their customers on how to leverage Digital - without being Digital at all.
HR departments are still hiring people who are stabilizing the organizational status quo - still applying old-world-metrics to new-world-people. Enterprise Architecture departments are mainly acting as Digital Show-Stoppers. And last but not least, the most digital approaches are still lagging real Executive backing.
How can it be? What are the hidden mechanics to make us stepping on our bootstraps on a daily basis?
My speech, “Why Organizations Are pretending To Leverage Digital Successfully, Whilst Failing Along The Line?” will clarify why our organizations are doing so - even with the best intentions - even with brilliant people. - AND - will show a way out of the Digitalization trap.
Synopsis
After passionately driving API programs for years, accelerating digital programs in Telco, Finance and Automotive industries, and after talking to countless teams, experts and managers in both Business and IT, I can see a common pattern.
Our organizations are making huge investments in new technologies, expecting almost immediately new revenues based on old business models.
They are introducing pseudo-agile methodologies to people who do not have an agile mindset and putting agile teams to the very end of their waterfalls. They are establishing shining Incubator Hubs, pretending to teach their customers on how to leverage Digital - without being Digital at all.
HR departments are still hiring people who are stabilizing the organizational status quo - still applying old-world-metrics to new-world-people. Enterprise Architecture departments are mainly acting as Digital Show-Stoppers. And last but not least, the most digital approaches are still lagging real Executive backing.
How can it be? What are the hidden mechanics to make us stepping on our bootstraps on a daily basis?
My speech, “Why Organizations Are pretending To Leverage Digital Successfully, Whilst Failing Along The Line?” will clarify why our organizations are doing so - even with the best intentions - even with brilliant people. - AND - will show a way out of the Digitalization trap.
The Team Member and Guest Experience - Lead and Take Care of your restaurant team. They are the people closest to and delivering Hospitality to your paying Guests!
Make the call, and we can assist you.
408-784-7371
Foodservice Consulting + Design
Artificial intelligence (AI) offers new opportunities to radically reinvent the way we do business. This study explores how CEOs and top decision makers around the world are responding to the transformative potential of AI.
The case study discusses the potential of drone delivery and the challenges that need to be addressed before it becomes widespread.
Key takeaways:
Drone delivery is in its early stages: Amazon's trial in the UK demonstrates the potential for faster deliveries, but it's still limited by regulations and technology.
Regulations are a major hurdle: Safety concerns around drone collisions with airplanes and people have led to restrictions on flight height and location.
Other challenges exist: Who will use drone delivery the most? Is it cost-effective compared to traditional delivery trucks?
Discussion questions:
Managerial challenges: Integrating drones requires planning for new infrastructure, training staff, and navigating regulations. There are also marketing and recruitment considerations specific to this technology.
External forces vary by country: Regulations, consumer acceptance, and infrastructure all differ between countries.
Demographics matter: Younger generations might be more receptive to drone delivery, while older populations might have concerns.
Stakeholders for Amazon: Customers, regulators, aviation authorities, and competitors are all stakeholders. Regulators likely hold the greatest influence as they determine the feasibility of drone delivery.
Senior Project and Engineering Leader Jim Smith.pdfJim Smith
I am a Project and Engineering Leader with extensive experience as a Business Operations Leader, Technical Project Manager, Engineering Manager and Operations Experience for Domestic and International companies such as Electrolux, Carrier, and Deutz. I have developed new products using Stage Gate development/MS Project/JIRA, for the pro-duction of Medical Equipment, Large Commercial Refrigeration Systems, Appliances, HVAC, and Diesel engines.
My experience includes:
Managed customized engineered refrigeration system projects with high voltage power panels from quote to ship, coordinating actions between electrical engineering, mechanical design and application engineering, purchasing, production, test, quality assurance and field installation. Managed projects $25k to $1M per project; 4-8 per month. (Hussmann refrigeration)
Successfully developed the $15-20M yearly corporate capital strategy for manufacturing, with the Executive Team and key stakeholders. Created project scope and specifications, business case, ROI, managed project plans with key personnel for nine consumer product manufacturing and distribution sites; to support the company’s strategic sales plan.
Over 15 years of experience managing and developing cost improvement projects with key Stakeholders, site Manufacturing Engineers, Mechanical Engineers, Maintenance, and facility support personnel to optimize pro-duction operations, safety, EHS, and new product development. (BioLab, Deutz, Caire)
Experience working as a Technical Manager developing new products with chemical engineers and packaging engineers to enhance and reduce the cost of retail products. I have led the activities of multiple engineering groups with diverse backgrounds.
Great experience managing the product development of products which utilize complex electrical controls, high voltage power panels, product testing, and commissioning.
Created project scope, business case, ROI for multiple capital projects to support electrotechnical assembly and CPG goods. Identified project cost, risk, success criteria, and performed equipment qualifications. (Carrier, Electrolux, Biolab, Price, Hussmann)
Created detailed projects plans using MS Project, Gant charts in excel, and updated new product development in Jira for stakeholders and project team members including critical path.
Great knowledge of ISO9001, NFPA, OSHA regulations.
User level knowledge of MRP/SAP, MS Project, Powerpoint, Visio, Mastercontrol, JIRA, Power BI and Tableau.
I appreciate your consideration, and look forward to discussing this role with you, and how I can lead your company’s growth and profitability. I can be contacted via LinkedIn via phone or E Mail.
Jim Smith
678-993-7195
jimsmith30024@gmail.com
Oprah Winfrey: A Leader in Media, Philanthropy, and Empowerment | CIO Women M...CIOWomenMagazine
This person is none other than Oprah Winfrey, a highly influential figure whose impact extends beyond television. This article will delve into the remarkable life and lasting legacy of Oprah. Her story serves as a reminder of the importance of perseverance, compassion, and firm determination.
1. 1
The Swisscom API journey #2
... it still requires changing our digital DNA
2. 2
Content
What happened so far ... 4
Imagine ... 5
Wheretop-downcrashesintobottom-up 7
It'saboutspeakingacommonlanguage 9
We had no clue, about how long the initial exposure phase would last ... 13
Wehavetorethinkourpretzel 15
Projectcentrismvs.APIcentrism 17
Theimportanceofanorthbound-map 19
Nosuccesswithout libraries 22
API-Management reloaded 23
(Why)shouldweavoidaggregation? 31
If we could go back in time ... 32
Things that are really hard to stand ... 33
The first API meeting in London ... 34
ElevenrulestokillanAPIprogrameffectively 35
About Swisscom 37
Imprint 39
3. 3
Changing our DNA doesn’t mean making things
‘a little bit better’ – it’s a fundamental change in
our nature rebuilding our way of working,
– from ground up!
IT-Coach & API-Evangelist
~ Kay Lummitsch
4. 4
What happened so far …
Seriously – The Swisscom API journey #1 raised
more questions than it answered. How could such
a small book be so successful?
1100 printed copies, over 2500 views on slideshare,
countless downloads and so many positive com-
ments from all over the world.
Awesome!That exceeded our highest expectations!
Edition #1 led to various discussions, and showed
that many enterprises are facing the same prob-
lems, even if the Powerpoint presentations are
sometimes telling a different story.
Answering the initial question – We made great
progress. Currently we’ve exposed more than thirty
APIs consumed by internal departments and com-
pletely changed our team set-up.
2015 is meant to be ‘The year of proof’.
~ The Swisscom API program team – March ‘15
We’re supposed to show that our elephant is finally
able to dance.
I’ve often been encouraged to work on a second
edition – so, today we’re happy to present you The
Swisscom API journey #2 – A deeper view
Thanks to all of you.
5. 5
Imagine ...
After having coffee I go to our huge, loft like
office, say Hi to the laughing guys in the entrance.
“Hey everybody! Welcome to our API kitchen”.
Wooden floor, big windows, beanbags and white-
boards. Architects sit amongst designers and de-
velopers discussing the implementation of an API
extension. Others work on the next API. Right next
to them, in the break-out area, developers are talk-
ing with business guys and app developers, show-
ing how their ‘problem’can be solved with existing
APIs.
They’re smiling!
In the middle of the room is a big open spaced kitch-
en. Kay is preparing omelettes for some developers,
teaching them about best practices.
Nearby is the Start Up Corner where Start Ups work
(for free). Currently two developers are with them,
gathering information about new trends in the
community.
Three plasma displays show the traffic on our gate-
way. “Wow – that’s a lot of traffic”. Another curve
shows revenue growth. We’re making money with
our APIs!! It’s already lunchtime and Kay serves
omelettes whilst standing around a huge wooden
table, talking about our next big vision for APIs …
* The so called Miracle question invented by Steve de Shazer – American psychotherapist
The API fairy comes into your room tonight, taps your head with
her magic wand – and all your problems are solved the next
morning. How would your day look like? *
6. 6
Pete Parker – CIO for Acme Inc., drops in. Formerly
in charge of enterprise services at Worldwide Insur-
ance Corp., he now leads a $10 billion big data initi-
ative. Acme Inc. is one of our long-time happy cus-
tomers, and is about to revolutionise our daily lives.
They use our partner APIs heavily, and are about to
reach their request limits again! We're discussing
pricing options to give them more requests. Great
to see how much we are helping them and that our
APIs are covering their needs – our customers are
making good business with our APIs.
That’s how a day
could look but the re-
ality is still different.
~ Imagine ~
7. 7
Where top-down crashes
into bottom-up
Edition #1 named it ‘Conflicts welcome’ –
here we want to go deeper into it.
Whenever business meets technology, tensions will
arise.
If we asked the business colleague afterwards, he
would answer something like this:
“Good Lord Help – This tech guy has absolutely no
idea what I’m talking about!”
And surprisingly the tech guy would answer:
“Lord have mercy Dude – This business guy has ab-
solutely no idea what I’m talking about!”
Seems funny but it isn’t – it’s our daily experience!
Unfortunately they are right – both of them –
100%.
Starting the API program, we hit the same prob-
lem over and over with no idea why we crashed so
hard. Back then, the team was composed of one
business representative and me – The API-Evange-
list – engaged in the development unit setting up
the API-Factory.
Whenever this business guy came, telling me how
things should be done, we ended up arguing. In the
end you could hear the sentences which mentioned
above.
Each of us saw arrogance and incompetence in his
opposite.
... crash-test-dummies at work
8. 8
... If we only had
a common language ...
Leveraging an API program means dealing with
this tension. We live in the hot-zone. That’s the
place where the friction starts between business
and technology. APIs provide a great opportunity
to bridge this divide.
What are we doing about this problem?
We have passionate discussions in meetings, always
keeping in mind that roles are speaking here – not
arrogant or even incompetent people. This helps
enormously.
Is it possible to overcome the divide between busi-
ness and technology in general?
In terms of APIs see – next chapter
~ Where top-down crashes into bottom-up ~
9. 9
It’s about speaking a
common language
... do you speak "API-ese"?
We’ll take the picture on the right to illustrate
two of our current problems.
The general naming problem
> APIs are named to fit the initial business request
(following our standard process), or the develop-
ment project. In this situation nobody knows what
is in the box.The names don’t reflect or describe the
APIs in any form. And they are tremendously sticky.
> APIs are named after internal development ver-
sions (that’s a hard one too!)
Internal backend system names & version pairs
are swooshing to the northbound interface. These
names have an extreme tendency to be seen at the
exposure layer ~ if we are not taking care of that.
> Finally the real API names (as they should be), are
not relevant to the affected stakeholders, and do
not play a role in this whole game.
10. 10
This little picture came into existence during an API core team meeting.
B = Business | T= Technology
~ It’s about speaking a common language ~
APIs
B T
11. 11
The communication/information problem
If APIs and we – the team that runs them
– are aiming to be accepted as the proxy between
Business and Technology, we have to be able to:
> Answer all relevant questions from the business/
consumers
> Hide anything that’s not absolutely relevant to
the business/consumers
> Protect the development unit from any business
interference
Being involved early is our current approach. We
started that involvement with an open attitude,
through consultancy and orchestration. Now we
step between the lines delivering appropriate infor-
mation and consultancy to the business (the North)
and useful information to development (the South).
In the near future you will hear us saying things like:
To the business/consumers:
“Project/Request X is going to make use of ‘API A’
and an advancement of ‘API B’. These will be ready
in X weeks from now. We are thinking about how
to provide you an ‘API-C’ to make it much easier to
adapt with your next project.“
To the API-Factory:
“We’ll need the customer-core-info_3.22.19 to de-
liver the enhancement to the Customer-Info API in
X weeks.”
As long this is not done, business will continue to
address development directly, and vice versa, as it
has always been.
~ It’s about speaking a common language ~
12. 12
The API program team has to become the commu-
nication proxy between North and South – exactly
like our APIs!
If we start by solving the communication problem,
the naming problem will solve itself.
Once this is done ... we’ve installed a common lan-
guage.
APIs!
~ It’s about speaking a common language ~
13. 13
We had no clue, about how long the
initial exposure phase would last …
... or how to keep the business units in-game
Our enthusiasm for APIs led to expectations
on the business side that the time to reap the ben-
efits had begun. Sadly it took way more time than
expected to expose neat and reusable APIs.
It's rare to hear voices talking about the problems
that arise during the exposure phase, and there are
plenty. The experts we met at conferences mainly
agreed on that. They are all facing more or less the
same problems. Seemingly, there is no formula for
success out there.
A well-known attitude inside big enterprises is to
differentiate external customers from customers
that belong to the own company. “This is just for
internal usage” – is an often-heard sentence.
We are putting in lots of effort to treat business
units as important customers instead of treating
them as ‘fellows in misery’.That seems obvious, but
it has to be done actively.
A business unit is not interested in exposing APIs – a
business unit is primarily interested in bringing their
new product to market – making use of whatever
technology that is able to make this happen.
We do not want them to be part of our struggle
anymore.
Our job is to consult them from the very beginning,
and keep them away from backend related discus-
sions, problems and complexities.
14. 14
~ We had no idea, about how long the initial exposure phase would last … ~
“I don’t care, if it takes you six months to
create a new API – I simply don’t care!”
~ Business representative during the TAD-Summit (Istanbul 2014)
Funnily, that’s exactly what an API is supposed to
do. That’s how we raise the trust in APIs.
see – it's about speaking a common language, p. 8
15. 15
We have to rethink our pretzel
We have to segregate data-delivery from data-management
An enterprise our size has prescribed stand-
ard-software-development-process to develop soft-
ware with a clear segregation of responsibilities.
Unfortunately this stays the same when it comes
to API-Development, -Exposure, -Management.
One consequence is that the development depart-
ment is responsible for:
> High enterprise-quality development of APIs
> Security & governance of these APIs
They have to make APIs enterprise-robust and save.
But not only in the technical context. They are still in
charge if it comes to the question: “Which amount
of data will be shown to whom?”
16. 16
~ We had to rethink our pretzel ~
In our case this led to APIs that suited exactly to a
given original business request. And this is frankly
“The same thing we did before – We just added an
API in front of it!” – And even worse, we produced
various APIs that are doing nearly the same thing.
Once we realized what we were doing there, we
stopped that immediately.
We decided to segregate data-delivery from da-
ta-management.
The data-delivery is responsible for bringing the
data to the service-exposure-layer and the da-
ta-management will have to decide, which amount
of data should be shown to whom – and it’s getting
even better – the data-management-team will be
enabled to make multiple behavioural changes to
the API without touching the originally proxy at all.
That was the missing part!
... until now …
“Experience is the name everyone gives to their
mistakes.”
~ Oscar Wilde
17. 17
Project centrism vs. API centrism
... on preventing ugliness
Our former approach to develop/expose/
manage APIs led to project driven APIs and an infla-
tionary growing amount of proxies, all of which are
doing nearly the same. The final APIs often serve a
single customer and are designed for very specific
use cases. Reusability of these APIs tend towards
zero. Each new project gets their own private API.
That’s what we call project-centric APIs.
Project-centrism is neither efficient nor does it scale.
We need a way to switch to API centrism. We want to
develop and expose APIs which are usable for many
use cases. We want reusable APIs.
As an enterprise we know how to develop software
in projects for many years. Processes are in place.
People are used to working with longtime product
life cycles, defined requirements and relatively slow
change processes. Establishing an API program -
even starting to expose APIs – doesn’t change an-
ything at first. For the developers the API program
just adds more API ‘projects’. We’re still vulnerable
to complexify things even more.
You read about the naming problem pointing to
the babylonian mess that can arise during API de-
velopment. You read about the problems finding
a new way to leverage cross-layer communication
and about the changes we made in our information
strategy. All this helps to become API centric. But
one – absolute crucial part is still missing.
A map of your future northbound interfaces.
see – next chapter
18. 18
~ Project centrism vs. API centrism ~
“You won't be able to please everyone – Aim to
displease everyone equally.”
~ Joshua Bloch: How to Design a Good API & Why it Matters,
Keynote at OOPSLA'05, San Diego, California, October 2005.
19. 19
The importance of a northbound-map
Leading the process is impossible without a northbound vision
How to change from reactive mode, – pledg-
ing to expose as many APIs as possible, generating
sudden usage and revenues – to leading the pro-
cess, and being the captain of our huge API-Ship?
Let’s take this analogy:
We have a good knowledge of the harbour we’re
departing from ...
“We know what we want to get rid of …”
We have great expectations for trading opportuni-
ties at the target harbour ...
“We’ll be part of the API business and generate great
new revenues.”
We also have a vague map of the seas between ...
“We’ve got a strategy!”
Get into active-mode!
21. 21
It’s where we translate backend assets into an
easy-to-understand API-Portfolio. In the morning
we’re discussing urgent problems – in the afternoon
we are shaping the future.
The approach reduces workload and uncertainty
on every layer. Things do not have to be solved over
and over again, and we are able to address the main
problems mentioned before.
Let’s keep on shaping!
But, because we’re in a hurry, we are dropping goods
over the railings on the pier at the target harbour!
That’s the next challenge to deal with.
We need a precise understanding of the rules and
conditions at the target harbour and a plan to op-
timise the unloading of goods to meet customer
expectations.
So, we’re creating a map! Shaping our northbound
map is extremely important to us.
The API-Design-Circle is a weekly interdisciplinary
meeting composed of enterprise-architect, solu-
tion designer, enterprise-service-bus specialist, API
product manager, developer and – of course – the
API-Evangelist. We also invite API-Experts and ex-
ternal community specialists to keep our thinking
outside-the-box.The Circle shapes both our current
API landscape and the course we steer.
~ The importance of a nortbound-map ~
22. 22
No success without libraries?
We often hear that “Our API program cannot
be successful if it doesn’t provide libraries’’. Indeed,
there is cool stuff out there that reads WSDL/RAML/
YAML/Whatever descriptor files and automatical-
ly generates libraries for most of the commonly
known languages.
Nevertheless, at the beginning we had to focus on
our first-level-APIs.
Now – as our map is taking more and more shape
we’re planning to provide libraries for our API con-
sumers.
23. 23
API-Management reloaded
“20% success is not enough!”
On the face of it, dealing with APIs seems to
be technical – technical interfaces, technical services,
and developers who think technically. Summarized –
this is tech-stuff. Our experience is that dealing with
APIs is 20% technical and 80% cultural. All the tech-
nical problems and details are solvable – the cultural
changes are much more difficult.
It follows that we’ll be just 20% successful if we focus
only on technical aspects.
So, keeping in mind that we aim to change our digital
DNA, we must do more.
You read about the separation of data-delivery and
data-management earlier in this book – that’s a cul-
tural move!
24. 24 This approach will enable us to deploy a new API...
... not in 6 months ... not in 6 weeks ...
(hold tight!) ... in many cases half a day!
~ API-Management reloaded ~
25. 25
Why (summarized):
Our former approach led to project-driven
APIs and a growing number of proxies doing nearly
the same thing.
In the future, we want to configure a fully-fledged
proxy using some kind of consumer profile – this
means the API will initially return the maximum *
amount of data which the consumer profile will
filter according to what the consumer is allowed
to receive.
Example: The API will return the full customer pro-
file with all details: addresses, contracts, subscrip-
tions, etc. but the end consumer will only receive
the first-name and the last-name.
This will unclutter our API offering enormously.
Thinking ahead, this will be the only way to keep
our APIs maintainable and manageable.
It will also reduce the workload for the API-Develop-
ment team because one proxy will be able to handle
multiple requirements.
* logic that prevents unnecessary backend requests is planned
~ API-Management reloaded ~
26. 26
What do we need?
Naked proxies: Future proxies should be deployed
naked, without any authentication/authorization.
Auth attributes should be switched on- and off-
using the consumer-profiles advice.
And again: Different authorization/authentication
scenarios will make use of the same proxy.
Full-fledged proxies (data-delivery at it’s finest):
Future proxies should deliver the maximum *, rea-
sonable amount of data in the context of the re-
quest.
Consumer profiles & filter engine: We want to be
able to apply consumer-profiles to API-Keys.
A filter policy should make use of these consum-
er-profiles and filter the returned data by the pro-
files advice.
The consumer profile is also able to make behav-
ioural changes to the API.
Consent engine: The consumer-profile should also
control the requests for consent.
Reporting capabilities: We want to be able to an-
swer questions regarding consumer access to data
at any time.
Governance: Each consumer-profile has to be ‘bless-
ed’ by the governance board.
Future thinking: Extension of the Profile-Syntax
to enable/disable querying at resource level with
query parameters as well as choosing between full
response, or links to subtypes and address trans-
lations.
* logic that prevents unnecessary backend requests is planned
~ API-Management reloaded ~
27. 27
{
“profileName“ : “CUSTOMER_BASIC“,
“productName“ : “happy-customer“,
“proxyName“ : “customer-info“,
“auth“ : “OAUTH2|NONE|BASIC“,
“consentRequest“ : “CUSTOMER_BASIC“,
“visibleFields“ : [
“customer.firstName“,
“customer.familyName“,
“customer.dateOfBirth“,
“customer.addresses.MAIN|*|plz“,
“customer.subscribtions.*“,
“customer.locations.LINK_ONLY“
]
}
Let’s have a look to a pseudo-profile:
~ API-Management reloaded ~
28. 28 … this little piece of Json code is able to revolutionize
our time-to-market!
~ API-Management reloaded ~
29. 29
~ API-Management reloaded ~
... at a glance
{
"firstName": "Ursula",
"lastName": "Schweizer",
"addresses": [
{
"streetAddress": "Hauptstrasse",
"houseNumber": "15"
}
]
}
{
"firstName": "Ursula",
"lastName": "Schweizer",
"language": "DE",
"gender": "female",
"birthDate": "1966-04-24",
"nationality": "CH",
"id": "1234567890",
"email": "u.schweizer@swisscom.com",
"addresses": [
{
"streetAddress": "Hauptstrasse",
"houseNumber": "15",
"city": "Zurich",
"postalCode": "8012",
"country": "CH",
"type": "main"
},
{
"streetAddress": "Nebenstrasse",
"houseNumber": "16",
"city": "Zurich",
"postalCode": "8013",
"country": "CH",
"type": "correspondence"
}
]
}
Filter
API-Gateway
Filtered response
according to profile
Full response returned by the API
30. 30
~ API-Management reloaded ~
This is an easy-to-use enterprise approach that will
improve and accelerate our work tremendously.
It will also enable us to separate data-delivery from
data-management – the cultural part.
Now the missing 80% is coming into our field
of vision.
31. 31
(Why) should we avoid aggregation?
... about losing control
It’s not unusual to hear during conferenc-
es that enterprises have a tendency to dislike ag-
gregation. We find ourselves in a similar situation
whenever aggregation is a topic of discussion.
The main concern is that aggregation decreases
performance and leads to unpredictable behaviours
in case errors occur. We risk to lose control and to
slip into random error-handling mechanisms.
So we have to aggregate with costs nearly ZERO
and deliver aggregated APIs that are predictable.
We’ll accept the challenge!
Surely, it does take time and energy to get there,
but for an enterprise, aggregation is not a job to
rush.
Once we know how to do it an enterprise-robust
and safe way, we are going to aggregate like crazy!
32. 32
… we would:
If we could go back in time …
> Setup the API-Factory, the API-Program team & the API-Design team
> Create a list of all relevant backend assets
> Enable Monetization/Analytics
> Introduce the common language - APIs
> Implement our northbound map step-by-step
> Design the northbound map ~ mapped to the list of assets
> Enable the platform to support ‘API-Management – reloaded’
> Setup the developer portal & provide API-Sketching
at the portal (Yaml/Raml) including speed mocking
> Implement a core API making use of all topics of this list
> Make our business units happy
33. 33
> It's hard to prove that APIs are reducing friction as long you're producing more friction and costs
than before.
> It's absolutely frustrating to organize hackathons without a minimum set of cool APIs.
> It’s hard if you can’t show a mock or test version of your APIs until they are finally exposed.
> It's hard to be forced to please everybody and to be accused for pleasing everybody at the same time.
Anton Rodriguez Yuste | Telecom Solutions Architect
> It's hard to fight proxy wars between business and technology in your own team. Consider
yourself lucky if you are friends enough to stand these. Stephan Karpischek | IT-Strategy consultant
> It's hard to make successful SOA APIs that have specific programming language dependencies.
Eugene Ciurana | Founder at Cosmify, Inc.
> It’s hard to propose APIs as a solution as long as no one sees a problem. Frank Buettner | Technology strategist
Things that are really hard to stand …
If you do not resonate with the following list – you made it!
34. 34
On March 22nd
we met in London for our first
EMEA-API meetup. Participants from the UK, from
Norway, the Netherlands, Germany and of course
Switzerland invested time and effort to talk about
their experiences in leveraging an API program.This
has been extremely insightful.
The discussions went far beyond the slide-show
level and we realized once again, that enterprises
have well known, common problems. And to share
them is a pretty good way to solve them. We are go-
ing to meet quarterly at different places in Europe.
The first API meeting in London …
… it’s about sharing experiences
Please ask to join our upcoming meetings.
35. 35
Eleven rules to kill an API
program effectively
ASK "WHY DO WE NEED API's"
AS OFTEN AS POSSIBLE
INCREASE COMPLEXITY
WHEREVER POSSIBLE
ASK EVERYBODY
– ALWAYS!
TURN ALL YOUR ENERGY INWARD
TRY TO BE PERFECT,
RIGHT FROM THE BEGINNING
36. 36
AVOID READING THIS BOOK!
(NEW & RATHER FUNNY)
DO EVERYTHING THEORETICALLY
FOCUS
ON PROBLEMS
BE EXTREMELY CAREFUL!
CREATE PROCESSES AROUND YOUR PROCESSES
OPEN AS MANY SECONDARY
STAGES AS POSSIBLE
~ Eleven rules to kill an API program effectively ~
37. 37
About Swisscom
Swisscom is Switzerland’s leading telecom provider with its headquar-
ters in Worblaufen, close to the capital city, Berne. With over 20,000 employees
it generated turnover of CHF 2.82 billion in the first quarter of 2014. Swisscom
is one of the most sustainable companies in Switzerland and Europe.
What we stand for
As a trustworthy companion in the digital world, we want to win peo-
ple’s hearts, make things simple and shape the future so our customers feel
safe and at ease.
Products and services
Swisscom offers mobile communications, fixed networks, Internet and
digital TV to corporate and residential customers. We are also one of Switzer-
land’s largest providers of IT services. We build and maintain the mobile and
fixed-network infrastructure, transmit broadcast signals and own shares in
media companies.
38. 38
Our employees
Swisscom employs more than 17,000 staff at locations throughout
Switzerland, around 1,000 of whom are apprentices. Around one in three
have direct daily contact with customers, either in sales or customer service
departments. Swisscom offers its staff excellent working conditions within
the framework of a collective labour agreement.
Who we work for
The Swiss telecommunications market has an estimated annual turno-
ver of around CHF 17 billion. Our market share varies between one- and three-
fifths, depending on the field. Swisscom has decided to focus on residential
customers, small and medium-sized enterprises and large corporations.
~ About Swisscom ~
39. 39
Imprint
Author: Kay Lummitsch
Passionate change maker | IT-Coach | Catalyst
API-Evangelist, Zurich – Switzerland
mail: kay.lummitsch@swisscom.com
mobile: +41 79 154 47 81
linkedIn: Kay Lummitsch
Co-Author: Stephan Karpischek
IT strategy consulting , Zurich – Switzerland
mail: kpi@kpi.at
mobile: +41 79 790 79 57
linkedIn: Stephan Karpischek
Design: Maude von Giese
Graphic Designer, Zurich – Switzerland
mail: maude.vongiese@gmail.com
mobile: +41 79 269 94 50
linkedIn: Maude von Giese
40. 40
Webversions: Edition #2
bit.ly/1DnIETv
Edition #1
bit.ly/1basqBk
Links: swisscom.ch
developer.swisscom.com
@swisscom_api
Special thanks to: Matt Chalmers (Apigee),
Eva Endress (Self employed),
Chris Novak (Apigee),
Christin Schmidt (Business-Coach)
Sarah Murphy (Swissom) for helping us with the text.
And of course the Swisscom API program team.
2nd
edition, March 2015
~ Imprint ~