How to Stay On Top Of Advancing Stack Technology

Refining stack architecture seems like a minefield for businesses these days. There are so many exciting components parts to consider, new tools and platforms that promise to grow business or boost efficiency or provide an unbeatable customer experience. Putting together the right solution is a daunting task. General uncertainty over where to go next could partially explain why IT spending didn’t meet predicted growth levels last year. Experts thought it would reach 2.7%, but it stalled at 1.4%. Companies are making up for it this year with a potential 9.5% increase in enterprise software and technology. A large portion of that growth is aimed at modernizing stacks to take advantage of rising trends like virtual assistants and mobile BI. More interest in stack updating doesn’t translate into a sudden surge in confidence as to how to go about it, however. Companies still find themselves unsure where to begin, or how to decide what stack components should be updated. This overview of the stack updating process will highlight where a stack’s strengths and weaknesses lie, then offer guidance on how to create a forward-facing solution that will grow as the company does.

Inventory The Current Stack

[caption id="" align="aligncenter" width="640"] Source: ThoughtWorks[/caption] Before any future planning, it’s important to understand the current state of the stack. This is deceptively simple. Twenty years ago single-vendor solutions were common in designing stacks, making it simple to keep track of the technology used. Trying to integrate tools from different vendors was considered too difficult. Over time, though, more features and options became possible. With more area to cover technology advanced asymmetrically. The big tech companies decided to specialize in different areas. A host of open source products cropped up to tackle challenges that were going unmet (or just provide options). On top of that, tools are usually designed to be used modularly to add functionality instead of being components of a monolith. In such an environment there’s no longer an advantage to using a single vendor for everything. In fact, trying to do so is a fast path to failure. Developers get the best results through a diverse stack tailored to a project’s specific needs. The drawback of this approach is that today’s technology stacks can be highly complex. While once companies could have as few as four or five components, looking under the hood of an average website using BuiltWith (or similar tools) reveals dozens of tools. Few people within an organization know everything they company uses. Trying to update a stack without completing a complete inventory is a risky proposition. Some tools depend on others; switching them could cause serious problems. There’s also the risk of duplicating a function already found within the stack or unwittingly removing a mission-critical capability. Sometimes issues don’t show up until they create a major disruption to operations. To avoid this threat, stack assessment should be done before making any changes. A stack inventory ideally includes information about what technology is used and how it fits into the stack. It’s more graph than list. Some popular approaches to visualizing stack structure include connection maps, Buyer’s Journey diagrams, Layer Cakes, and function clusters.

• Connection maps: Sketch connections between elements, emphasizing how data flows through the company.
• Buyer’s Journey diagrams: Outline the buyer’s journey from awareness to conversion or return business. Place elements where they fall along this path.
• Layer Cakes: Draw a tiered diagram that places broader technologies at the base with elements becoming more specialized as they near the top.
• Function clusters: Group elements in labelled clusters by function and sub-function (like social media, analytics, inventory management). Function clusters can be connected to each other to provide more information if needed.

There’s no one best way to create a stack visualization. The method chosen should be one that makes it easier to solve the particular problem at hand. For example, if a company has been experiencing complaints about mobile user experience, they might use a function cluster to better understand the potential cause.

Assign Performance Rankings

Once the components of the stack are clear, it’s time to investigate gauge their functionality. Create a rubric to determine how well each tools performs its job. Some points to consider:

• Performance: Assess whether the tool actually works as intended. Too often companies continue using tools that no longer meet their needs out of habit, adding more products to the stack to fill in the gaps. There could be a more modern solution available that combines the functions of all those products into one tool.
• Reliability: Even when tools have all necessary functionalities, they may lack reliability. With the variety of well-maintained development tools on the market, there’s no reason to keep using one that hinders consistent workflows.
• Ease of Use: Every component in the stack doesn’t have to be approachable to every employee, but there’s value in user-friendly tool. Intuitive operations reduce the time needed to operate and maintain them as well as lowering training costs when onboarding new staff.
• Adoption rates: If people aren’t using a tool consistently, there’s an underlying problem. Either staff needs more training or the component doesn’t meet their needs and should be prioritized for replacement.
• Interoperability: Stack complexity is sometimes seen as a tradeoff for better overall performance and scalability. Components that don’t work smoothly with other tools cut into that performance boost.
• Product Support: Older components that are no longer being maintained could be a security risk.
• Actual Business Value Added: Some components are added on a trial basis and simply left in, or were pet projects of past executives. Spend a few minutes making the business case for each as if deciding whether to use them for the first time.

The rubric should be generally consistent across technologies. While function-specific performance metrics should be used to assign ranking, this should be a measure of overall satisfaction with the component. Resist the urge to rank anything 0% or 100%. If it was 0% functional it never would have been used in the stack, and there’s nothing so perfect that can’t be improved. Be careful to note where technologies interact with each other. Interconnected tools could have both individual rankings and a group ranking to guide the decision-making process.

Identify Opportunities for Improvement

Using the stack diagram and component rankings, pinpoint elements that could be improved by new technologies. This involves both identifying underperforming technology and exploring maturing technologies. To find the balance between reliability and longevity, consider the most recent alternative that has proven its business value. Would it add sufficient value to justify an investment? If not, waiting for emerging technology to mature further and reassess then. Let need drive development. Don’t upgrade for the sake of style. Remember laser disc players? Those who rushed to adopt them just because they were new ended up regretting it when DVDs came along. When the list of desired upgrades is finished set priorities based on rankings and potential value added. This is potentially the trickiest part. Without understanding the technical function of tools it’s hard to establish an optimal replacement order. Companies who already have a relationship with a good developer should bring them in to clear the uncertainty. For others, many developers offer free or low-cost consultations. Choose the consulting developer as carefully as one intended for a specific project. That way, once a decision is made about which stack component to upgrade first the company can begin development without the hassle of switching developers.

Favor Modular Development Practices

Updating a stack requires significant investment. Protect that investment by choosing new tools with an eye to the future. The focus should go beyond selecting useful tools; it’s also important to align components in such a way that upgrading or replacing them down the road creates the least possible disruption. The current trend for achieving this is phasing out monoliths in favor of modular architecture. Software “monoliths” consist of a mainly solid core infrastructure that functions as a whole and has specific requirements for connectivity with outside tools. Modular development is an agile, flexible philosophy that emphasizes scalability and breadth of functionality. It features independently functional components that can be upgraded or replaced as they age out. Doing so allows modular architecture to incorporate cutting-edge tools without rebuilding the stack entirely as required in monolithic development.

Evaluate on a Continuing Basis

Stack optimization needs to be an ongoing process. Regularly reassess performance rankings rather than relying on the same ones to compare to new technologies. What works today might not work tomorrow; using old rankings could lead to comparing a new platform to how the existing platform performed five years before instead of how it works now. Be open to development, but don’t feel pressured to advance for advancement’s sake. Instead, let need and data drive upgrades. Keep an eye out for new technologies that could smooth pain points or offer a sizable competitive edge. Remember that no one important is looking at a company’s stack and handing out grades. Customers judge a company based on performance and functionality.

Updating your stack architecture is a delicate balancing act. Concepta’s team of experienced developers have the knowledge to guide decisions on which components to retain and where investment is needed. Schedule your free consultation today!