2. I’ll be talking about:
1. How we (in HE & FE) view software-developers
2. Our growing appetite for outsourcing
3. Being in a position to really exploit SaaS
4. the value of the strategic developer
5. conclusion
3. 1. How we (in HE & FE) view
software-developers
4. "I have never yet come across
an engineer who can turn his
hands to business.”
Lord Sugar
6. the role of ‘developer’ is not valued
• very few developers make it into senior management in higher education and
research
• developers are not invited to contribute at a strategic level for fear of being
seen to be ‘technology driven’
• developers come and go, often on very junior and short-term contracts -
therefore not recognised and trusted
• we have a rich & continuous source of talent from our student cohorts
• this means that there is little investment in developers
• consequently, we don’t get the best value from our developers (through
no fault of their own!)
7. which leads us to:
2. Our growing appetite for
outsourcing
8. “We don’t do IT development -
it’s not our business - I’d
outsource my granny if I
could....”
9. This slide adapted from presentation by Paul Curran (http://www.slideshare.net/JISC/paul-curran)
10. IT as commodity
• what is sacrificed to achieve the convenience of treating IT as a commodity?
• the capacity to offer differentiated services to your paying customers
• the capacity to integrate systems unless it’s worth the while of the remote
provider
• remember, HE is a small market to some providers - they might not care
all that much about solving your niche problems
11. What effect does treating IT as
commodity (or outsourcing your
granny) have on your ability to
deliver an excellent student
experience?
12. This slide adapted from presentation by Paul Curran (http://www.slideshare.net/JISC/paul-curran)
14. the SaaS relationship
• Software as a Service - where the software is delivered to your users across
the network - very often accessed through a Web-browser
• new features added by the vendor and rolled out to all customers
• considerable economies are made possible, but:
• local customisation opportunities are limited, and you are one of many
customers (potentially many more than in a pre-SaaS world)
• to offer more local integration and customisation potential, vendors
increasingly offer machine-readable Application Programming Interfaces
(APIs)
• APIs change the picture....
16. the value of the local developer
• should understand local conditions better than an external supplier
• is more accessible - very important when adopting agile development
• through (web) APIs, can tailor remote services to idiosyncratic local needs
• can engage the technical people in an external supplier - not just the pre-
sales people!
• can engage with and exploit available open source developments
17. Procurement
• procurement of any given SaaS needs to take into account the APIs offered by
that SaaS service.
• this needs to be considered in the context of technical understanding of the
integration possibilities with other local or SaaS systems with which you have a
business relationship
• how do we engage in dialogue with vendors?
• what capacity do we need internally to deal with this?
18. "Do we have the capabilities required to
deliver value from IT?”
Diana Oblinger
24. the strategic developer
• is experienced, both technically and in the ‘business’ of Higher Education
• has good local (sometimes tacit) knowledge - such as the real business
processes of the institution
• has moved beyond ‘problem solving’ as the extent of their perspective
• can align technical planning and interventions to strategic goals - has an
institutional perspective
• gives a technical-development dimension to strategic planning
• offers leadership, beyond project-management and can identify new ICT-
based opportunities to innovate and deliver a better student/staff experience
27. business has addressed this
problem by creating the role of
the CTO (Chief Technology
Officer)
what is the equivalent in our
universities and colleges?
29. "...to thrive in the digital future, you need
people who understand all facets of it
integrated from the very beginning. Take a
lead from the Victorians and ignore Lord
Sugar: bring engineers into your
company at all levels, including the top.”
Eric Schmidt, CEO Google
31. how many software developers
does it take to change a
lightbulb?
none.... that’s a hardware
problem.
Notes de l'éditeur
this might be the view of an opinionated business man, but I think this is a common view in our sectors too.
Managing development projects which involve more than one person (this is all software development projects which you are likely to manage) is like herding cats. It’s not something that many people relish
“I might be better off replacing software developers with people who know how to manage SLAs with remote service providers.”
2 different directors in two different institutions in the UK
This is from Paul Curran’s talk yesterday - I have added the red circle to highlight his important dividing line between what is done locally and what is outsourced. It’s right to consider what might be better delivered by external specialists.
in other words….
I disagree with this and would put the line here. I’ll explain why
It’s about being in a position to really exploit SaaS
by the way:
The Cloud is not the same as Software as a Service (SaaS) - the cloud is primarily about infrastructure
SaaS is mainly about outsourcing the development and delivery of applications.
When I talk about outsourcing, I’m mainly talking about SaaS
not for machines. This is important. You probably have local services which can be enhanced by remote services with APIs, but do you have the developers who know how to exploit them?
can make cheaper services into better services
From her keynote here yesterday
First, let me outline how SaaS works in general:
green star is focus of knowledge about users’ behaviours, needs etc.
red star is focus of capacity to innovate technically
gap between them is pretty large
red line is technical dialogue - dotted means it’s a weak dialogue
same gap between knowledge and capacity
we risk mirroring the classic internal IT divisions but making this worse as the tech capacity is outside of our organisational control.
Loss of organisational understanding of technical issues
SaaS providers would often rather work through a partner with a track record of development with their product, than through each customer directly. After all, this is partly the appeal of the SaaS model to the provider. Here the focus of capacity to innovate technically in context is with the partner. Note that the nexus of development for the institution is still outside the institution.
The local developer is able to exploit the APIs offered by the different SaaS providers to build a tailored solution
the gap between understanding of users’ requirements and the capacity to deliver technical innovation is reduced, and importantly, the next innovation project will add to this understanding and capacity.
but, I believe that we need to get to the point where we can conceive of a strategic developer
is probably disguised as a manager :-)
does not really exist as a role, yet, but if it did....
1. we have a rich source of raw talent coming in (our students)
2. we can and often do employ some of these. They gain the domain and tacit knowledge. Then we start to lose people
3. those that stay normally have a choice of going back into academia or moving into management
4. by this point we have lost all of our experienced developers. It is rare to have someone with a developer’s experience at a strategic level in our institutions
1. technical (latest stuff) - new technical ideas (18 months to get up to speed on technologies)
2. technical (judgement) and an understanding of local context
3. organisational knowledge (tacit knowledge - how things work and how to get stuff done at my institution)
3. domain knowledge (how higher education works, how libraries work)
4. committee work, strategic planning, leadership (not on offer to our developers)
The CTO is a board-level position. Incumbents are frequently from a software application development background
I’ll conclude with a plea from Eric Schmidt, CEO Google