This document provides information about the role of a Development Director in an enterprise IT organization. It begins with an introduction to the role and then discusses what the Development Director is responsible for, including all in-house and packaged applications and systems used across the business. It describes typical backgrounds of Development Directors and discusses who they report to and manage. It also provides a day-in-the-life example and discusses interactions with other IT roles. The document concludes with a glossary to help understand terminology relevant to the Development Director role.
6. WHAT ELSE MIGHT I BE CALLED?
There’s a lack of consistency in naming for this job function.
But some titles crop up repeatedly:
Systems Director/Manager
Head of Application Development
Business Systems Manager/Director
Director of Software Development
Head of Application Infrastructure (not often)
Information Systems Director (although this often means CIO)
7. WHO AM I?WHAT DO I DO?
I’m responsible for:
• All applications/systems within the business
(not systems software)
• In-house/bespoke systems + packages
• Laptops/smartphones to the mainframe
• Interface to all the business streams/departments
8. WHO AM I?WHAT DO I DO?
I typically:
• Design and build applications/systems (but I don’t run them)
• Buy and take responsibility for packages
• Maintain applications/systems (I worry about availability)
• Manage the entire cycle from business requirements to live
running working directly with the business
• Understand what the business needs/what its strategy is
• Manage third parties (in the outsourced world)
9. TYPICAL BACKGROUND
• I probably started life as a developer, maybe as a business
analyst, but probably not a tester or software support guy
• The new breed may come from a consultancy background
• I might have a degree in programming, although I probably
haven’t written a line of code in years
• I may have a degree in maths or languages
10. TYPICAL BACKGROUND
• The best of us have a ‘strategic emphasis’
• We line up well with the business and
manage downstream the production of
what the business needs
• We like apps, and may take infrastructure
for granted (treat it as a utility)
• We may identify with the business more
than our colleagues in IT do (we’re
strategic, they are not ….)
If a system fails,
its probably the
infrastructure,
or…
11. WHO IS MY BOSS, AND WHO DO I MANAGE?
IT Strategy and
Architecture
Business
Transformation
Application
Development
Operations
Governance
and Risk
CIO
Dev Mgr
BusinessArea 1
Dev Mgr
BusinessArea 2
Dev Mgr
BusinessArea 3
Dev Mgr
BusinessArea 4
Dev Mgr
Desktop
SmartphoneApps
12. ABOUTTHE APPLICATION DEVELOPMENT CYCLE
A never ending process…
• Core systems can be over 20
years old
• Package cycle vs bespoke
cycles
• Need to get the analysis right
• Need to get the design right
• Testers get the flak
13. ABOUTTHE APPLICATION DEVELOPMENT CYCLE
Need to keep up with issues like:
• New product launches
• Regulation
• Performance
• User interface consistency
• Batch
• Costs
• Skills
14. WHAT MIGHT MY OBJECTIVES LOOK LIKE?
Go live on a new business
system by end second Quarter
– and secure whatever
business performance benefits
are expected
Achieve 99.9% app availability
Meet any other
specific business
measures that are
dependent upon
my apps
Customer satisfaction
rating (keep business
unit heads happy)
Reducemycostsby10%
Increase productivity
by 10% (do more per
developer)
Maintaingoodstaffretention
SoundmanagementofthirdpartySLAs
15. A DAY INTHE LIFE OFTHE DEVELOPMENT DIRECTOR
Catch up with CIO
Interview – Head of [example business
unit] Systems (largest people role)
Planning meeting – [example business unit A]
Planning meeting – [example business unit B]
Lunch – high performers (retention)
Vendor meeting – package X
New Dev plan to review with CTO (incl. new dev platforms)
Review with Ops (SLAs)
Demo – [exampleY] system prototype
Review meeting – [example Z] department
16. WHAT DO ITHINK ABOUT PEOPLE IWORKWITH?
CIO – “I could do
that job better”
Ops Dir – “bit of a
grease monkey/pseudo
techie”
CTO – “technically strong
but practically inept”
Strategy/Transformation
Dir – “on Planet Zogg’”
Compliance/Security –
“Ah, the Business
Prevention team”
17. AND WHAT DOTHEYTHINK ABOUT ME?
“Takes ages to build something
a grad could pull together in a
weekend…” (CTO)
“Doesn’t really
understand the
business”
(Business heads)
“Slopey shoulders… ‘It’s
never a problem with the
app’” (IT Ops Director)
“Why do they have so
many people? What do
they all do?” (Various)
18. WHO’STARGETING ME? (AND WHO SHOULD BE?)
Anyone who sells:
• Applications development platforms, or infrastructure
for the delivery of applications
• Often broad technology solutions for business
• All kinds of business applications
20. GLOSSARY: LEARNTO SPEAK ‘DEV DIR’
Package
A way of describing the various functionalities of an application.What’s in the package? –
basically a list of things it can do. Different releases can add to these functionalities (hopefully
the application has been well written to make this process easier).
Bespoke package
Bespoke application – we’ve looked at all the available packages – none do quite what we want,
so we’re going to build one ourselves, write it internally with our own developers (or contracted
ones)and build it directly to our precise specifications.
Licence
The agreed rules and restrictions for use of specific systems software or applications software.
e.g.You’ve got 100 user licenses in two countries for the fee you’re paying – and no more! It can
get very complex to control access across a large organisation with multiple offices (people
download or share passwords), so it can be easy to fall out of compliance.
21. GLOSSARY: LEARNTO SPEAK ‘DEV DIR’
Support and maintenance
This is often rolled into one term but think about it as two:
• Support: we provide support if users can’t do something they want to – typically through the Helpdesk.
• Maintenance: this is fixing the ‘bugs’ – faults with the application itself.
Software as a Service
A software delivery model in which software and associated data are usually centrally hosted
on the cloud (it doesn’t have to be in the cloud though, however you do it, it is effectively
renting the software).
It has become a common delivery model for many business applications and has the potential
to reduce IT support costs by outsourcing hardware and software maintenance and support to
the SaaS provider.
22. GLOSSARY: LEARNTO SPEAK ‘DEV DIR’
System software vs application software
System Software is any computer software which manages and controls computer hardware so
that the application software can perform a task.You need System Software to run an app.
Operating systems, such as MicrosoftWindows, Mac OS X or Linux, are prominent examples of
System Software.
Application software refers to programs that enable the end-user to perform specific, productive
tasks, such as word processing or image manipulation. Examples include MicrosoftWord, Excel, or
Adobe Photoshop.
Application development backlog
This is all about delivery timescales. E.g. I’m head of cards systems in a bank and you’ve given me
ten things you want. Five are in process but I’ve got a backlog of the other five. I’ll give you an
estimate of when you can get it developed by, and that backlog is measured in ‘man years’.This
can be as many as hundreds of ‘man years’ – which is why Apps development teams are so big!
23. GLOSSARY: LEARNTO SPEAK ‘DEV DIR’
Offshore development
Where much of the development work is done in more cost effective (lower paid!)
countries.These are teams of apps developers overseas who respond to a brief, and design
software around it.
Onshore/offshore model
Where application development (in this case) is managed by a locally based project
manager who coordinates with an offshore group of developers.
Outsource
Hand over the process of applications development, management and maintenance to a
third party.Then manage relations with that single third party.
24. GLOSSARY: LEARNTO SPEAK ‘DEV DIR’
Right source
Right sourcing evaluates all outsourcing options in order to bring together the best
combination of onsite, offshore and near-shore delivery capabilities to provide maximum cost
and time advantages.A balance is sought between those applications and processes that can
be executed using internal resources and those that call for outsourcing. Factors which affect
the sourcing strategy for the application include, but are not limited to, application criticality,
complexity, stability, technology base and availability of documentation.
Visual development tools/prototype
This is when you design a basic workable ‘dummy’ version. Put one case through – to show how
it works. A bit like a concept car – that doesn’t really drive round the whole track in all
conditions. Where you might have a button that will show 20 things when finished, right now
it’s only got a few critical things that work.This is to give the impression of what the full
working system will look like and get approval from the user.
25. GLOSSARY: LEARNTO SPEAK ‘DEV DIR’
The life of the Development Director
Spec
Defining the specifications for a new application – what does it need to achieve and under what
circumstances? Involves a lot of discussion between the developer delivery team and the end users
– basically understanding the business challenges and how to address them.These will be a key part
of acceptance testing later.The end result needs to be signed off to go forward. It’s the document
the business often doesn’t read but should.
Documentation
Information about developing applications and drivers for a certain operating system.These are
statements that identify attributes, capabilities, characteristics, or qualities of the app.This is the
foundation for what gets implemented. At a technical level this would include the code, algorithms
and interfaces the app will have.
Training – to be apps ready
Training for employees can vary significantly according to the role they fulfil and how they will use
the application. Need practical training to get benefits fast and minimise business disruption.
26. GLOSSARY: LEARNTO SPEAK ‘DEV DIR’
The life of the Development Director
Business representative
The person on the ‘business side of the fence’ in the organisation who signs off what the users
want.When we’ve done all the workshops etc. we can eventually get that signed doc that shows
everything we want.
User requirements
Need to workshop it through with the business representative.Then play this back in detail –
going through each data item by data item – they need to read this in detail.What the
employees or customers will use the applications for – what is the business need and the specific
problems it must solve?
Development tools
Software that the developers can use to create a new application. Good tools will help them get
the job done faster (meaning more organisational flexibility for IT and the business).They often
incorporate web and collaboration technologies, open platforms, and extensible frameworks.
Some will be visual, some won’t.
27. GLOSSARY: LEARNTO SPEAK ‘DEV DIR’
The life of the Development Director
Testing and automated/regression testing
To simulate what a user does, how the application behaves and to root out any bugs you
can build a test ‘harness’.You’d probably get some users in to physically test it too. What
about regression testing?
Let’s say you test elements one to ten and all is fine. But then you find a problem with
number eleven. So you fix it. But by rewriting the code to fix it you might have altered
something in those original one to ten elements. So you then have to go back (regress)
and check one to ten still work.That’s regression testing, and it can get pretty complicated
when you do it on a larger scale.
You’re not going to go live with a system until you know it works at high volume.This is
stress testing.You create a harness that simulates 10,000 users. It models when systems
start to grind to a halt. Important to know what scale it starts to fail at.
28. GLOSSARY: LEARNTO SPEAK ‘DEV DIR’
The life of the Development Director
UAT (User Acceptance Testing)
AcceptanceTesting is conducted to determine if the requirements of the application have
been met. You hand over to the business side of the fence and say ‘use it to do what you
need and flag any problems’. When it’s signed off you are saying that it’s safe to go live. If it
goes live, and any bugs appear, it’s your fault not ours!
Legacy/heritage systems
Old (but not necessarily obsolete!) computer systems that may still be in use because their
data cannot be changed to newer or standard formats, or their application programs
cannot be upgraded. Sometimes it can be difficult to know if anyone still knows how to fix
it in the organisation!
29. GLOSSARY: LEARNTO SPEAK ‘DEV DIR’
The life of the Development Director
Batch progamming
Overnight – batch programs run the overnight processes – like.
RTFM
ReadThe F***ing Manual.The response you usually get from the helpdesk when users call
up to say the application is not working!
Source vs object
The programmer writes code in a textual form or using a visual programming tool (source
code), and this code is translated (by a program called a compiler) into another form (object
code) which can be executed directly by a computer.The code is then distributed in object
code form. Basically, object code is only useful to the user – you can’t work with it to
change the application.
31. ABOUTTHE MARKETING PRACTICE
• With over 90 people and 10 years’ growth we
are 100% B2B focused and one of the UK’s top
10 B2B agencies
• We integrate all the skills you need under one
roof to plan and manage end-to-end
programmes across EMEA (data, inside sales,
creative, content, digital …)
• And we focus on working with a few select
clients to deliver results and prove ROI
We live and breathe enterprise demand generation