Project 1 Output: The Innovation Platform

Second of a series of posts from an unpublished book chapter written in 2002 Lifestyle management services
One of the key features of the client’s existing service offering was a suite of lifestyle management services. These were services that were intended to help individuals manage busy lives. The services used included shopping advice services, dating services, and a concierge service. A mix of web, SMS, IVRS and call centre staff were used to offer their services. User research showed that this approach was popular with the target market segments. Further research gave pointers to a basket of lifestyle management services that could form the basis of a set of applications. These were prioritised, and then presented to focus groups to further refine the service profile. Financial and travel services were an important component of the proposed service package, along with location-based services and tools. There was also demand for communication based services, such as instant messaging, and location-based buddy lists which would alert users if they were in the same cell as friends. Multi-platform delivery requirements
One of they main issues concerning the client was the explosion in device types. Where they had begun as a GSM operator, specialising in voice and IVRS services, they were now already offering SMS services (including location broadcast messaging), running a web portal and were starting to deal with WAP – and the incompatibilities between their providers microbrowsers. They were beginning to plan a GPRS network, and were also considering bidding for a 3G licence. It was clear to them, looking further east to Japan and iMode, that the next generation of phones would add many more user interfaces and many more form factors. Wireless connected PDAs would make things more complex still. Any solution they adopted would have to be able to be adaptable enough to support these technologies and platforms, and the changes that would occur with shifts in fashion as the new season’s phones rolled out. The ability to cope with rapid change was a key driver for any platform development. A conceptual architecture for rapid service delivery
A solution to these problems was put together, and quickly became known as the Innovation Platform. Designed to be a component-based application architecture, it could best be thought of as a bus structure that would allow new applications to be plugged into the service as required. With well defined APIs, new versions could be swapped out, and unsuccessful services removed. User interfaces and other core services are functions of the bus. While conceptually a messaging architecture, it could be developed using other component technologies, such as JavaBeans or COM – or frameworks like CORBA. All that would be required to link components would be a will defined protocol that could handle serialised data and manage events, as well as call methods and return results. Fixed APIs
Fixed APIs are a key to delivering an Innovation Platform, as they guarantee its “plug and play” operation. Instead of changing APIs from version to version, applications and components will need to be designed to have fixed APIs that will not change. Any versioning will need to be side-by-side, so that services that use component A version 1 will still be able to operate, despite the release of version 2 and the services that use it. The operator will need to fully document its public APIs, and component and service developers will be contractually obliged to do the same. Service descriptions
As an Innovation Platform would offer a plug and play software bus for applications and components, it would need to offer a set of tools that would document APIs and service locations. This would be shared with partners and partner developers, to help them develop new applications. Service descriptions would also be used to generate an application directory for end-users, in addition to any navigation model. Service managed user interfaces
Any service must offer a single user interface and navigation metaphor to its users. One of the problems with WAP portals is that when a user passes from the portal site to hosted services, the look and feel changes. An Innovation Platform, acting as a host for applications and service components, would be able to avoid this by defining display rules and templates. Applications would deliver content to templates, rather than directly to user devices – allowing the operator to control look and feel, as well as enforcing their brand values and brand experience. Open interfaces to operator services
Another important feature of the Innovation Platform was to be a set of APIs that gave third parties access to operator services. These would include network services, such as SMS and location information, as well as access to billing and account services.