The Enterprise Applications Team implements and supports specialized applications that support our business processes within GitLab.
We are directly responsible for all of GitLab's finance systems and Enterprise Applications Integrations. We build and extend these applications to support the processes of our business partners and rationalize our application landscape to ensure it is optimized for efficiency and spend.
Our team ensures the availability of these applications and integrations through monitoring and alerting. These internal-facing applications include a multitude of different applications and environments, including Zuora, Adaptive Planning, NetSuite, Navan Expense, etc. We are also responsible for the IT Audit and Compliance function to ensure we pass SOX Audit for our IT General Controls (ITGC).
Our Enterprise Applications team is made up of a combination of roles to best support the services we offer. Learn more about each by clicking on the tiles:
Open a New SKU issue using the
CM: Add_New_SKU template or
CM: Add_New_PS_SKU for a Professional Services SKU.
Open a Retire SKU issue using the
CM: Retire_SKU template.
If the system change is a quick change which does not require additional cross-functional alignment, scoping, or testing, and is not an output of a larger project, submit a Change Request.
Open a Configuration Change issue using the
CM: Configuration Change [Generic] template.
Open a Department Change issue using the
CM: Department Request template.
Open an Incident issue using the
IM: FinSys Incident template.
Open a Coupa Sandbox Refresh request issue using the
Sandbox - Coupa Refresh Template template.
Open a NetSuite Sandbox Refresh request issue using the
Sandbox - NetSuite Refresh Template template.
Open a Zuora Central Sandbox Refresh request issue using the
Sandbox - Zuora Central Refresh Template template.
Before opening a new intake request with Enterprise Applications, please check the Services We Support section that lists the templates to be used for specific requests.
Every week, the Enterprise Applications Leadership reviews the EntApps Intake board and there are only 2 possible outputs for the issues on the Open list:
The EntApps Backlog board is used by the EntApps team to review and act on Backlog requests. The Enterprise Applications Leadership reviews the board every 2 weeks, before a new milestone starts.
The EntApps Backlog board has 2 lists:
BT Backloglist is dedicated to issues that are not yet ready to start.
Closedlist works as a history of all the issues that did not progress and so were closed.
Both EntApps Intake and EntApps Backlog boards are at gitlab.com level so that issues created in other team's projects can appear on the board. The ~"EntApps Intake" label is not limited to the Intake project, it can be used in different issues across all gitlab.com.
EntApps milestones run for 2 weeks from Wednesday-Tuesday to avoid pushing changes over the weekend. This is also in line with the Business Technology blocked periods and the GitLab calendar.
Every Tuesday, Enterprise Applications Leadership is responsible for:
Once the Enterprise Applications Leadership creates the first version of an upcoming milestone, before the milestone begins, input from BSA, FinSys and Integrations team members is required (sync or async) in order to:
EntApps milestones run for 2 weeks meaning that a request that comes when a milestone is already ongoing, will be placed in the queue and follow the Intake process. If your request is urgent, please open an intake issue and tag @jesssalcido and @broncato in a comment. Enterprise Applications Leadership will work with the requestor to prioritize it and place it in the appropriated milestone.
Issue weight is an estimate of how much time is required to complete the request from an issue, using the Fibonacci Sequence.
|Size||Dedicated Person Time||Weight (issue points)||Description / Examples|
|XS||4 hours / Half Day||1||A task. The simplest possible change. We are confident there will be no side effects, and interaction with stakeholders is minimal.
- Update existing handbook page/documentation.
- Deprecation of an unused Hosted Payment Page in Zuora.
|S||1 Day||2-3||The problem statement has been determined and a solution identified. No need for (extra) discussion with other teams.
- Modification of Reason Codes in Zuora.
- Update CSS for Zuora Hosted Payment Page (affects self-service, requires testing and interfacing with engineering department).
|M||1 Week||5||The problem statement has been defined with understood requirements. Extra investigation is required but the expectation is that once a solution is identified, it should be relatively easy to implement.
- Most system bugs or performance issues.
- Stripe Account for Boundless / BigCommerce
|L||2-3 Weeks||8||The problem statement has been defined but a solution will require extra investigation in order to be identified and implemented. Surprises are expected, different teams will have to be involved. Significant investigation will be required and once the problem is found, a solution may not be straightforward.
- Bugs or system workflows that negatively impact the work of other people.
- Stripe V2 Implementation
|XL||> 4 weeks||13||The problem statement has been defined but it's a significant change that has dependencies and the requirements are probably not fully understood or known. It's unlikely we would resolve this in just one issue and the preference would be to further clarify requirements and/or break into smaller issues.
- A new system or module implementation.
- E-Disty Epic, which involves multiple changes, and has been broken down into smaller issues.
For issues that are added to a milestone with 8+ points/weights, the expectation is that by the end of the 2 weeks milestone, the problem statement has been defined but a solution might require extra investigation in order to be identified and implemented. Surprises are expected, different teams might have to be involved and so the issue will be carried over to the following milestone.
Following an activity-based estimate, beginning with the requirements of the project and the size of the application and then, based on this information, defining the required tasks, which will serve to identify the overall effort that will be required.
|0 - Intake||Confirm the project scope, initiate project activities and establish project management processes and controls.|
|1 - Define||Ensure project goals, plan, timeline, milestones, deliverables, resources and responsibilities are drafted and reviewed. Book and lead meetings as need to ensure project work streams are initiated to align on approach, resources and schedules.|
|2 - Design||Book workshops/discovery sessions, lead meetings with internal and external participants and provide a summary of the key decisions, actions, and meeting notes.|
|3 - Build||Assist the technical teams as needed, document all functional and integration configuration according to decisions made during the Define & Design sessions.|
|4 - Test||Help unblock and keep project on schedule. Assist the project team by ensuring the configuration sufficiently meets the needs of the business based on the criteria identified during Define & Design.|
|5 - Deploy||Assist the project team with tasks that will facilitate/allow the move into the production environment (go-live checklist, sponsors sign-off, documentation is in place).|
|6 - Live + Hypercare||Monitor and provide support for the deployed application following the project go-live.|
|0 - Intake||Assist the project team validating the project scope.|
|1 - Define||Join meetings as needed to review the overall project, including a draft of the plan and timelines and discuss all in scope functionality. Provide the necessary information through documentation/workbooks.|
|2 - Design||Review modifiable business processes, identify potential adjustments, and review data and configuration.|
|3 - Build||Build the functional and integration configurations in preparation for the Test stage.|
|4 - Test||Execute the in-scope scenarios, documenting any issues to be researched.|
|5 - Deploy||Prepare the pre-production environment with signed off configuration and integrations.|
|6 - Live + Hypercare||Assist end users with any functional or process issues, and work with the project team and SMEs to ensure the new interfaces are operating properly.|
|Priority||Label||For Incidents||For Projects|
|High||~"BT-Priority::1"||- The damage caused by the Incident increases rapidly.
- Several users are affected.
-A minor Incident that can be prevented from becoming a major Incident by acting immediately.
|- The project is business critical and has a due date linked to a legal/security/compliance due date.|
|Medium||~"BT-Priority::2"||- The damage caused by the Incident increases considerably over time.
- A single user is affected.
|- The project is linked to an OKR in the current or upcoming quarter|
|Low||~"BT-Priority::3"||- The damage caused by the Incident only marginally increases over time.
- Work that cannot be completed by team member is not time sensitive.
|- The project can be completed in our spare time and can be paused for higher priority work|
|~"BT::Backlog"||Unless a due date is indicated or urgency specified, non-access related issues will go into the backlog and prioritized bi-weekly.|
|~"BT::To Do"||EntApps team will look at the issue when assigned to a milestone.|
|~"BT::In Progress"||EntApps team is actively working on the issue.|
|~"BSA"||Business Systems Analysts issue|
|~"BT Finance Systems"||Finance Systems Administrators issue|
|~"FinSys::Service Desk"||Finance Systems Service Desk issues, 72 hour SLA|
|~"BT Integrations::Kanban"||Business Technology Integrations issue|