Developing Open Transport isn't about the the technology

I have been pretty involved in the creation of the Open Transport Initiative. A project, along with some very clever folk in the transport industry, to create a new interoperability open standard for transport / mobility accounts.

It has been personally rewarding (so far) and on 14 October we launched a near-finalised version of the customer account specification for peer review & feedback.

Several people have commented that this is a pretty significant technology, which (assuming it is adopted across the transport industry) could provide a similar level of integration and openness as Open Banking has provided to the Financial Services industry.

But the reason for creating this Open Standard and giving it away (eventually) isn't to show how technically proficient I and those around me are. It is to meet a growing need that has been identified... that a customer's transport data such as: purchases, usage and concessions is locked away in an account for each mode of transport.

Steve Jobs once famously remarked 'You've got to start with the customer experience and work backwards to the technology.' and this is what we have done. 

Why the cost of your cloud infrastructure could be too high

I've recently been been looking at some significantly increasing cloud hosting costs for a client.

There are a lot of reasons why this is happening... but in short, a lot of additional cloud costs come from these three causes:

1. Incorrect cloud architecture
This could be: not using “build & burn” practices, failing to automatically spin up (and especially spin down) components as needed, etc.

2. Processing more data than is needed
This could be: the creation of too many environments, badly sized test databases, etc.

3. Having unnecessarily stringent NFRs for non-production
In this could be: the high specification of development or test environments, running batch jobs too often and when not needed.

Open Transport Initiative is gearing-up for launch

I've been quiet on this blog over the last 6 or 7 weeks, as I have been working hard on a number of client projects and also getting things ready for the launch of Open Transport.

As well as the actual website: https://opentransport.co.uk/ there is now a Linkedin page online:

https://www.linkedin.com/company/open-transport-initiative/?viewAsMember=true

Knack Bags earns 5 star rating on TrustPilot

I'm very happy today that a Press Release for our client Knack (https://knackbags.com) has just gone live.

https://www.prnewswire.com/news-releases/knack-bags-reviews-earn-5-star-rating-300906864.html

Knack have (justifiably IMHO) gained a 5 star rating and some great reviews for their website, service and products. 

Transformation in Travel needs rethinking

If Digital transformation is all about the connected customer, then how can transport be truly transformational if it doesn't provide what the digital customer wants?

A customer doesn't want a fragmented mobility experience. They want a cohesive one that is consistent (but not necessarily exactly the same) across all digital channels. But how can transport deliver a truly mature digital experience when:

• Every train operating company (26 in the UK) is a difference franchise, most of them providing their own online account
• Many local bus services don’t have online self-service accounts and those that do have one for each operation / franchise (despite these services being run by the same parent company in a lot of cases)
• Public transport services have private competition which only allow their tickets to be accepted via their own mobile app

We therefore need a rethink of how every customer account for each transport provider integrates. And that this way of integrating is not locked to a particular operator or technology provider. To ensure that if I have 4 accounts with 4 different operators... I don't have to log in to each one to get a holistic / aggregated view of my entire transit purchases or trips.

Short Sighted User Experience

Boots.com 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)

Loyalty & a fragmented transport network won't work!

I recently read an article on Wired.com 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:
https://www.linkedin.com/pulse/supporting-loyalty-rewards-fragmented-transport-hayden-sutherland/

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.

Taking Mobility-as-a-Service Seriously

This week I have made it public knowledge the Ideal Interface has joined MaaS Scotland.
https://blog.idealinterface.co.uk/2019/07/19/ideal-interface-joins-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.

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?

Latency-aware:

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.

Instrumented:

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).

Failure-aware:

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.

Event-driven:

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.

Secure:

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.

Parallelizable:

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.

Automated:

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).

Resource-consumption-aware:

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).

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.

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!

Launching the Open Transport website

Today I have launched the website for Open Transport:
https://opentransport.co.uk/

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?)

Architecture vs Agile

There are various technology "holy wars" that have been fought throughout the years.
PC vs Apple
Thin client vs Desktop computing
etc.

Some have been resolved and some still continue to this day.

And now, as more digital / business transformation projects are adopting an agile approach to software configuration and development... another battle, albeit one that has been raging for some while, is growing in its intensity and prominence.... That of the agile approach vs the need to define architecture for a solution in advance.

As both a supporter of agile to create products & get feedback quickly, and an architect of digital products and services (both large and small) I understand both sides of this war.

Agile:
Wants to develop minimum viable products as quickly as possible, then get this in front of users and rapidly iterate towards completion. The focus is on "good enough" not excellence and likes the flexibility to change & improve features.

Architecture:
Designs those things that do not move... and the resemblance to buildings IS intentional. Architecture is usually fixed for the long-term and gives the foundations for other more nimble practices around it. Technical Architecture (what I define as the combination of the Enterprise Architecture and Solution Architecture disciplines) should provide general directions (e.g. public cloud/hybrid/private, buy vs build, etc.) and standards. Plus architecture should also make  higher-level decisions on technology and principles which would be hard to change subsequently (e.g.coding language, integration methods, etc.).

Where things get messy is in the lower-level design of applications and their solutions. Here is where the agile versus architecture battle is waged. Where teams need to be empowered sufficiently to create products that meet the user stories... but also need enough guard-rails and check-points to operate within governance.

When not to use an API

