Body
Background
Solution Delivery has recognized that maintaining the applications, integrations, etc., that we produce is an expensive and time-consuming activity. We have newer tools that designed to relieve the long-term maintenance burden from the solutions that we create. Change is often difficult, but we don’t want that difficulty to prevent us from making choices with which future-us will be happy.
Environment
- 1191721: Workday
- 10374: TeamDynamix (TDX)
- 1054647: iPaaS
- Laravel
Preferred Development Tools
We use the following order of preference when selecting tools to build solutions. (This order is visualized as an inverted pyramid in order of preference.)
- Use Existing Workday Features
- Use Workday Extend
- Use iPaaS/TDX & COTS (including OSS)
- Build a new application using Laravel/PHP, etc.
When a new request comes in and is determined to be unrelated to existing solutions (i.e. we decide we need to make something new), the team should traverse down this list from top to bottom, by order of preference. In other words, we should first conclude that a new solution cannot use existing Workday features before deciding whether we could use Workday Extend. If we can’t do that, we should consider whether iPaaS, TDX Work Management (the ticketing platform we are all used to), or a Commercial Off-The-Shelf (COTS) solution (including Open-Source Software (OSS) options) are able to address the use case. If there are no other options, we resort to creating a new PHP app.
Creating a new PHP/Laravel app is like getting a new puppy. It might be the perfect solution for your family team, but it’s not a decision to be undertaken lightly. The team that creates a new PHP/Laravel app also must keep up with the language and framework updates, move it between servers, etc. The team, VE, and Architecture should all be part of this decision.
Reasoning and Nuance
While we are obviously pushing the use of solutions on low-maintenance platforms (Workday and iPaaS), we understand that there are plenty of gray areas involved. Ultimately, the team should discuss and decide on a solution architecture, and document the decision and reasons it was selected.
Non-exhaustive list of things to consider:
- How long will the solution be used (if it’s just a year or two, the fastest thing to put in production may be the best!)
- What kind of data is involved (HR/Finance? Workday sounds nice! TDX tickets? Probably iPaaS!)
- What volume of data are we talking about?
Not great reasons:
- Lack of familiarity with a specific tool/technology; you gotta learn sometime!
- Client wants it really fast (we can do it right, or we can do it again)
When the team has considered the target architecture, the BA assigned to your team will take that info to the #valueengineering Slack channel for discussion and approval (ultimately by the Director of Application Architecture and Operations (Dirk) or his designee, as Director of Application Architecture). This whole process (discussion to VE approval) should take no more than a half day; we are not trying to slow things down, we’re trying to future-proof!