Articles about Technology Strategy

Once you’ve decided to move to an API-first architecture model, it’s tempting to jump right in building APIs, selecting an API gateway service, and standing up an API marketplace. That all takes work and delivers progress — up to a point. But, as some companies find out too late, you can pour months into standing up a state-of-the-art composability framework without really getting to ROI. You could even be increasing your tech debt. To start solving real business problems, you’ll need more than fingers on the keyboard. You’ll need to start with an API ecosystem in mind. Envisioning an API ecosystem within your organization Your API gateway is middleware, not a complete solution. It’s designed to streamline microservices delivery, running in the background to make work faster, easier, and more secure for API developers. Adding an API marketplace can help, by providing more of a storefront approach to sourcing those connections. But you can’t just build APIs and hope the right people come find them. You’ll need to go beyond the technology layer and design an API ecosystem to derive strategic value from those tools. To ensure API gateway or API marketplace platforms reach their full potential, successful organizations put strategy first. As you think about designing a future state API ecosystem to work toward, consider: What business needs your internal and external customers (API and application developers) are trying to solve How your current business processes may be helping — or hindering — those objectives Where you might find opportunities to streamline, remove friction, and accelerate progress Shifting the technology mindset from product delivery to customer experience can dramatically elevate ROI from day one by changing the way you prioritize, design, and implement each component of your solution. Your API gateway and API marketplace are utilities; your API ecosystem is how your business culture uses those tools. Driving value to your API marketplace Moving from a customer experience mindset to effecting real change and boosting the ROI of your API marketplace comes down to processes. A full process audit can help you spot opportunities for growth. First, look for processes that currently rely on APIs or on systems ripe for modernization: Which processes currently rely on APIs? Which rely on aging or end-of-life legacy systems? How might the API marketplace support more rapid composability to streamline modernization of those systems? Next, consider your current development processes: How do our developers publish APIs today? Is the API gateway frictionless, or do developers have to think about it every time? How do others find and use published APIs? If others find the API, is it easy to understand how to use it? Is the API marketplace truly self-service, or do developers waste time hunting details to implement the component? How do we manage the API lifecycle to maximize the value of our API investments? Then, consider how to use your API ecosystem strategy to level up: Reduce friction for API providers and consumers Package API instructions and information in an easily accessible way Make it easy for users to search for and implement the right API or component for their needs Manage your API lifecycle from creation to retirement Whether your business is growing or you’re already a global enterprise, once you get your API gateway and marketplace tools implemented and automated in a way that makes sense for your users and the business problems they solve, you’ll start to see results. The turn-key ability to source, consume, and change APIs makes your API marketplace nearly infinitely scalable, and flexible to evolve along with your business. Finding the right partner For organizations with significant legacy architecture, change comes at a considerable cost. You can’t afford to miss the productivity and efficiency gains that an optimized API marketplace delivers. Whether you need help imagining an API ecosystem or bringing it to life, selecting the right API marketplace or building a custom API gateway, the right partner can bring experience and expertise to get you through the roadblocks. Fusion Alliance specializes in full-spectrum digital transformations — helping organizations around the world find the right technology to fit their business needs and evolve their processes to maximize the value of their technology investments. Learn more about our approach to building a composable enterprise >>

Your grandpa wants his solution back Reality television is nearly 75 years old. Shortly after World War II ended, your great-grandparents may have watched Candid Camera on ABC. Nowadays, Survivor is on its 43rd season and the genre continues to crank up the cringe factor with increasingly dubious show premises in hopes that they’ll stumble into a hit franchise. Technology can be like that. Organizations invest in ground-breaking technology solutions, then add patches, fixes, and enhancements over time. In the short-term, companies can achieve significant process and resource savings by building onto an existing solution. But in the long-run, legacy technologies struggle to keep competitive pace, the enterprise architecture takes on a life of its own, and the organization starts missing opportunities. This is tech debt — the bane of IT departments at just about every mid-market to enterprise business. Gartner recently found that even in the face of “irrecoverable failure” of legacy solutions, many executives favor compounding technical debt by continuing to build on end-of-life systems, rather than investing in a new solution that better fits the needs of today’s business. It’s understandable. Starting over from scratch is a huge investment, with a large potential downside if it doesn’t work. Executives facing the high probability of a recession are more likely to hedge their bets. The answer, once again, is composability. At our most recent APIs Over IPAs panel discussion, IT executives from NetJets and OCLC talked over a variety of topics, including how to overcome tech debt by making the business more composable. If you couldn’t make the event, check out these short video clips: How composability can reduce tech debt How to increase API adoption (without resorting to buzz word strategy) How to decide between a COTS or custom API gateway tool Your end-of-life technology may not be quite as old as reality TV, but there’s no need to trail along with a has-been solution. Fusion's API experts partner with technology leaders from mid-market and enterprise brands to talk about the latest trends in modular applications. Find out how to get blockbuster results (without scary budgets) through composability. Register for our next APIs Over IPAs event This article was originally shared in our digital newsletter — get content like this directly in your inbox.