In an earlier post, I covered how there are now "APIs with everything"

However, it is not always that a system designer would use an API for integration. Here are some scenarios where you would consider NOT using an API:

• When an API is not available, for example the vendor has not developed one yet
• When an API does not meet the necessary non-functional requirements (for example: security, performance, volume, availability, etc.)
• When you already have a tightly coupled integration between two systems and there is no need to change/upgrade this 

Have I missed any?

Non-functional requirements - is that the best description?

Thought for the day:
The term "non-functional requirement" is a bit daft really. As it implies that you have a requirement for a feature that does not help functionality.
Perhaps they should be called operational requirements?

How to write online testimonials

My consultancy help a number of clients with their website content & optimisation. Most of the time we find that providing a testimonial helps provide 3^rd party validation of their product or service.

So how do you write an online testimonial? Well the most obvious thing to state is that “less is not more” and usually the more that is written (within reason) the more the testimonial is useful … for content, usability and potentially search engine optimisation too,

So consider building up your testimonial beyond just a single one line quote to:

• A sell-worded longer quote*
• Quote plus image**
• Quote plus hyperlink***
• Quote plus hyperlink plus image
• Quote plus full case study

* the quote is usually a few short sentences or a paragraph statement from an existing client (ideally with name, title & company) or customer review

** the image is usually of person, but other obvious image can be used

*** the hyperlink is typically a call-to-action" (e.g. "contact us to get a quote now" "read our case study here" or "find out more about xxxxx".

Picking what NOT to do is an IT Strategy

Technology change and progress never stops. There is always a newer version, a better alternative piece of software or another way of supporting an evolved business process or two.

For internal technology departments and especially those within larger organisations, this rate of change means there's never an end in sight. In a world of infinite need and finite resources... there's usually a long list of things to do once the current projects & programmes have been delivered.

With all this demand and the expected pace of implementation (that can come from all angles including: business stakeholders, vendor sales people and consultants) it can feel like everyone wants to change everything at once:
New finance system? Yes
New HR software? Sure
New B2C website? Of course
New B2B website? No problem
New sales portal? Yeah
New customer data platform? Naturally

Faced with a these requests, perhaps along with a potential new-found investment in technology to fuel a "digital transformation", senior IT people will want to say yes. Who wouldn't want more resources, increased budgets, the chance for some new "toys" or the opportunity to stick a big 'look what I've done' post on their LinkedIn profile?

But like the proverbial plate spinner, who (theoretically at least) should know how many plates they can spin at once... those in a position to take on technical work need to understand how much change they can take implement before they hear the sound of virtual crockery smashing. Experience needs to inform them (and so do their managers, subordinates and peers) just how much change their organisation can take on in parallel.

But when the demand for so much change outpaces the organisation's ability to deal with that change, someone has make the important decision as to what to do and therefore what NOT to do. 

Nobody, least of all IT people (prehistorically noted for saying "the answer is no, now what's the question?") want to tell a business stakeholder that their project is less important than another... but sometimes there is only so much change you can do at once.

Advice on Video Search Engine Optimisation

The aim of video SEO is simply to make it as easy as possible for both YouTube and Google to understand all video content. And why wouldn’t you? With Google being the largest search engine and YouTube being the second, it is more and more important that companies now factor online video optimisation into their marketing efforts.

Since Google can’t fully understand what your video is about without help (not yet, anyhow) optimising your clip currently means providing as much textual information about it. This is so that search engines can properly index it and then show it in their relevant search results.
My advice here is therefore:
Creating an optimized title is perhaps the most obvious thing to do, yet is probably one of the most overlooked. The clip title should be several words long (we tend to keep to the same 55 – 60 character range we recommend for web page title optimisation) and include the major keyword(s) you want to your video to rank for. Note: There are differing opinions on whether the keywords at the beginning of the title give more of a boost than those added subsequently… but I have found no definitive proof of this.

Description
Insert as much text as you realistically can into the description field of your clip. Add words about the video content, the people or characters, the situation or product it shows, and the usage or benefits being explained. In short… consider this a blog post and use several hundred words if possible. Obviously, any content placed in the description needs to include your targeted keywords from your SEO strategy, plus don’t be afraid to sometimes repeat keywords or derivative terms here
If your clip contains people speaking (e.g. a voice-over or some dialogue) strongly consider obtaining a transcript of the text and inserting this in the description too.
Don’t forget the transcript can also be:

1. Used to correct or improve the closed captions, which you must consider - Sure, YouTube can auto-transcribe your audio content, but not any visual content than you may also want to describe
2. Added as additional content into any web page that embeds this video clip (potentially providing some on-page SEO help too)

Video Tags
There is growing consensus in the SEO community that tags for YouTube clips have minimal optimisation benefits (but they do help with cross-linking between clips with the same tags). So still use them to describe your content in the same way you would a social media or blog post. However, remember to use those tags which highlight the uniqueness of your video (and therefore avoid very generic and therefore very competitive terms).

  

Title information

Remember to provide bespoke information about each different clip uploaded.  Don't upload the same clips with different info title & descriptions.

(Although I have no personal proof that this is "black hat" SEO activity... it does go against the very premise of what Google is trying to do. Plus, if it was suddenly treated as such... it could have a lasting negative effect.)

Comments

Encourage comments, ask for them and respond back when you do get them.