Ricky Moorhouse

I live in the south of England with my wife, two children and our dog Nova. I work at IBM as a Cloud Architect for API Connect cloud services. I enjoy running, walking, photography and spending time with my family.

You can find me elsewhere on the web- github- bluesky- instagram- mastodon- threads- linkedin

Product Academy for Teams - San Jose

Last week I had the opportunity to attend the three-day Product Academy for Teams course at the IBM Silicon Valley Lab in San Jose.

This brought together members of our team from across different disciplines - design, product management, user research, and engineering. It was fantastic to spend time face to face with other members of the team that we usually only work with remotely and to all go through the education together learning from each others approaches and ideas. The API Connect team attendees were split into three smaller teams to work on separate items and each was joined by a facilitator to help us work through the exercises.

We spent time together learning about the different phases of the product development lifecycle and in each looking at the process some of the best practices and ways to apply them to our product. It was particularly effective to use real examples from our roadmap in the exercises so we could collaboratively apply the new approaches and see how they apply directly to our product plan.

Each day of the course looked at a different phase of the product development lifecycle - Discovery, Delivery and Launch & Scale:

Discovery - Are we building the right product? - looking at and assessing opportunities and possible solutions we could offer for them, using evidence to build confidence and reviewing the impact this would have on our North Star Metric.

Delivery - Are we building it right? - ensuring we have a clear understanding of the outcomes we're looking for, how we can achieve them and how we can measure success.

Launch & Scale - Are customers getting value? - ensuring we enable customers to be successful in their use of the product and that we are able to get feedback and data to measure this and improve.

Each of these phases has an iterative approach to it and we looked at how we could apply these to our product plan. We also looked at some of the tools and techniques that can be used to help us apply this and members from the different product teams attending shared how they are using these today.

On the final day of the course I also had the opportunity to share some of our journey with instrumentation, how this has evolved and some of the lessons we learnt along the way - such as the benefits of having a data scientist on the team. I am looking forward to sharing this with the wider team and seeing how we apply some of the learning to improve our systems going forward. For example, better validation of decisions through measuring and improving our use of data.

Mount Tamalpais

I headed up from San Francisco to Mount Tamalpais State Park to explore the area and see some of the sights before heading down to San Jose. I drove through the spectacular scenary of the State Park heading up above the clouds and winding round the mountains to the East Peak car park and then heade out along the Verna Dunshee trail around the peak - the views were amazing and the scenery was spectacular. I then decided to head up to the top along the Plank Walk trail to see the views from up by the fire lookout at 2571 feet.

Chapel at Castlemartin Range

Green Bridge of Wales

Carew Castle

Barafundle Bay

Freshwater Beach

API Connect Quick Check

This script originated as part of a much wider framework of tests that we put together when I was in the API Connect SRE team. However I’ve found this set of functions to be something useful to be able to validate quickly from time to time in different contexts to give a high level answer to ‘Is it working?’

The steps this script takes are as follows:

  • Authenticate to the API Manager Platform API and retrieve an access token
  • Take a templated API and Product and modify it to return a unique value
  • Publish this API to a nominated catalog
  • Invoke the API through the gateway (looping until a successful response is seen)
  • Query the Analytics APIs to find the event logged for this invocation (again looping until found)

Whilst the entire test frameworks a lot of assumptions around how our environments are built and deployed, this test was relatively standalone - and I just needed to make a couple of updates to it to work outside of our cloud deployments - add support to turn off certificate validation and for username/password instead of API Key based authentication. Take a look at the script on GitHub.

If you want to try this in your own environment you can follow these steps:

  1. Clone the repository

    git clone https://github.com/ibm-apiconnect/quick-check.git
    
  2. Install the python required dependencies

    pip install -r requirements.txt
    
  3. Identify the appropriate credentials to use for your stack - either username/password or an api-key if you are using an OIDC registry and set these as environment variables (APIC_API_KEY or APIC_REALM, APIC_USERNAME & APIC_PASSWORD) or use the command line parameters - either of:

    • -u <apim_user> -p <apim_password> -r provider/default-idp-2 (Local user registry or LDAP)
    • -a <apim_api_key> (OIDC e.g. SaaS)
  4. Download the credentials.json file from the toolkit download page to identify the client id and client secret for your environment - these can either be set as environment variables (CLIENT_ID / CLIENT_SECRET) or as command line parameters (--client_id / --client_secret)

  5. Run the script according to the usage examples

    python api-deploy-check.py -s <platform-api-hostname> -o <provider_org_name> -c <catalog_name> [credential parameters]
    

If successful, you should see output like this:

Example output from the script

I'd be interested to hear if you find this useful or if you have other similar utilities you use already - let me know!

Originally posted on the IBM API Connect Community Blog