This panel was moderated by John Dages, Technology Solution Director at Fusion Alliance (left) and features Ryan Shondell, Executive Director of Data Services at OCLC (center) and Jeremy King Chief Enterprise Architect at NetJets (right). Good technology executives know that good directives must be followed up with action plans that create value. So how do you get the business on board with an API-first strategy? How do you enhance API adoption at the enterprise level? Solve an actual problem. Think of a legitimate felt need within a service or a function in your span of control and use microservices, headless, cloud-native, or composable functions to handle it. Buzzwords don’t drive API adoption. Follow-through does. Show the business how an API-first strategy makes their job easier. The average business user doesn’t care about fancy architecture. They don’t care if you use microservices, make something headless, or are running a composable enterprise unless it makes a difference in their day-to-day. They want the website to be faster or to have more capabilities so they can drive their own KPIs. So how do you drive API adoption when your business users are thoroughly tech agnostic? You build change management into your roadmap and win hearts and minds with results. When it comes to getting the business on board for API-first initiatives, the only way to build trust is demonstrable progress. About our panelists: Ryan Shondell is currently the Executive Director of Data Services at OCLC, responsible for developing and executing the company’s data strategy and aligned technology. This includes technical product management, data operations, data quality, and development of AI/ML capabilities, analytics, search, and all customer-facing data applications and APIs across a staff of 300. Prior to joining OCLC, Ryan held multiple senior engineering leadership positions at VMware going back to 2010, most recently as Senior Director of Engineering, where he helped to lead global development on products like Skyline and VMware Cloud. And now, he’s actually headed to Path Robotics to start his next adventure. Jeremy King has been working in Technology for over 20 years and is currently the Chief Enterprise Architect at NetJets. He started his career designing and developing embedded systems and has worked in many industries including banking, health care, travel and transportation, and integration tools. His background includes distributed cloud-native architecture, data structures and modeling, enterprise integration patterns, event-driven architectures, and API design. As a Software Architect, Jeremy has faced the challenge of making disparate systems exchange data in consistent, performant ways. His current passions include technical innovation, graph databases, and emerging API standards.

This panel was moderated by John Dages, Technology Solution Director at Fusion Alliance (left) and features Ryan Shondell, Executive Director of Data Services at OCLC (center) and Jeremy King Chief Enterprise Architect at NetJets (right). The decision to build or buy API gateway tools for your organization is rarely black and white. Building an API gateway pulls your team away from other opportunities, but buying could lead to vendor lock-in. Off-the-shelf solutions might not give you differentiating advantage, but inventing your own protocols could accelerate your tech debt. How do enterprise businesses weigh the trade-offs? When to consider building an API gateway tool The custom tool will deliver differentiated value directly to customers or enable the business to deliver that value The custom tool solves a consumer or business problem that delivers market value The custom tool gives you a competitive edge in functionality, cost, or speed to market When to consider buying an API gateway tool Your IT time and talent is needed on other revenue-driving projects Your team could use an out-of-the-box tool as a platform, and build your custom functionality on top of it as an accelerator The tool conveys significant ongoing maintenance and support savings Know which shark is closest to the boat It’s not always simple to project future savings or quantify possibility. If you’re faced with a build or buy tech decision, sometimes you have to solve for the biggest issue at hand. That could mean you buy an API gateway tool or another off-the-shelf solution. Yes, it’s a vendor dependency, but every other part of your business has them, too. If you make a forward choice, and keep your eyes open, you can avoid many of the pitfalls associated with vendor lock-in. For example, finding components that are portable, avoiding proprietary pieces, and limiting the specialized components you buy outright can help. And it’s always wise to create a backup plan. As they say, “don’t have such an open architecture that your business falls out.” About our panelists: Ryan Shondell is currently the Executive Director of Data Services at OCLC, responsible for developing and executing the company’s data strategy and aligned technology. This includes technical product management, data operations, data quality, and development of AI/ML capabilities, analytics, search, and all customer-facing data applications and APIs across a staff of 300. Prior to joining OCLC, Ryan held multiple senior engineering leadership positions at VMware going back to 2010, most recently as Senior Director of Engineering, where he helped to lead global development on products like Skyline and VMware Cloud. And now, he’s actually headed to Path Robotics to start his next adventure. Jeremy King has been working in Technology for over 20 years and is currently the Chief Enterprise Architect at NetJets. He started his career designing and developing embedded systems and has worked in many industries, including banking, health care, travel and transportation, and integration tools. His background includes distributed cloud-native architecture, data structures and modeling, enterprise integration patterns, event-driven architectures, and API design. As a Software Architect, Jeremy has faced the challenge of making disparate systems exchange data in consistent, performant ways. His current passions include technical innovation, graph databases, and emerging API standards.

