Articles Home | New Era Technology | Page: technology strategy

The secret to modern scalable architecture

Apr 6, 2022

Why quality is key for legacy system modernization According to Boston Consulting Group, 70% of digital transformations fail to meet expectations, deliver on time, or stay on budget. Why? For some businesses, the roadblock is executive buy-in. For others, it’s resources. But many organizations at the mid-market to Fortune 500 level agree on the need for cloud adoption and system modernization and have no qualms about paying for it. At those companies, the problem is a more foundational issue. The foundation of modern, scalable architecture is quality. The most sophisticated code and trendiest solutions can only take you so far. Without a solid process that prioritizes continuous delivery, a clean commit history, and unit testing, your legacy system modernization efforts will stall out. Legacy system modernization requires a culture shift. At a certain point, traditional enterprise architecture hits a scalability ceiling, and performance begins to suffer. Most organizations accept that strategic cloud adoption is the logical next step, but fewer understand the culture shift that a modern, scalable architecture often requires. Putting a problem into a box and calling it Kubernetes does not equal modernization. In an asynchronous cloud environment, you can’t afford to indulge a maverick developer mentality. It may sound counterintuitive, but the best way to achieve true scalability, and see cloud ROI faster, is by creating and enforcing a culture of accountability to old-school best practices. Building a quality-first culture starts with clear communication. Learning a new way of operating is hard. That’s why change management plays such a critical role in successful digital transformations. When it comes to retro-engineering a quality mindset into your IT culture, you’re requiring process changes and new skill acquisition — and those don’t come easy. Successful change at the team level takes transparency, and a commitment to clear communication. To build organizational buy-in and help dev teams take ownership of a shift to a quality-first development culture. Quality starts with testable code. You can’t inspect quality into a system. When you’re building a modern, scalable architecture you can’t afford the risk of last-second changes with huge downstream implications. Instead, commit to continuous delivery so that code reviews move beyond a formality to deliver meaningful impact. Quality builds momentum. A reliable workflow of testable code, where potential problems are spotted, assessed, and addressed right away, enables faster development. The small up-front time investment leads to significant efficiencies down the line, laying the groundwork for increasingly streamlined and sophisticated solutions. Quality delivers massive time savings. Entrenched developer cultures sometimes resist inexpensive and fast quality solutions like unit testing. It may not be flashy, but adding one extra function to do a unit test is a much simpler fix than the downtime you incur from uncontrolled code. Quality unleashes your team. Organizations sometimes go to extraordinary lengths to avoid simple quality fixes like unit testing. But when there are problems in production, they always come back to code. Rather than taking on an expensive, fragile, time-intensive work-around, getting developers up to speed on unit testing helps you get more utility from your team now and prepares your architecture for the future, when today’s tribal knowledge may not be as readily available. The most important journeys start with one step — and digital transformations are no exception. Change is hard. But overcoming resistance to achieve legacy system modernization is worth it. When your goal is a modern scalable architecture, the first step is always quality. If your modernization efforts have gotten off-track and you’re feeling stuck, we can help. Fusion helps enterprise organizations align their goals, refine their processes, and identify the right technologies to step into the future with confidence. Learn more about cloud strategy >> Schedule a consultation >>

Exploring cloud modernization challenges and the path forward

Jun 16, 2021

