Navigating the Technology Trade-offs
When it comes to enterprise mobility, discussions around technology requirements are notoriously difficult. Here we shine a light on some of the trade-offs, constraints and pitfalls.
The renowned economist Thomas Sowell is quoted as saying: “There are no solutions, there are only trade-offs”. This is especially true when building mobile applications for the workplace.
Some of the most passionate and lively discussions we have with our customers revolve around technology decisions.
One reason these conversations are so tricky is because different stakeholders have different objectives, different points of view and different biases. As an external partner, we’re tasked with navigating this minefield while attempting to balance the often competing needs of usability, viability and feasibility.
Every discussion around technology requirements inevitably results in trade-offs. Each choice that gets made along the way creates constraints in other areas.
Every discussion around technology requirements inevitably results in trade-offs. Each choice that gets made along the way creates constraints in other areas. And since time, money and resources are limited commodities in every business, there are competing intentions and no easy answers.
A lot depends on what kind of solution you’re building, who will use it, how frequently they will use it, what they will use it for, and how long it's likely to last. It’s really a matter of finding the right horse for the right course.
To help shine a light on some of the trade-offs, constraints and pitfalls, we’ve pulled together a list of technology considerations (see below).
The bad news: there is no perfect answer. Prioritising one consideration will almost certainly mean sacrificing one or more of the others. Try gathering your key decision-makers, rank the considerations by importance, then decide which trade-offs you’re most comfortable with.
These considerations fall into two broad categories (Capability and Sustainability), with three considerations in each. All the considerations are designed to be examined holistically. For each one, we’ve explored implications for your choice of hardware, development toolset and architecture.
Will the solution be sufficiently capable in the short term?
Platform: It’s important to determine the most appropriate hardware device(s) and/or software platform(s) on which to build your solution. Many elements of the user experience will be affected by your technology choices. Often these decisions will be influenced by the cultural, market or business environment.
- Hardware: Given your budget, resources and priorities, which device(s) will you support and which can you choose to omit? Total cost of ownership is an important consideration.
- Toolset: How will your platform choice inform your development toolset? What are the best or most appropriate tools for your chosen platform(s)?
- Architecture: What constraints will your chosen platform(s) place on your architecture decisions?
Ecosystem: The scale and maturity of a technology ecosystem can impact the capability of your solution.
- Hardware: Some devices have a broader range of applications and accessories than others.
- Toolset: The larger and more mature the ecosystem, the easier it is to source developer tools, attract and onboard talent, and get peer support with common problems.
- Architecture: Does your architecture take full advantage of the hardware, tools and software libraries available in the ecosystem?
Security: For many organisations, the security profile of both deployed solutions and the tools used to build them are business-critical considerations.
- Hardware: By design, some devices are more secure or securable than others.
- Toolset: Some toolsets are secured by their providers, others are reliant on communities of individual contributors.
- Architecture: Designing an appropriate security profile with separation between components can help minimise risk.
Will the solution be sufficiently sustainable over the long-term?
Life expectancy: Consider the potential lifespan of the solution as well as the platform(s) it’s being designed for.
- Hardware: Devices come and go, as do hardware manufacturers. There are potential risks with adopting a device or platform too early or too late in its lifecycle.
- Toolset: Your toolset needs to live as long as the solution is operational. As software platforms gain new capabilities, some toolsets will support them more quickly than others.
- Architecture: Is your architecture robust enough to adapt as your chosen platform evolves?
Support: The ability to update and maintain a solution is often a key consideration. When technical issues occur, it’s important to be able to diagnose and resolve them quickly.
- Hardware: Some devices have more service and support options than others, making them easier to update, repair or replace.
- Toolset: A good development toolset is one where every element is dependable and maintainable over the long term. Some toolsets are supported by the platform vendor, others rely on smaller companies or individual contributors.
- Architecture: A simple architecture of well-defined components is typically easier to support. Some components may not be supported over the lifetime of a project.
Portability: Which devices, platforms and/or tools might your solution need to be compatible with in the future?
- Hardware: As the business and technology landscape evolves, it’s important to consider if/how your solution will support future devices.
- Toolset: Consider the trade-offs between using tools that offer short-term functionality vs long-term portability.
- Architecture: Is your architecture flexible enough to support emerging platforms? Building solutions using interoperable standards can help ensure compatibility with future technology.
When digital transformation starts with the user rather than the technology, magical things can happen.
When creating software, deciding which platform, environment or framework to use is a case of “horses for courses”. The trick is finding the right horse for the right course.