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.
Assign Performance RankingsOnce 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.
Identify Opportunities for ImprovementUsing 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 PracticesUpdating 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 BasisStack 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!