Thursday, August 1, 2019

Short Sighted User Experience make life difficult for online bookings by:

  1. Forcing online registration for booking an eye test appointment online (despite already asking me a lot of these questions as part of the appointment request process)
  2. Generating an error that I haven't used a loyalty card number as part of the registration (which I do not have nor want)
  3. Not indicating that the loyalty card number is a required field

So I think I will phone for an appointment instead (thank goodness I didn't need glasses to find this out)

Sunday, July 21, 2019

Loyalty & a fragmented transport network won't work!

I recently read an article on about how USA-based transit providers are offering loyalty rewards to encourage usage of their services.

In my opinion royalty rewards are offered for only two purposes:
1. In exchange for customer data (e.g. give us your email for 10% off first purchase)
2. To change user behaviour (e.g. get 20% off rail fares for travelling off-peak)

However, this article got me thinking about how a multi-modal (rail, bus, subway, ferry, etc.)  transport network could never hope to implement an effective loyalty scheme if it only had one mode... in other words in a fragmented area, such as Scotland, could this work?

So here's my article on Linkedin explaining this in more detail:

In reality... of course I know it won't work unless:

  • All operators share the same technology/software/account application (and I know how unlikely that would be in a privatised industry)
  • There are ways for all these accounts to integrate together, so that an aggregated view of all accounts is possible in one place.
    And I think it is for this purpose that an Open Transport API should work towards.

Friday, July 19, 2019

Taking Mobility-as-a-Service Seriously

This week I have made it public knowledge the Ideal Interface has joined MaaS Scotland.

Although technically we joined just before I attended the MaaS Scotland Annual Conference in Edinburgh on June 20th... this announcement is part of my growing aim to get more involved in the ongoing development and industry acceptance of an Open Transport API for account interoperability.

Wednesday, July 17, 2019

LIFESPAR cloud architecture principles to follow

With more and more organisations adopting cloud technologies for their applications, I've seen the tendency to just "life and shift" architectures. Physical servers are replicated as virtual machines and the same software applications as before are run "on somebody else's computer". 
  • Latency-aware
  • Instrumented
  • Failure-aware
  • Event-driven
  • Secure
  • Parallelizable
  • Automated
  • Resource-consumption-aware

But this approach doesn't leverage many of the benefits of software-as-a-service (SaaS) or the new cloud-only components available as platform-as-a-service (PaaS). It also means that architects creating cloud-native solutions need to have a different set of principle to before.
Some of the best guidance I have seen in this area comes from Gartner, who use the acronym LIFESPAR to explain those principles to follow for designing cloud-native architectures.

So what is LIFESPAR and what does it mean to an architect?

Understand that every application needs to be designed & implemented knowing that it may not get an instant response to each request. This latency could be milliseconds, or it could be seconds, so ensure each solution elegantly deals with delays and is tested to prove it works under these conditions.

Every solution and every component must generate sufficient data about their usage and ideally send this information back to a central location, so that real-time & subsequent decisions about the architecture, cost, volumes, etc. can be made. In this way, as instrumented approach supports an elastic automatically scaling system (scaling both up AND down).

Remember that things fail (hardware, processes, etc.) and that software, created by humans, is never usually bug-free. So always design solutions that wait or fail & re- in the way you need them to. Failures must also be comprehensively tested - if necessary, writing code to force failures (e.g. the Chaos Monkey). Also bear in mind that in some scenarios... latency and failure are the same thing.

Applications used to developed with synchronous actions (as the performance, etc. of the target system was known). But now in a decoupled architecture, messages need be sent as events. This also simplifies scaling and makes them more resilient to failure.

Always assume your solution will be subject to some sort of malicious activity and try to prevent it. This means restrict events and users, minimising attack surfaces and following best practice data handing and security processes.

Many small systems are usually cheaper that one large one, even in the cloud. Therefore find ways to scale-out your solution and its processing & messaging, rather than scaling-up.

Every cloud-based component and also your overall solutions should be able to be deployed, started, stopped & reset via scripts. Remember to test this from a command line, from the beginning of development through to your Operational Acceptance testing (and even as a means of testing Disaster Recovery processes).

So, you now have almost limitless processing and storage resources at your fingertips. But you also either have your credit card charged as you use the service or are going to get an invoice for what you use very soon... Therefore, always consider using the least amount of cloud resources possible. Simplify your solution, build & burn of components & environments, automate components to start & stop only when they are needed and don't store more than you need (e.g. by sharing test data across solutions & environments).

Thursday, June 20, 2019

MaaS Scotland Annual Conference 2019

Today I attended the MaaS Scotland annual conference event in Edinburgh. Which brought together representatives from across Scotland, the UK and Europe to discuss recent developments and projects in the area of Mobility as a Service.

There were many interesting presentations, including those from Eric Mink from the Dutch Ministry of Infrastructure and Water Management (who mentioned the Dutch API Blueprint for MaaS)
And also Michael Matheson MSP, who is the Cabinet Secretary for Transport, Infrastructure and Connectivity. Plus also there was more information about the MaaS Investment Fund from Transport Scotland.

Thursday, June 6, 2019

Config versus Code - what's the difference?

I have worked on a few projects lately where the the conversation typically went as follows:
"We aren't coding anything, we are simply changing the configuration within the product"
or "We don't need to deploy our changes to Subversion/CVS/BitBucket/GitHUb as it is config not actual code" (and sometimes the word "actual" is stressed).

Sound familiar?

So I thought I would define what I thought are the traits and differences between config and and code:

Config is:

  1. Customisation of mature code, without affecting that code
  2. Held in a source control system, wherever possible
  3. Setting and changing parameters via simple instructions
  4. Carried out using a visual tool or interface
  5. Limited in scope (to what the developer wanted to expose)
  6. Best suited to making changes to SaaS (Software-as-a-service) products

Code is:
  1. Scripted or compiled
  2. Always held in a source control system
  3. Carried out using an IDE (Integrated Developer Environment) such as Visual Studio or Eclipse
  4. Far less limiting in scope (to what the developer wants to do)
  5. Where repeatable functionality is held
  6. Best suited to the creation of bespoke applications

Or put another way:
If you need a developer to make a code deployment once a configuration change has been made (to implement that config).... it is not config!

Wednesday, May 29, 2019

Launching the Open Transport website

Today I have launched the website for Open Transport:

This website explains the aim of creating an online account open data standard across the transport industry.

I have seen the start of the benefits that Open Banking has has in the Financial Services industry and I think the same thing needs to happen for the transit and transportation industry in Scotland, The UK, Europe and wider afield.

Perhaps this standard may even be adopted in other industries too.. perhaps the travel one.
(Can you imagine the possible benefits of all airlines being able to link their accounts, so that a customer could use just one login to manage all their details and see the data about their flights on different carriers?)