Service oriented infrastructure (Part 2)
SDKs: fundamentals and futures
In this paper, Software Development Kits (SDKs) are defined and the motivations for developing them are examined in detail.
A framework for the analysis of SDKs is then presented that is based on value chains. A number of current SDKs are analysed
to illustrate the use of the framework and the results of these analyses are then used to inform a discussion about the future
directions in which SDKs might develop.
Software Development Kits (SDKs) are widely used and have
been well known in the software industry for many years. For
the purposes of this paper, we define them as collections of
software tools, encapsulations, abstractions and
documentation that can be used to develop software for
specific tasks in specific domains. An SDK is developed by
one group or organisation with the intent that it will enable
other groups or organisations to access functionality that
exists on a device or network and control or use it from their
software applications. This definition excludes libraries that
are designed to enable the reuse of abstract software such as
pattern frameworks and algorithms and focuses on enabling
access to functionality provided by a device or asset
(including data assets). Because we are using this definition
when we write about an SDK in this paper, it should be taken
that we mean both the exposure interface for a set of
services and the functionality they provide.
1.1 The changing context
Given the definition above, should a company like BT be
interested in the development of SDKs?
For more than 40 years, Moore's Law has correctly
predicted the exponential growth in the amount of
computing power at our disposal. IP networks have made it
possible to connect all this power quickly, simply and
efficiently. Opportunities have now been created to make
use of the latent functionality and underused capacity spread
across the resulting 'Cloud' and these in turn are allowing
organisations and, increasingly, individuals to offer
software-based services to other network users.
The telecommunications industry has also witnessed
significant change. Until about a decade ago, new cables and
equipment often had to be installed before new services
could be offered to customers. It was a costly and timeconsuming
process, so it was unusual for accompanying
software development work to be on the critical path. The
situation has now changed. Increasingly, the industry's
products and services are defined by software deployed onto
the routers and processors built into its networks.
One consequence is that software development is now
very much on the critical path when it comes to the launch of
new products and services. This has made the productivity
and performance of operators' software development
processes a significant competitive differentiator.
Of greater significance in the context of this paper is the
opening of the service creation process to a broader range of
developers. This has two main benefits. First, research has
shown that users who participate in the development of
services are more loyal . This factor is of great importance
to telecommunications operators, who are typically expected
to finance upfront to cover development and deployment
costs themselves, generating returns over an extended
period of time. The more loyal an operator's customers are,
the more likely an overall return is to be achieved.
Second, users are an efficient source of product
innovation . Many companies, notably Johnson &
Johnson and Nike, have developed open innovation
processes in which users and others generate many of the
ideas eventually taken to market. More significantly, entire
industries have been built on the innovations of their
customers. Examples include:
- mountain bikes, a category of product conceived and
developed by a user community that has come to
dominate the cycling industry;
- the GNU-Linux operating system and eco-system,
which was developed by unpaid volunteers; and
the army of 'pro-sumer' software developers that
creates an extraordinary range of often-complex Excel
spreadsheets every day to solve the business problems
Some of this won't be new to anybody, of course. Even
as far back as 1975, ICT companies were experiencing
productivity problems in their software development
processes. (Fred Brooks wrote about the problem in his
seminal work, 'The Mythical Man Month' , which was
published that year.) The use of standard interfaces and
standard Application Programming Interfaces (APIs) has
driven the entire PC industry for more than 20 years.
What is new is the spread of software and
'programmability' into business processes and other areas of
functionality. Increasingly, these too can be configured using
soft switches and SDKs. Consider network configuration,
printer administration and remote desktop management, for
example. In the past, specially-configured devices had to be
provided for many applications. Often, this involved the
provision of additional hardware. Now, the vast majority of
applications can be supported using computers with
standard hardware configurations and operating systems.
Specialist requirements can be met by providing additional
layers of software. Decisions about bundling, wrapping and
presenting software functionality to users – for example,
where on the value chain that presentation should take place
– are now central to every service provider's strategy.
1.2 Internal vs. external; client vs. server –
the SDK value chain
SDKs are a convenient way for one business unit or IT platform
to make functionality available to another. There are differences
between internally-facing SDKs and externally-facing ones,
however. For example, the owners of internal platforms operate
in a management hierarchy that makes it difficult for them to
turn down requests for changes or exceptions to facilitate a
rapid product launch. The users of the SDK are obliged to select
and use the internal platform, and are therefore obliged to put
pressure onto the providers to support them. In contrast, the
creators and users of externally-facing SDKs are more loosely
coupled. Creators can actively seek feedback from users while
promoting the use of their SDK. Users can simply evaluate the
offering against their requirements, abandoning it if it falls
short of their selection criteria.
The pressures and relationships will also vary depending on
the nature of the organisation that provides the SDK. Those
operating infrastructures used in medical settings – in the British
National Health Service, for example – will be subject to different
pressures to those whose infrastructure is used in a military
setting, such as the British Army. The pressures involved will affect
both the way services are exposed and the functionality provided.
2. The SDK value chain
In this paper, we focus on the drivers for SDK development
and describe some of the possible directions in which SDKs
might evolve. The case of SDKs developed for use within
organisations is too complex and context-dependent to be
considered in detail, so we will focus on externally-facing
SDKs – those offered by one organisation for use by others.
By looking externally, we can also treat the provision of an
SDK as a mechanism to provide value to customers.
Our introductory discussion established that the
motivation of an SDK developer is to enable others to use
functionality it has available. By doing so, it can make
professional developers more productive and enable them to
access functionality not previously available.
To commercialise an SDK, the organisation must identify:
- who is being given access;
- how access is to be controlled;
- which services are to be exposed, how and to whom; and
- the price, if any, at which services will be made available.
A good analogy is the security arrangements at a
nightclub. The nightclub operator will have made significant
upfront investments in order to provide its services, on top of
which a range of ongoing costs must be met. To preserve the
value of the club's facilities, access must be controlled. Were
access open to all, the club could become overcrowded and
dangerous and undesirable characters could enter whose
presence drives the best customers away, reducing revenues.
Incidents of bad behaviour may require the club to be
cleared, further reducing its takings.
The use of appropriately tough staff on doors can solve
some of these problems, but nightclubs tend to do better if
they implement a multi-layer multi-function strategy that
goes far beyond entry controls based on hard-and-fast rules
about dress and age group. The ideal is to add value to each
user's experience. For example, door staff can be given
discretion to admit special guests whose dress falls short of
requirements – the kid in the scruffy trainers who's the DJ's
best friend, perhaps. Bar staff might be asked to suggest
extravagant but expensive cocktails to increase takings, but
allowed to open bottles of beer or water on request. And
when high-spending regulars turn up, hosts can also adapt
their response – by showing them to a table their friends are
partying at, for instance.
Figure 1. Value chain models
SDKs must do a similar set of jobs, making appropriate
functionality available to the correct users on their choice of
devices. However, the questions must be thought through
from a somewhat different perspective.
The activities that add value to an SDK that is addressing
external customers are outlined in figure 1. The generic value
chain  contains five primary business activities that add
value to create propositions that customers will pay for. The
mapping of (for example) operations to API development is in
some ways arbitrary; it could be argued that the development
of the API is more analogous to marketing and sales, in the
sense that this is the 'shop front' for the asset exposed via the
SDK. However, by identifying the activities that create an SDK
as provided to users, we can create a framework that helps us
understand the elements of existing SDKs and identify how
and where the technology might evolve in the future.
The elements of the SDK value chain that we have
- Processing, data access or connectivity provision, which
involves the provision of the raw material of computation
or network resource. The functionality provided may be
associated with quality of service guarantees and it may
be of the form of access to special resources such as
unique algorithms or real-time data feeds.
- API development, which includes the provision and
maintenance of an appropriate set of calls and access
bindings that allow the underpinning functionality to be
manipulated. In Porter's original value chain , this
step is labelled 'operations' and defined as the
transformation of inputs into products and services. This
is analogous to developing the service wrap for some
piece of functionality.
- Exposure and access control. The provision of a
functional and convenient API is the first step to making
it usable. The utilisation of the service must be managed
to prevent over exploitation, the exposure function must
provide protection against denial of service attacks and
assurance to the user that they are connected to an
appropriate and authentic resource. This is the step in
the value chain that makes the functionality really
accessible for the developer.
- Directory services and user interface. Once API calls
have been discovered by users, the ways in which they
can be manipulated must be understood before they can
be put to use. This element of the value chain includes
- User communities and support. Service is provided in
an SDK value chain via either traditional technical
support or user support communities.
The description of the SDK value chain has enabled us to
frame a set of questions through which we can characterise
particular implementations. Working through the value
chain, our questions are as shown in table 1.
There are no 'right answers' to any of these questions.
The choices developers make are determined by the business
context in which they find themselves, the technological
facilities to which they have access and the market at which
they are aiming. In the external setting, these decisions are
informed by commercial considerations; someone has to pay
for the cost of providing the service.
This pressure motivates the first category of questions –
overall positioning. An obvious difference between an SDK for
a video card and an SDK for, say, Lego Mindstormsï¿½ is that
the former is aimed at a community of professional
programmers while the latter is aimed at young consumers.
This difference will inform the structure of the rest of the SDK.
| Overall positioning|
|What user group is the SDK intended to address (consumers, third-party developers, in-house developers, device
developers, children, product managers)?
Via which devices and system is access enabled (handsets, GUIs, XML interfaces)?
What network resources are required for access to be possible (constant connectivity, broadband, intermittent
Who is paying and when?|
| Processing, data access or connectivity provision|
|What functionality does the SDK make available?
What are the chargeable transactions that are enabled by the SDK?|
| API development|
|How is the lifecycle of service acquisition handled?
What granularity of service is provided – and what is the level of control and customisation that is offered to the service
What mode(s) of interface are offered (streaming, batch, synchronous, asynchronous/eventing)?|
|Exposure and access control|
|What authentication processes are required?|
Who is the authentication authority?
What guarantees are there that services will be maintained in the future?
How will versioning of these component services be managed?
|Directory services and user interface|
|What are the abstractions that the SDK uses to enable programmatic manipulation of resources?|
Table 1. Questions used to characterise SDK implementations
3. SDKs examined
In this section, we will look at some key offerings from ICT
market leaders. These are:
- Windows SDK  and Popfly from Microsoft 
- Google Search  and Android from Google 
- iPhone SDK from Apple 
- SDK from BT 
- Ribbit 
According to Wikipedia, other candidates we could have
chosen included the Eclipse SDK, the Flex SDK, the Java SDK
and the Qt SDK. These SDKs allow developers to access
software components such as integrated development
environments and user interface libraries. Based on the
definition presented earlier, we have ruled these SDKs out of
scope. They don't facilitate access to an underlying resource
or functionality that has an independent purpose. Android
and Windows are primarily platforms that have an SDK, for
example, while the iPhone and the BT network are clearly
physical assets. Clearly, it is difficult to draw the line between
an asset (such as a visual programming interface) that is
intended as an enabler for access and the fundamental
offering itself (like the permission management system in
Android), but we won't discuss this issue here.
The selected SDKs are described below and compared
using the value chain framework in table 2.
3.1 Windows SDK
The Windows SDK is the facility Microsoft provides to allow
developers to access functionality built into Windows
operating systems such as Windows XP, Windows Vista and
Windows Server 2003.
It is comprehensive and extensive, reflecting the
complexities of the Windows operating system and of
modern personal computers and servers. A very large
number of basic interfaces and calls is provided and
wrapped into a Common Intermediate Language (CIL) which
is then used to underpin functionality exposed via a number
of different languages (C#, Visual Basic, C++, etc.)
supported in a common developer environment (Visual
Studio .NET). This strategy promotes developer mobility and
flexibility, motivating developers to learn to create
functionality using Microsoft's assets by assuring them that
they are acquiring transferable skills that will remain
valuable as the technology landscape (as defined by
Microsoft) changes. Recently, Microsoft has focused on a
number of research initiatives that promote this approach
including extensive work on Domain Specific Languages and
the Volta system .
These technological assets are supplemented by
extensive on- and off-line training materials and
documentation as well as numerous conferences and events
to inform the developer community of the available assets
and promote them to that community.
Popfly is another Microsoft SDK, but rather than enabling
developer access to assets provided by Microsoft, Popfly aims
to enable access by consumer users to assets on the open
web. Some of these assets are wrapped and exposed by the
Popfly project at Microsoft, and include Microsoft provided
services, however a large number of assets are provided via
developer key managed 'blocks' which encapsulate complex
calls to resources. These blocks are created by third parties
and then published to the user community.
Interaction with Popfly takes place using the Silverlight
system. This enables sophisticated client-side tooling and
interaction to be provided via a web browser, including
community resources and support and visual programming tools.
3.3 Google search
In 2008, the Google search engine was the dominant
mechanism for discovering data on the web via keyword
search. It offers access to a keyword index of resources
available via HTTP and other protocols addressable via DNS.
The dominant use case of the Google index is via a web
page. However, it is easy to address the asset directly using
HTTP queries – for example via the Greasemonkey  script
in figure 2.
A range of commands is available to control the search
results obtained including date ranges, site constraints and
In addition to the general search interface which is
accessible via google.com, Google offers a range of APIs and
guides to specialist search technologies. These include
Google Ajax Search, Desktop Search, Code Search and
Custom Search. All are supported with documentation, blogs
and discussion groups.
Android is an operating system and application development
framework for mobile devices. In addition to enabling the
development of three-tier applications on a mobile device,
Android provides a full blown mobile operating system with
protected memory process management and sophisticated
task management and notification functionality. In addition,
while Android is based on the Linux kernel, the process
distribution and management model is implemented with
regard to the constraints of mobile devices, specifically the
difficulty of managing virtual memory requests in the
context of devices with constrained memory footprints.
Android contains a set of components that allow it to be
used as a mobile internet terminal enabling a Web 2.0
application experience on the move. Specifically, Android
engine (SQLite), libraries for secure communication (SSL)
and eXtensible Messaging and Presence Protocol (XMPP)
messaging. Android also provides a comprehensive security
and access control model for user data. By preventing
unauthorised access to resources such as users' photoalbums
and contact lists by third-party applications, this has
made a developer ecosystem possible.
The SDK allows the functionality of the Android platform
to be exploited at an application development level by
anyone with Java skills. It is aimed at handset developers,
enabling them to customise and extend the Android platform
for implementation on their devices, and at third-party
application developers who are able to implement
standalone applications that should be portable between
instances of Android.
To encourage take-up of Android, Google has created the
Open Handset Alliance . The alliance is working to prevent
platform fragmentation, ensuring that Android applications
can run across various handsets and enabling innovation.
Figure 2. Greasemonkey script
3.5 BT SDK
The BT SDK provided a set of libraries that manage
authentication for users of services originated from the
company's networks and IT systems or from infrastructure
and databases secured for exposure under various
Access to conference call, SMS and voice calling
functionality was provided along with (in early versions)
location, contacts and 'information about me' services. Services
were exposed through SOAP-based web services using web
service standards for authentication and authorisation.
Support for developers was offered through .Net and
Visual Studio and also via Java, PHP and Python bindings.
In October 2008, BT withdrew its SDK in favour of that
from Ribbit, a company it had recently acquired.
Ribbit offers an SDK that provides manipulations of client-side
functionality via Adobe Flash and functionality from the Ribbit
SmartSwitch. This allows SDK users to build applications that
control the flow of actions and instructions across various
signalling standards and networks. For example, a call can be
routed to a mobile phone, a fixed line phone and a web
browser. When it is picked up on one of these, the SmartSwitch
will notify the other two to stop 'ringing'.
The development kit, which is based on Adobe Flex,
allows easy development of voice-based applications on PCs
that support Flash. Access to computers' microphones and
speakers is supported as well as graphical presentations.
In the future, Ribbit plans to offer REST-based1 APIs to
network features extending beyond the SmartSwitch.
1 REST stands for REpresentational State Transfer. It has been adopted as the label for exposing services as manipulations of documents on the web.
4. The future of SDKs
It is generally very easy to achieve functional access to
resources to be manipulated over a network and the skills to
do it can be easily purchased. However, the ease of
development should not be over-estimated. Readers may
have encountered a plethora of exciting and innovative
demonstrators that illustrate the wide range of new services
and features that could, in theory, be provided to customers,
but it is only when work moves beyond the demonstrator
stage that many difficulties are encountered.
In our view, the key issue is that the benefits users can
derive from service bundles are finite, as is users' willingness
to pay for them. If the costs of assembling the service exceed
the willingness to pay, the service is not economically viable.
Such costs arise from (for example) the need to manage
multiple subscriptions, incompatible data schemas and
transforms. Maintenance and management costs must also
be factored in. (In economic theory, a situation in which
transaction costs overwhelm the value of a service value
thereby preventing the exploitation of a resource is known as
a 'tragedy of an anti-commons' .)
SDKs are a mechanism which can be used to represent and
define the value of a bundle of rights to service utilisation which
will be maintained over a defined period. In fact, we argue that
because of the nature of software and networks, it is both
natural and convenient to represent the rights of users in this
form. An SDK provides an exact contract between a user and a
provider as to what is available and when. However, the precise
nature and implications of this contract are often poorly
understood – both by users of SDKs and their developers. Some
will only discover the limitations of the Windows SDK contract
when the support lifecycle policy affects the operating system
version they use, for example .
| Windows SDK||Popfly||Google Search||Android||BT SDK2||Ribbit|
Windows licensees||Fun consumer
(web)||Web users, via a
web browser using
enable access and
drive use of
enable access to
services in web
|Processing, data access or connectivity provision|
third parties. No
charging at this
time||Access to search
data (contact lists,
provided by large
data access.||Access to
Flash API including
managed API||CREST-based API
Microsoft .NET and
Eclipse||Adobe Flex API|
|Exposure and access control|
|Layered access to
provided||Windows Live ID
to use tool; team
keys to enable
management||DOS prevention by
IP address access
Time out for
machine design to
based pay per use
exposure to be
REST-based API to
enable access to
Table 2. Comparison of selected SDKs using value chain model
2 The BT SDK was withdrawn in October 2008 after BT's investment in Ribbit.
In this paper, we have looked at SDKs from BT, Google and
Microsoft. Each of these companies is pursuing a strategy to
deliver ICT functionality to the markets that it perceives as
offering the best return on its investment.
Looking at the SDK Google has developed for its search
functionality, the company's strategy appears to be to
develop new revenue streams by encouraging the use of its
applications by third parties. The strategy it has adopted for
Android is different, however. Here, it developed a model
and SDK before delivering (with its partners) actual
implementations of the underlying platform. Both Google
offerings focus on enabling access to functionality, however.
Even where features like key management are emphasised
in the offering, this seems to be done because, without
these features, the practical usefulness of the platform
would be compromised. With Android, Google is attempting
to guarantee that a high-quality web access environment
will be available without up-front licensing fees to the large
number of web users reliant on mobile devices. This
guarantee is underwritten by the Google brand and the
enormous capital base and revenue stream that the
company has secured in recent years. Google seems to be
saying that, so long as people are prepared to use its
technology, it is confident that its model and position will
allow it to profit.
Microsoft is pursuing a similar strategy, but much more
conservatively. The Windows platform has been extended
into the mobile space and access to it enabled by an
encyclopaedic array of supporting material. Innovation in the
form of Popfly focuses on enabling a new constituency to
access the Microsoft platform and the wider world of web
BT's vision is that its billable network services will be
incorporated in third-party offerings. The Ribbit SDK
offering access to the SoftSwitch technology and a strong
browser-driven client appears to be an attractive approach
to fulfilling this vision.
In order to capitalise on this approach, innovation is
required to produce answers to the questions that have
motivated the developments by Google and Microsoft. In
particular, we need to find an answer to the question of
who the users of SDKs will really be. For example,
providing and enabling access to commodity network
equipment and hardware without establishing strong
direct relationships with revenue generating customers
may not be in BT's long term interest. Microsoft's work
with Popfly points to the view that it has taken about
whom to target in the future.
In BT's innovation program, we have invested heavily in
technologies that aim to enable consumers to establish the
behaviours they want their digital assets to exhibit. By allowing
them to express and share their requirements, we hope to
make BT a significant component of many next-generation
internet applications. But, whatever technology mix we
provide, it seems clear that a competent and well-thoughtthrough
SDK is essential. It will support our target user
audience directly and provide a well-understood contract with
that to which we make a long-term commitment. An SDK is as
fundamental to our ability to participate in the future digital
economy as it is to Google or Microsoft.
However, simply providing an SDK and understanding
and living up to the commitment this implies won't be
enough to guarantee our success.
We pointed to the tragedy of the anti-commons in
section 4.1. The anti-commons is an economic scenario in
which the mechanisms of resource allocation available are
unable to create a functional distribution of labour and
resource; no effective value chain can form or persist. For
example, after the end of communism in the Soviet Union,
many shopping centres were closed because their operation
proved administratively impossible. This was because the
division of assets under the emerging legal system meant
that there were too many people with a say so or a veto on
any initiative or operational decision, and some shops simply
could not operate effectively. This resulted in markets being
opened on the pavement outside locked and shuttered shops
. Given the vagaries of the Russian climate, this solution
suited no one.
In some ways, an SDK is representative of an emerging
anti-commons. In the best case SDKs can be enablers that
provide access to discoverable machine interpretable
interfaces. In the worst cases they are a signifier that
resources exist, but they are hard to use. Publishing an SDK
may mitigate this, but if the wrong technical choices have
been made it can prove to be a waste of time and resource.
To be truly successful, an SDK needs to either define a
de-facto standard, as the Goolge search API has done, or
provide an extension of an open standard. This is critical
because it reduces the transaction costs that are required to
adopt the functionality that is provided and enables the
value chain to form. Implementation of an open standard
ensures that consuming clients – the programs that utilise
the services offered via the SDK can be from multiple
sources, even implemented to do completely different jobs.
For example, a storage SDK that implements WebDAV 
can be used to implement a digital photo storage service, but
it can also form the basis of a document repository for a small
or medium-sized enterprise. In addition, with the open
standards approach the learning curve for adopting the SDK
is shallow for an adopting organisation, risk is spread and the
functionality offered is base-lined by a process that accounts
for the wider needs of the user community.
If SDKs are going to be useful to customers in this
context, they and the products they support must implement
open standards. Suppliers must compete based on the
quality of what is provided rather than by attempting to lock
customers artificially into an ecosystem.
From this perspective, it appears that it is in suppliers'
interests to involve themselves in open standards communities
to influence and choose the final position of their goods and
services in the emerging internet architecture and value chain.
If they do choose to take this approach, they need to adopt
open standards where they exist, publishing SDKs in a
conformant fashion. They should continue to monitor and
adopt standards as they evolve and, in cases where no
standards exist, help the community define new ones.
It will be beneficial to any organisation creating an SDK
if they recognise that they must adapt their architectural and
product definition and launch processes to do this reliably
and effectively. The cross-coupling and tension between
features and reuse must be fully understood.
The author of this paper would like to thank the reviewers
who provided much needed feedback and some extremely
insightful and incisive comments and suggestions. While the
content of this paper is strictly my responsibility, I would like
to thank my colleagues Cefn Hoile, Paul O'Brien, Paul
Muschamp, Tim Stevens, Paul Downey, Paul Warren, Jim
Hardwick and John Sheperdson for the many discussions,
disagreements and open mockery over beer and coffee that
got me to the point of being able to write them down.
- Auh S, Bell SJ, McLeod CS and Shih E, 'Co-production and customer
loyalty in financial services', Journal of Retailing, vol.83, no.3, 2007,
- von-Hipple E, 'Economics of product development by users: The
impact of 'sticky' local information', Management Science, vol.44,
no.5, May 1998, pp.629-644 Top
- Brooks F, 'The mythical man month', Addison-Wesley, 1975, ISBN 0-
201-83595-9 (1995 edition) Top
- Porter M, 'Competitive advantage: creating and sustaining superior
performance', Collier Macmillan, London, 1985 Top
- The Windows SDK, http://msdn.microsoft.com/en-us/windowsvista/
- Microsoft Popfly, http://www.popfly.com Top
- Google, http://www.google.com Top
- The Android SDK, http://code.google.com/android Top
- The Apple iPhone SDK, http://developer.apple.com/iphone
- The BT SDK, http://sdk.bt.com Top
- Ribbit, http://www.ribbit.com Top
- Manolescu D, Beckman B and Livshits B, 'Volta: developing distributed
applications by recompiling', IEEE Software, September/October 2008, pp.53–59 Top
- Pilgrim M, 'Dive into Greasemonkey', O'Reilly Media Inc., November
2005, ISBN 0596101651 (also at http://diveintogreasemonkey.org) Top
- The Open Handset Alliance, http://www.openhandsetalliance.com Top
- Heller M, 'The tragedy of the anticommons: property in the transition
from Marx to markets', Working paper 40 of the William Davidson
Institute, University of Michigan Business School, Feb 1997 Top
- Microsoft policy on support 2008-10-08, http://support.microsoft
.com/gp/lifepolicy (accessed October 10, 2008) Top
- WebDAV, http://www.webdav.org Top
Simon Thompson is chief researcher in BT's
intelligent systems centre, where his interests
centre on community-oriented computing.
He joined BT after gaining his PhD from the
University of Portsmouth in 1997 and has
worked in its research department ever since.
Before taking on his present role in 2008, he
had worked on a range of prominent projects
supported by the European Union and the
UK Department of Trade & Industry (now the
Department of Business, Enterprise and
Regulatory Reform). He was the founding
chair of the AAMAS Industry Track in 2003
and has published more than 50 referenced
papers in the areas of intelligent agents and service-oriented architectures.
He was a visiting research fellow at the University of Southampton from
2003 to 2006 and has been named as an inventor of 23 patent families.