How bxp is developed

1 Overview

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

We use a structured approach since we started which is continuously refined.

The current organisational development approach is detailed.

2 Phases

2.1 Phase 1: Sources

Most of the updates to 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 receive 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 departments contribute new ideas All_n_One_Departments

New modules historically have been born from simple 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, whereas 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 to 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 (our policy states that no developer can test their own code). Using a combination of the original request, feedback from the developer, and the appropriate testing solution, an iterative process is applied to "test > document > fix", which is applied.

2.4 Phase 4: Go Live

When tested, the code is then put into the live environment 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 depends on the work. Where potential operational errors could occur, the code is put live out of hours.

2.4.1 Documentation and Client support

If the functionality is implemented correctly, a supporting Wixi is created and released to clients on our public domain.

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