For companies considering cloud modernization, they focus on moving workloads and shifting away from traditional, on-premise data centers to reduce costs and improve scalability for future growth. While these are important factors, it’s only a small piece of what is possible in a successful cloud modernization strategy. By embracing new software delivery paradigms across practices, architectures, and deployment methods, your organization can facilitate comprehensive, top-down change while maximizing impact, improving CX, and increasing the bottom line. However, the modernization process isn’t as simple as moving pieces of your company from on-premise to a cloud platform. Even before you start building a strategy, you need to have clear answers to the following questions: What do we start with? How do we prioritize and rank projects? When do we start this process? To help you plan your modernization strategy and journey, we’re exploring the common questions and challenges many businesses face and how they overcome them. Jump to a section: Approaches to modernization Getting buy-in for modernization Prioritizing modernization efforts Choosing which applications to modernize The path to modernization Leveraging cloud and API strategies to enable true digital transformation Approaches to Cloud Modernization There are several different approaches to shifting applications from on-premise to cloud, and it’s important to be familiar with each one before starting the process so you can make the right choice. Let’s look at the most common cloud modernization strategies from least to most mature, and you can weigh each option against the goal for the application so you can consider the best options. 1.   Replatform (lift and shift) Replatforming, or “lift and shift,” simply means you’re taking an application in its existing form from an on-premise server to the cloud. This is a fast and minimally resource intensive approach as you don’t need to modify or fix any of the existing code. However, if there are already issues with the application, moving it in its existing form to the cloud may only make those problems worse. 2.   Move, then modernize This strategy is also known as platform as a service (PaaS). In it, you run your apps on a cloud provider’s infrastructure. Developers can reuse languages, frameworks, and containers leveraging code that’s specific to the company. The downside of this approach is likely to be missing capabilities, transitive risk, and being tethered to a particular framework. 3.   Modernize, then move Your team can update the application by modifying or extending its existing code, then moving it to the cloud. This method allows you to secure the application while adoptiong the cloud characteristics of your provider’s infrastructure but does also mean incurring upfront development expense. 4.   Replace with SaaS When the requirements for a business function change quickly, replacing your existing application with SaaS may be a better option than committing to a significant rebuild or refactor. While this cloud modernization strategy is faster and may be less expensive up-front, you may face issues like inconsistent data semantics, difficult data access, and being locked into a vendor. 5.   Rebuild or refactor Rebuilding or refactoring legacy applications requires restructuring and rewriting the existing code. This is the most time and cost-intensive option and is used for large projects, like breaking up an outdated, monolithic application into microservices or leveraging containerization. Not all applications warrant this investment but doing so will often provide a long-term value. Determining your Functions Once you determine your overall approach, the next step is determining the vehicle by which your applications will be delivered, whether by a serverless function, container, or virtual machine. Cloud modernization ensures that your application design patterns are based on principles of scalability, statelessness, and high availability, but beyond that, there isn’t a standard rule to which option is best. Serverless Going “serverless” is often the most cost-effective option for most organizations. This cloud computing application development and execution model lets developers focus on writing top-quality front-end application code and business logic without having to factor in or manage backend infrastructure or servers. Once they write the application code, they deploy it to containers managed by the cloud service provider. From there, an event will trigger the application to run and prompt the cloud provider to allocate resources to it. Once the application stops running, so does billing, ensuring your company only pays the time and resources needed during execution. Also, the cloud service provider provides the infrastructure needed to run the application and is responsible for infrastructure scalability, management, and maintenance saving your organization time and resources. Container A container is an abstract, self-contained fixture which holds everything needed to run an application, including code, system tools, and libraries. They are “minimalist” by design, holding only what is needed and are free of superfluous software that would slow down processing. Like serverless computing, containers enable your development team to build and restructure applications with minimal overhead and greater flexibility, plus, they can be moved and deployed easily. However, scalability is determined by the developer in advance, unlike serverless in which the backend scales automatically. Also, containers are restricted to their host system, so a Windows container can only operate on a Windows host while an OS container can only run on an OS host. Virtual machine A virtual machine (VM) is a software-based computer that is hosted by a physical machine but is completely isolated from it. The VM operates independently and is configured individually for the apps you run in them with the host operating system simply acts as a foundation for VMs to run. While they use significantly more processing power, a VM allows your organization to host multiple environments, offers easy scalability, and is easy to setup and maintain. Related article: 5 keys to planning a successful cloud implementation Getting Buy-in for Cloud Migration and Modernization While IT teams see the overwhelming benefits of cloud modernization, it can be difficult to gain organizational buy-in from company leadership due to the up-front costs of cloud migration and modernization. We recommend that when you’re putting together your business case for making this shift, you break down the specifics of how moving to the cloud is part of your business strategy to: Fight competitive threats and support developing technology that your business requires; you’ll be able to create and deploy new features faster Break your innovation crisis and develop new strategies that don’t rely on outdated tech stacks Replace your house of cards, moving away from constraints about fragility and inabilities to test properly Attract technical leaders rather than relying on a single specialist who is the only one capable of repairing a specific system Restructure, merge, and acquire new technology rather than maintain outdated versions of middleware that can become a burden on budgets. Position cloud modernization as an opportunity to maximize your existing investments and improve your company’s ability to meet business goals. Also, consider starting with a single use case and modernizing a single app to meet it. This can build a foundation for continued efforts. Prioritizing Cloud Modernization Efforts Once your company is ready to move forward with modernization efforts, it can be difficult to choose how you prioritize applications to move into the cloud. Starting with legacy systems can bring immediate time and cost benefits. Because legacy applications are often highly integrated into the infrastructure, shifting them can be complicated, but using APIs to decouple them from the infrastructure can smooth the way to shifting monolithic applications into granular, cloud-based functions. Choosing Which Applications to Modernize Cloud migration and modernization provides organizations with an incredible opportunity to create new ecosystems with the customer at the center of all functionalities. Traditionally, front-office functions were the only areas where customer experience needed to be prioritized. However, taking a customer-centered approach throughout the modernization of each system allows you to redefine the customer relationship to gather data effectively and improve speed and efficiency. When building your modernization strategy, consider the applications that power the customer journey across functions and departments: Front office – Customer-facing website and mobile experiences Middle office – Analytics and customer insight apps Back office – Employee-shared services, including records and transactions Starting with customer-related applications can quickly lead to positive results and buy-in for future cloud modernization projects. The Path to Cloud Modernization When evaluating potential cloud modernization opportunities, there are five key steps, 1) Align; 2) Design; 3) Connect; 4) Implement; and 5) Enable. Alignment and strategy development When building out your modernization strategy, consolidate and charter each element of the process and partner with leaders across the business. This ensures that all parties are involved, understand the project, and can provide valuable insight and input related to where to start and building an efficient path forward. Design and adoption Once your stakeholders are in alignment with the strategy, it’s time to define the north star for the architecture and technology. Analyze the key cloud platforms, then capture and socialize reference architecture. During this step, it’s important to evaluate the delivery method of your applications, keeping in mind how to keep architectures compatible. Connection and Integration While separating data can enable federation and autonomy, integration supports connection and sharing across teams. Whether you’re choosing to replatform, restructure, or replace a legacy application, consider how your apps will connect and integrate into the architecture as a whole and how you can leverage APIs to unlock modern architecture. Enabling modernization across the enterprise This is a cyclical process, and when you near the end of implementation, it will probably be time to start a new project. The cloud modernization process is always in flux and are rarely fully complete. As you iterate and refine the work you’re doing you’ll continue to increase your insight into the process while improving efficiency. Y Implementation When it’s time for implementation, it’s important to contain the risk. Make changes across your portfolio one by one. Prioritize your timeline by business case and stick to the reference architecture you built previously. Remember that the path to cloud modernization isn’t just a straight line, it should be circular to reflect an ongoing process. Leveraging cloud and API strategies to enable true digital transformation Digital transformation powers innovation and increases an organization’s ability to meet and exceed customer expectations. However, for companies with outdated IT systems and legacy applications standing in the way of progress, modernization is the way forward. Wherever you are on your organization’s journey to modernization, we’ve got resources to help you along the way. Want to talk? Just let us know.

