Enterprise Applications Team

The Enterprise Applications Team implements and supports specialized applications that support our business processes within GitLab.

Who We Are

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:

Our Vision

  • To enable end to end business processes within the enterprise applications that seamlessly hand off to each other and ensure it provides a great user experience to our business partners
  • Ensure data integrity between systems and security of that data
  • Constantly iterate to simplify and ensure processes are efficient and automated as much as possible..
  • Leveraging out of the box best practices as much as possible. We buying and extend applications where we don’t see building them as GitLabs core engineering competency
  • IT Audit and Compliance - Ensuring that all customer / business data is secure and can pass key audits for attestations and compliance with SOX, SOC, etc.

Services We Offer

Business Process Improvements

  • Being business process first, means that the Enterprise Applications team will firm up requirements, use cases, and process flows as we implement systems, enhance them or deliver fixes. Learn more here.

Application Evaluations & Implementations

  • We provide templates for vendor evaluations, can help write and review your user stories, and are happy to participate in tool evaluations that integrate with other applications or intersect with multiple departments. Once an application is selected, our team will align with vendor teams to implement Enterprise Applications that are coming on board. We follow a process that ensures we keep multiple groups aligned as we iterate to get the systems up quickly and efficiently. Learn more here.

Finance Systems Administration

  • Enterprise Applications supports all of the core finance systems with experienced admins that streamline and enhance current processes, turn on new features, and improve end to end process cycle time.

Integrations Engineering

  • Our integration team manages all of the integrations between Enterprise Applications at GitLab. Focusing on building out failover, redundant and auditable integrations that are constantly monitored. Learn more here.

Applications We Own

  1. Zuora
  2. Zuora Revenue (RevPro)
  3. NetSuite
  4. Coupa
  5. Tipalti
  6. Stripe
  7. Navan
  8. Navan Expense
  9. Avalara
  10. CaptivateIQ
  11. Workiva
  12. FloQast
  13. Adaptive Planning
  14. Xactly
  15. Mavenlink
  16. DocuSign

Services We Support: Finance Systems Service Desk

New SKU Request

Open a New SKU issue using the CM: Add_New_SKU template or CM: Add_New_PS_SKU for a Professional Services SKU.

Retire SKU Request

Open a Retire SKU issue using the CM: Retire_SKU template.

EntApps System Configuration Change

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.

Department Change Request

Open a Department Change issue using the CM: Department Request template.

EntApps System Incident Log

Open an Incident issue using the IM: FinSys Incident template.

Coupa Sandbox Refresh

Open a Coupa Sandbox Refresh request issue using the Sandbox - Coupa Refresh Template template.

NetSuite Sandbox Refresh

Open a NetSuite Sandbox Refresh request issue using the Sandbox - NetSuite Refresh Template template.

Zuora Central Sandbox Refresh

Open a Zuora Central Sandbox Refresh request issue using the Sandbox - Zuora Central Refresh Template template.

Our Intake Process

graph TD
    A[Intake/Request received via issue] -->|EntApps Intake label automatically added| B(EntApps Leadership reviews the EntApps Open Intake board every week)
    B --> C{Is the issue ready to be worked on?}
    C -->|No| D[Issue added to the EntApps backlog board]
    D --> F[EntApps Leadership reviews the backlog board every 2 weeks] --> G{Backlog issue ready to be worked on?}
    G -->|Yes| H[EntApps Intake label is added]
    H --> B
    G -->|No| I{Issue creation date > 30 days?}
    I -->|Yes| J[Close the issue]
    I -->|No| F
    C -->|Yes| E[EntApps Leadership to add it to a milestone]
    E -->K[EntApps Leadership reviews the milestone with BSA, FinSys and Integrations teams]
    K -->L[EntApps Leadership and teams assign every issue to the correct team, team member and priority]
    L -->M[EntApps Leadership and teams add the appropriated weight and break it down as needed]
    M -->N[Milestone is defined and issues are assigned and ready to be worked on]

Intake Request

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. {: .alert .alert-danger}