This panel was moderated by John Dages, Technology Solution Director at Fusion Alliance (left) and features Ryan Shondell, Executive Director of Data Services at OCLC (center) and Jeremy King Chief Enterprise Architect at NetJets (right). How many meetings do you have with Amazon when you want to use S3 to move a workflow into the cloud? None, of course. Amazon makes its S3 service easy to find, understand, and consume. And how many meetings do you have to have when you add an API to your own organization’s technology ecosystem? The “how many meetings” test isn’t a trick question. It’s a good rule-of-thumb metric to judge whether your service is driving value or contributing to tech debt. Bottom line up front: APIs must be consumable to add value. If you’re building an API and you have to have a meeting before someone can use it, something has gone wrong and you may need to reconsider your composability approach. If you build an entire composable ecosystem that works the same way the world used to work 20 years ago, you’re cruising for tech debt rather than ROI. A functional composable enterprise requires components that are discoverable, with documented constraints and functionality, so that operators can find what they need and put it into place without a lot of hand holding. This discoverability could come from traditional documentation, or effective use of introspection endpoints to allow for programmatic, systemic discoverability. Either way, to reduce your tech debt and boost the ROI of your composability, be sure to ask yourself: how many meetings did we have before we could offer or consume this product? The closer that number is to zero, the better. About our panelists: Ryan Shondell is currently the Executive Director of Data Services at OCLC, responsible for developing and executing the company’s data strategy and aligned technology. This includes technical product management, data operations, data quality, and development of AI/ML capabilities, analytics, search, and all customer-facing data applications and APIs across a staff of 300. Prior to joining OCLC, Ryan held multiple senior engineering leadership positions at VMware going back to 2010, most recently as Senior Director of Engineering, where he helped to lead global development on products like Skyline and VMware Cloud. And now, he’s actually headed to Path Robotics to start his next adventure. Jeremy King has been working in Technology for over 20 years and is currently the Chief Enterprise Architect at NetJets. He started his career designing and developing embedded systems and has worked in many industries, including banking, health care, travel and transportation, and integration tools. His background includes distributed cloud-native architecture, data structures and modeling, enterprise integration patterns, event-driven architectures, and API design. As a Software Architect, Jeremy has faced the challenge of making disparate systems exchange data in consistent, performant ways. His current passions include technical innovation, graph databases, and emerging API standards.

Composable enterprises are more fun than they look. If you’ve got a monolithic legacy system on your hands, sticking with the status quo isn’t a fun choice. But going nuclear and building back from scratch probably isn’t realistic. Wouldn’t it be great to find a middle ground? Meet the composable enterprise. It’s an iterative path toward digital transformation, with applications repackaged into components that can be used to build new solutions across the business. Piece by modular piece, you rebuild your technology ecosystem – becoming more efficient, effective, and scalable as you go. As the glue that holds those components together, APIs are key to building a composable business. And developing secure API solutions that accommodate shifting capacity demands and amplify your technology takes a hefty dose of strategy and expertise. That’s what we love about it! If APIs are your jam, too, or if you’re wondering if a composable system makes sense for your business, let’s talk. We recommend reading, Is your composable business enterprise project working or causing tech debt? Get smart: You’ve probably spent the day wondering how speculative/sci-fi/literary fiction relates to API strategy and microservices (or maybe that’s just us). But, we’d guess, the same type of mind that enjoys transforming legacy monoliths into composable enterprises would also really track with a book like How High We Go in the Dark by Sequoia Nagamatsu. Modular pieces linked together by strong bonds leading to an intricate and ever-expanding whole? We’re here for it (the book and the technology strategy). This article was originally shared in our digital newsletter — get content like this directly in your inbox.

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 >>

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.