the development lifecycle

Submitted by admin on Wed, 07/13/2011 - 08:11
  1. introduction
  2. what it is

introduction

A development lifecycle is a series of events that turn a customer's idea for a new Internet service into reality.

The development lifecycle is usually broken down into processes like these.

Each development lifecycle causes the configuration of an LIC to change. New services are added, existing ones are kept working and old ones are deleted. Support teams have to keep track of changes, plan for the future and make fast repairs when things go wrong.

what it is

Let's say a big customer demands a new Internet service from a big business enterprise. Perhaps he wants a web site for e-commerce. Every man and his dog get involved before the new service can be created for the customer. The extra red tape pushes up the price.

  1. A customer asks for a new service and waits for the response.
  2. A business analyst probes the customer's requirements and scribbles them down.
  3. An Internet service architect takes the requirements list and maps out a technical design of how the service will work. A company brochure may need a web server. A fantasy football site may need a web server and application server.
  4. The support team then read the architecture description and estimate what capacity is required to run the service. An online repository of every book ever will need a lot of disk space. A daily news channel needs a lot of network bandwidth.
  5. The support team ask the data center manager if he has room for a load of new computers.
  6. The support team ask the network team if the network can handle the extra traffic.
  7. The support team complain about unreal expectations and hand back a more detailed design.
  8. This design is vetted by security experts. If they believe the service will be as watertight as a fish's arse at fifty fathoms, they approve the design.
  9. An SLA (Service Level Agreement) is created so the supplier and the customer are clear about what the service provides and what it doesn't provide. The availability must be agreed. If the web site is expected to be available 24 hours a day, but no-one pays the overtime bill for getting support staff out of bed when it breaks in the middle of the night, don't expect a happy compromise.

The customer complains about daylight robbery and the price is negotiated back down. After the new service is sold to the customer, the process continues.

  1. The service is built by a development team.
  2. Computers are installed and configured along enterprise guidelines.
  3. The service is installed and goes live.
  4. A phone number, e-mail address and other contact details are given to the customer. These contact details belong to the service desk. A customer needs a service desk like a toddler needs a security blanket.

After the service is up and running the process loops ad infinitum.

  1. The service level is regularly measured. Management information is created from the measurement data, such as "the service performed perfectly in December but got flattened by demand during the January sales" and "the new product was launched last week and so far it has only been viewed by the producer's mum and one guy who was actually looking for something else". The service availability, capacity and usage are all monitored.
  2. Service level reports are written and sent to the customer.
  3. The service desk eagerly waits for calls from the customer. Customers phone up to complain, not to praise, so most messages are passed onto someone who can manage problems.

Nothing stays the same for long. The price of support weighs heavy on the customer.

  • Maintenance work needs support. Any changes to the computers that the services run on must be thought about and checked by everyone who may have an interest. A change to a firewall that allows Internet hackers to graffiti web sites is not going to please the security team.
  • Upgrade work needs support. The customer probably wants to upgrade his service to offer the latest greatest features. All releases of new applications and content must be managed. If several people release things without talking to each other then sooner or later they will overwrite, delete and generally undo each other's work.
  • New service launches need support. If one launches a new service which breaks all the existing services, the others give him a severe bottom spanking.