Abstract: This article introduces the reasons why organizations choose to standardize a technology stack or DevOps to use on existing and future projects in order to maximize ROI of their technology choices. When selecting technology for new projects, the architect should consider both technologies within and outside of the existing technology stack, but the big picture needs to be carefully understood and consideration needs to be placed on the ROI of introducing new technology versus using existing technology within the technology stack. Ultimately, don’t fear new technology or new DevOps, embrace it, but do the work to understand, drive, and move the organization forward using new tech and operations.
As a Software Architect, understanding the long term affects and ROI of technology selection is critical. When thinking about technology selection for a new and upcoming project, you need to consider the project requirements, but also look beyond them at the bigger picture. Even though at first glance, a specific technology might seem perfect for a new project, there may already be a more familiar technology that will actually have a much bigger return on investment in the long term.
It is important to embrace new technology when you can demonstrate a big ROI to the business. Being stuck in older technology can be extremely prohibitive especially if you continue to be stuck in that technology year after year.
Many organizations stick to specific technology stacks to avoid the cost, overhead, and complexity of dealing with too many platforms. An architect should have specialized technical knowledge of the technology stack used by the organization, and if the organization’s technology stack isn’t standardized, the architect should work to standardize it.
Advantages to an organization by standardizing their technology stack
Development costs – It’s easier to find people who are specialized on a specific platform instead of having multiple platform specializations with conflicting technologies. When you need developers with conflicting skillsets (ex: .NET and Java), you will likely need to pay for additional employees to fill the specialization gap.
Smoothness & Predictability – There needs to be a level of predictability to ensure operations continue to go smoothly, and to help with project costs and estimates. Predictability comes in the form of having teams and the organization know how to approach technical problems. Are your enterprise services restful with JSON as an example, or are they scattered and using different technology depending on the faction of the organization involved? If they are, as an architect, make sure to standardize this. Keep it the same, move to restful services, micro services in the cloud, or whatever makes sense to your organization. However, keep in mind that standardization is a key to predictability with whichever road you choose as an organization.
Licensing costs – It’s typically advantageous to stick with only a few technology vendors to attain better group discounts and lower licensing costs.
Physical tier costs – It’s cheaper and more manageable to manage physical tiers that use the same platforms or technologies. Using multiple platforms (ex: Apache and Windows based web servers require double the skillset to maintain both server types and to develop applications that work in both environments)
Understand the bigger picture beyond to better understand ROI
As an architect you have responsibility with technology selection as it retains to ROI. Once you are familiar with the organization’s technology stack and the related constraints, you can make a better decisions related to technology selection. You may want to put a higher weight on technology choices known collectively by the teams, but it comes down to understanding the bigger picture beyond any current project and understanding the ROI of both the ongoing projects and ongoing costs of the technology choices used.
You should always be willing to navigate away from your existing technology stack to get a bigger ROI, but be careful that the cost of supporting multiple platforms and technologies doesn’t exceed the cost savings of using a specific specialized technology for a specific case in the long term.
Don’t get stuck in old technology either. Don’t be afraid to upgrade services, as an example, to use a new micro-architecture, but make sure you understand the ROI. Don’t be afraid of PoC’s either. Use PoC’s to demonstrate that your proposed architecture is going to be awesome and provide tremendous business value. Start small, then once you’ve proven it, move to standardize, and make sure no one is still doing things the old way.
Recognizing older and inefficient technology, or ineffective dev operations is also part of the responsibility. As an architect, you should be able to identify these cases, and use this to make a case for bringing technology or Dev Ops into the organization. If people are routinely doing things at an incredibly slow pace, find out why, fix it, and work to standardize the solution. They may be sticking to architectures that are slow and outdated. There may be slow Dev Op operations, or even something as simple as using slow or outdated source control systems which could greatly be improved to provide ten times the value through modernization.
When Microsoft released .NET and related languages (VB.NET and C#) in 2001, many organizations made the choice to adopt VB.NET or C# and fade out classic VB development. Those that made the switch early had an initial learning curve cost. Organization’s that chose to keep their development technology choice as classic VB eliminated additional costs at the onset, however they paid a bigger price later when employees left the company, finding classic VB developers became more difficult, and the technology became so out of date that maintenance costs and technical debt began to increase dramatically.
Sometimes the choice and ROI will be obvious; the technology in question might not be in use by your organization, but it lends itself well to your existing technology. For example, introducing SQL Server Reporting Services is a logical next step if you are already using SQL Server, or introducing WPF and WCF will compliment an organization that is already familiar with development on the Microsoft .NET platform.
In another case, it may make sense to add completely new technology to your technology stack. For example, it may be advantageous from a cost perspective to roll out Apple iPhones and iPads to your users in the field, even though your primary development technology has been Microsoft based. Users are already familiar with the devices, and there are many existing productivity apps they will benefit from. Developing mobile applications will require an investment to learn Apple iOS development or HTML5 development, but the total ROI will be higher than if the organization decided to roll out Microsoft Windows 10 based devices just because their development team is more familiar with Windows platform development.
Finally, there will be cases where even though the new technology solves a business problem more elegantly than your existing technology stack could, it doesn’t make sense to do a complete platform change in order to get there. In these cases, the ongoing licensing costs, costs of hiring specialized people, and complexities introduced down the line far outweigh any benefits gained by using the new technology.
Summary
It’s important that the software architect facilitates the technology selection process by evaluating technology based on ROI of the project while also considering the long term ROI and associated costs of the selected technology. By doing this, it also provides an easier more confident sell to steak holders. It’s important not to focus only on your existing technology stack however, and consideration should be given to unknown or emerging technologies within the technology selection process. Careful consideration should be given to the cost of change and ongoing maintenance of any new technology and the ROI needs to be evaluated against the ROI of sticking to the existing technology stack over the long term.
This is an updated and revised version of an original article I wrote back in 2013 at http://dandouglas.wordpress.com