Revision as of 18:29, 20 April 2015

1 Overview

One of the questions we are often asked through security questionnaires and how our teams work here is "How is bxp developed?"

There is a structured approach we have used since we started with is continuously refined.

The current organisational development approach is detailed.

2 Phases

2.1 Phase 1: Sources

Most of the changes in our solution are inspired by our clients. We learn a lot by simply using the tools ourselves in house. Pitching for new business is a great source of inspiration for doing things in new and improved ways. Our Contact department often get new functionality requests or requests to enhance the platform.

Hamsters and maintenance are other great sources of inspiration which we draw from. Our Security department is never short of new and enhanced ways of refining the processes, procedures and underlying functionality. In fact all of our departments contribute new ideas All_n_One_Departments

New modules historically have been born of just ideas. Finding new and innovative ways of dealing with operational headaches or building on other people's views of how things should work.

2.2 Phase 2: Tickets

Every item of work to be done is created initially as a Ticket in the All n One bxp system. Each ticket is then scoped and refined into separate Jobs.

Every work item, billed or not, becomes a ticket. A ticket can be a massive project with hundreds of jobs or a single ticket with a single job. Jobs are itemised pieces of work that can be solved within 4 to 40 hours. For greater detail on how work can be managed through bxp and a worked example of the tickets Scenario_-_bxp_and_managing_work

Each of these work items are then prioritised and allocated to appropriate internal team resources to execute. The "Technical Operations Manager" manages all the projects and ensures their timely delivery.

2.3 Phase 3: Builds

So depending on the work type of the job, the developers can begin to implement solutions. Some tickets require quotations and reference back to a client other pieces of work can be done for internal departments.

Scoping and definition change greatly depending on the work type.

To give an example build for clarification purposes. "Create a new function clean phone numbers." The design of the function has already been scoped by the initial request. If further clarification is required more communication happens.

Each of the tickets will affect one or more of the All n One Infrastructures. All n One Infrastructures

The build itself is performed in the testing environments of All n One. Using a combination of centralised testing facilities and locally hosted instances, developers build the code to deliver the ticket.

The job is then passed to another developer to test (you're not allowed to test your own code). Using the combination of the original requested, feedback from the developer and the appropriate testing solution an iterative process is applied to "test > document > fix" is applied.

2.4 Phase 4: Go Live

When tested the code is then put into the live through a number of auditable mechanisms integrated into bxp.

As all functionality on the bxp platform is common to all client systems, considerable thought is given to the go live approach for solutions. The order of Go Live changes depending on the work. Where potentially operational stopping mistakes could happen the code is made live out of hours.

2.4.1 Documentation and Client support

If the functionality does what is required, then a supporting Wixi is created and release.

Information about the development, if significant enough is included in our monthly newsletters and social media as well.