To request work to be added to the Enterprise Applications Roadmap, please open an intake issue using the “Request” template.

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 issue is ready to be worked on and so it will be added to a milestone.
    • Enterprise Applications Leadership is responsible for removing the label EntApps Intake, adding the correct team label (~“BSA”, ~“BT Finance Systems or ~“BT Integrations::Backlog”) and appropriated milestone following the Milestone Planning process.
    • Additional information might be requested in the issue.
    • Once requirements are defined by the ~“BSA” team, associated system changes will be sent to the ~“BT Finance Systems team in the form of a Change Management Issue for configuration.
  • The issue is not ready to be picked up and will be added to the EntApps Backlog board.
    • Enterprise Applications Leadership is responsible for adding the ~“BT::Backlog” label and removing ~“EntApps Intake” as well as adding a justification in the issue as a comment.

Backlog

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:

  • The BT Backlog list is dedicated to issues that are not yet ready to start.
    • When a backlog issue is ready to be worked on, Enterprise Applications Leadership will remove the ~“BT::Backlog” label and add the ~“EntApps Intake” so it will be included in the weekly review of the EntApps Intake board.
  • The Closed list works as a history of all the issues that did not progress and so were closed.
    • It is the responsibility of the requestor to be clear on what the scope of their issue is. Issues that are in the backlog for 30 days without engagement from the requestor will be closed. If the issue needs to be picked back up, the requestor must re-open it and manually add the ~“EntApps Intake” label.
    • If the issue is in the backlog because it is blocked, the ~“BT::Blocked” label must be added to keep the issue open for longer than 30 days.

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. {: .alert .alert-warning}

EntApps Milestone Planning

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:

Considerations

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:

  1. Assign every issue to the correct team and team member.
  2. Add an issue weight. The goal is to go over the problem statement raised in the issue with the team that will be working on it and put it into one of 5 buckets: XS, S, M, L, XL as a way to group the unit of work.
    • The issue can be broken down into smaller issues (less weights) as needed.
  3. Add the appropriated priority label to every issue in the milestone.

EntApps Milestone Timing

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. {: .alert .alert-warning}

image-1

EntApps Milestone Schedule (Q3 and Q4 FY23)

Issue Weights

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.

Example:
- 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.

Example:
- 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.

Example:
- 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.

Example:
- 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.

Example:
- A new system or module implementation.
- E-Disty Epic, which involves multiple changes, and has been broken down into smaller issues.
**Consideration** {: .panel-heading}

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.

Project Weights

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.

image-1

Business Systems Analysts Activities

Stage Tasks
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.

Finance System Admins Activities

Stage Tasks
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.

Issue Labels

Prioritization Labels

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

Status Labels

Label Description
~“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.
~“BT::Done” Issue resolved.

Other Labels

Label Description
~“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

Contact Us

Slack Channels

  • #enterprise-apps
  • #business-technology
  • #bt-finance-operations
  • #financesystems_help
  • #bt-integrations

{::options parse_block_html=“false” /}


Enterprise Application Guides
“GitLab’s Enterprise Application Guides for Finance Systems”
Enterprise Applications Integrations
Who are we? Dennis Griffin - Senior Integrations Engineer GitLab handle: @dgriffin4 Karuna Singh - Integrations Engineer GitLab handle: @Karuna16 Jeff Dunnett - Senior Integrations Engineer GitLab handle: @jdunnett Santhosh Baranidharan - Senior Business Analyst GitLab handle: @sbaranidharan Durgesh Thakkar - Senior Manager, Architecture and Integration Engineering GitLab handle: @dthakkargit Contacting us Slack: #automation-team What do we do? We are the team that designs, builds and maintains the complex ecosystem of integrations and automations that exist in our Enterprise Applications ecosystem.
Finance Systems
Finance Systems Operations
Finance Systems Access Requests
Finance Systems Access Requests
How We Work
Finance Systems: How We Work
Quote to Cash Documentation
Enterprise Applications Quote to Cash Documentation
Tools
Last modified March 26, 2024: Update links to remove redirects (5b495046)