How Agile product owners should prioritize user stories

Jun 2, 2021

Many organizations struggle to adopt Agile as part of their digital transformation. And one of the most common struggles in adopting Agile is how to move toward incremental and iterative refinement. Iterating on a goal allows more information to be gained quickly, but it also means timelines are likely to overlap. While stakeholders tend to focus on their piece of the puzzle or the next goal, product owners have to balance complex timelines and goals for multiple stakeholders. How does an Agile product owner prioritize all the overlapping timelines and goals within the wider context of their organization? There are no solid rules, and everyone has to adapt to their own organization, but many successful product owners factor in the following key principles to make their decisions and plan their sprints: Prioritize based on a mixture of urgency, importance, and size Use tactical stories to achieve strategic goals Find ways to regularly invest in maintenance These principles can increase product ownership success and even lead to greater agile adoption across your organization. As in most things, the trick is balance. Prioritize stories based on Urgency, Importance, and Size Urgency There is always pressure to prioritize urgency. You can’t turn back time, and if you miss an urgent issue then you are certain to hear about it. However, the biggest mistake product owners make is prioritizing urgency too high. There will always be urgent requests, and if urgency is your only factor, you will only end up fulfilling urgent requests. Importance Importance is not always reflected in urgency, but it must always be reflected in priority. Waiting for important work to also become urgent almost certainly spells disaster. The proactive stance of prioritizing important work against urgent work also tends to have political implications. We’ve all heard the adage “the squeaky wheel gets the grease.” The best customers are typically the ones who complain the least, so don’t punish them for that. This also applies to stakeholders. The more you incentivize good stakeholder behavior, the more you are in control of your backlog. Size Of course, urgency and importance are not the only two factors to balance. Part of the difficulty of building a sprint for a product owner is the need to also balance size. Ideally, you want constant progress throughout a sprint. It is common for a feature to get started and then get blocked. That is why you need to include user stories of all sizes. Only having large stories tends to mean stories will get handed off mid-sprint. Knowledge sharing provides value, but mid-sprint handoff only slows progress. If most stories in your backlog tend to be large, small stories will have increased priority in order to fill in a sprint even though they may be of lower importance and only medium urgency. Prioritizing through a mix of urgency, importance, and size doesn’t just create a balanced sprint, it also creates a balanced time orientation. Urgent stories make a team reactive. You can’t look forward when you’re focusing on past mistakes or present pressure. Directing your team’s time orientation beyond the present moment is a key strategy for creating a productive team. Use tactical stories to achieve strategic goals Of course, not every sprint can be a perfect balance of importance, urgency, and size. Like the strategy for directing a team’s time orientation, some choices might be preferred to create or enforce a team culture. While a product owner is the leader of their team, they also answer to stakeholders. And organization objectives, usually data-driven ones, are created with these stakeholders as part of an organizational strategy. The decisions a product owner makes that have a direct impact on reaching these objectives are called tactics. But the product owner is still leading a team! There are many strategic decisions that a product owner makes which may not have a direct benefit to organizational objectives, however, they might lead to a more productive team. Good product owners don’t just focus on tactical decisions of meeting objectives, they refine strategies that benefit the individual team and drive toward objectives in an indirect manner. For instance, retrospectives tend to generate more strategic shifts than tactical shifts. Common examples of tactics used by product owners: Sprints containing stories of varying size Proof of Concept (POC) stories which discover information to do further planning or design Prioritizing the most complex use cases first Prioritizing the most common use cases first Stories that require liaising with other teams, when collaboration is an organizational goal Maintenance which offers innovation affordances Maintenance which increases product stability Common examples of product owner strategies: Cross-training by assigning stories based on areas of weakness Siloing specialties so individuals achieve high efficiency in strategic skills Requiring recorded demos as acceptance criteria for certain stakeholders Requiring regular alpha or beta releases for highly engaged stakeholders to provide feedback “Dead sprints” following releases which allow for feedback to build before addressing it Documentation stories which seek to identify outdated/deprecated documentation and update it in order to lower future bug counts Support buckets, allocated time for bugfixes that can be released ad-hoc instead of on a sprint schedule To clarify, I am not recommending that product owners devote large amounts of resources to tasks which in no way benefit organization objectives. It’s simply a recognition that indirect benefits to objectives lead to success in certain types of organizations. Strategic stories are an intentional investment in greater future value (such as cross-training), although it’s likely that the story could provide a more immediate value to the organization as well. Find ways to regularly invest in maintenance The last key principle faced by new product owners is learning how to please stakeholders while still investing in maintenance. This can sometimes be a challenge because many product owners will get a slap on the wrist if they spend too much time or money on maintenance, and not all maintenance plays are equal. However, I always recommend a portion of each sprint is dedicated to maintenance. There are different types of maintenance, so be sure to find the maintenance tactics that fit your organization’s needs. I’ll highlight a few valuable maintenance story types that have proven effective time after time. Tests Tests almost always are a valuable play. Even for a product that truly requires a higher caliber of quality — where testing is likely a requirement of the product delivery — it is common to discover there are things that lack regular testing. Tests can mean anything from writing automated unit tests for code to walking through the onboarding process to find points of friction. Unit tests make sure untouched features aren’t broken by unrelated changes. End-to-end tests take more time to perform but ensure that the most valuable processes always work. Manual tests, popular for proofs of concept, save the time required to automate tests but take longer to perform, matching a lesser initial investment to the likelihood that something will not be tested often. Manual tests can also be more valuable than unit tests for things that constantly change since overly-specific tests tend to discover more problems with the tests than they do the thing being tested. Find testing methods that work for your product, and don’t forget that processes need tested regularly as well. Support bucket The concept of a support bucket is one of my favorite strategies. It communicates to a team that things worth building are worth maintaining. Refining products regularly shows team members their work is valuable. In cases where there is a strong bug reporting system, it is likely that the team struggles to resolve bugs as fast as they come in. A support bucket is a way to maintain a position of strength. When your team is on top of their bugs, creating a support bucket addresses incoming bugs faster and keeps them from dominating a future sprint. If bugs don’t come in as much as expected, it creates a vacuum that allows team members to define their own work. Many developers relish the opportunity to take two days to refactor code that works but is confusing. However, this is something that can only be done when there are already good tests to ensure it doesn’t cause more problems than it solves. Pre-emptive customer engagement One of the least-used but highest-value maintenance tasks is pre-emptive customer engagement. If bug reports aren’t coming in, that can mean you’ve created a high-quality product! It can also mean you aren’t hearing about difficulties encountered by customers, or customers aren’t adopting product updates for some reason. When user stories are created, it is probably easy to identify real customers to whom this user story will apply. Talk to those customers and ask them how they are using the new features. How to prioritize user stories in Agile All the talk about priority, strategy, tactics, and maintenance is great, but how do I balance ALL of that when assembling a sprint? Much of this depends on the leadership and the number of stakeholders you’re dealing with. Organizational politics can send blue-sky planning into a tailspin. In the real world, you have to not only do good work, but make sure that work gets seen by the right people, and that they are impressed. If your organization’s leadership prioritizes innovation and “shiny things” This is a sign that part of your work is about the ideas and the culture shift. This is a completely valid position for a leader. There are many political advantages to trying new things and building a culture of innovation. It is a great way to gather information for refining organizational strategy. In cases like these, the following breakdown of average sprints works well: 50% strategies of short-term investment that can get thrown out or create a culture of innovation 25% tactics supporting a long-term organizational strategy 25% maintenance Applicable tactics/strategies: POCs, specialized efficiency, regular alpha/beta releases, prioritizing common use cases first, maintenance offering innovation affordances If your organization’s leadership prioritizes long-term strategy, stability or predictable growth This is a sign that part of your job is about giving customers confidence in your products. This is not an anti-innovation position, rather it is a recognition that you are in a position of strength in your market. In cases like these, the following breakdown of average sprints works well: 50% tactics supporting a long-term organizational strategy 25% strategies to shape the team 25% maintenance Applicable tactics/strategies: cross-training, prioritizing most complex use cases first, maintenance improving product stability, improving documentation, support buckets, external liaisons Closing If you’re a product owner or your organization is beginning to adopt Agile, take a look at your organization to find out what your stakeholders truly care about. While every organization is unique, these factors are universal. Tailor your strategies to your team and your tactics to your objectives. Most of all, create balanced sprints which deliver constant progress toward your goals. Analyzing urgency, importance, and size can lead to solid prioritization that drives team success.

Insights

Insights

Articles about Page: technology strategy

The secret to modern scalable architecture

Exploring cloud modernization challenges and the path forward

How Agile product owners should prioritize user stories

Ready To Talk?

About Us

Quick Links

Stay in Touch

Contact Us