Risks with Using External APIs: A Tech Guide to Staying Safe

External APIs (Application Programming Interfaces) are a powerful tool for developers, letting apps talk to each other and share data or services seamlessly. Whether you’re building a weather app that pulls data from a weather API or an e-commerce site using a payment API like Stripe, external APIs can save you time and effort. But they come with risks that can impact your project if you’re not careful. With the growing reliance on APIs in cloud-based and microservices architectures, understanding these risks is more important than ever. In this article, we’ll explore the main risks of using external APIs, how they can affect your tech projects, and tips to mitigate them. Let’s dive in and uncover the potential pitfalls of external APIs!

What Are External APIs and Why Use Them?

An external API is a set of rules and tools that lets your app communicate with a third-party service over the internet. For example, if you’re building a travel app, you might use the Google Maps API to show locations or the Skyscanner API to fetch flight prices. These APIs let you access features or data that you don’t have to build yourself, saving you time and resources. They’re widely used in software development because they allow you to add complex functionality—like payment processing, geolocation, or social media integration—without starting from scratch.

But while external APIs are convenient, they introduce risks because you’re relying on a service you don’t control. If the API provider changes their service, goes down, or has security issues, your app could suffer. Understanding these risks can help you plan better and protect your project from unexpected problems. Let’s break down the main risks of using external APIs and how they might affect your work.

Risk 1: Downtime and Reliability Issues

One of the biggest risks with external APIs is downtime. Since you’re relying on a third-party service, if their servers go down, your app might stop working properly. For example, if your e-commerce app uses a payment API like PayPal, and PayPal’s servers are down, your customers won’t be able to check out. This can lead to lost sales and frustrated users.

Downtime can happen for many reasons—server outages, maintenance, or even cyberattacks on the API provider. In 2023, a major outage at Twilio, a popular communication API provider, disrupted thousands of apps that relied on its SMS and voice services. If your app depends heavily on an external API, you’re at the mercy of their reliability. Even APIs from big companies like Google or AWS can experience outages, though they’re usually rare.

To mitigate this risk, check the API provider’s uptime history—many publish their service-level agreements (SLAs) promising a certain percentage of uptime, like 99.9%. You can also build fallback options into your app. For instance, if a weather API fails, you might show cached data or a message explaining the issue to users. Planning for downtime ensures your app stays functional even when the API doesn’t.

Risk 2: Security and Privacy Concerns

Security is a major concern when using external APIs, as you’re sharing data with a third-party service. If the API provider has weak security practices, your app—and your users—could be at risk. For example, if you’re using an API to process user logins, and the API gets hacked, attackers might steal sensitive data like email addresses or passwords. In 2024, a data breach at a popular marketing API exposed user data for thousands of apps, highlighting how API vulnerabilities can ripple outward.

Another issue is privacy compliance. If your app handles user data, you need to follow laws like GDPR (in Europe) or CCPA (in California). But if the API provider doesn’t comply with these regulations, you could be held responsible for any violations. For instance, if a third-party analytics API collects user data without proper consent, your app might face fines or legal trouble.

To reduce security risks, choose API providers with strong security practices—look for HTTPS encryption, regular security audits, and compliance certifications like ISO 27001. Also, limit the data you share with the API to only what’s necessary. For example, if you’re using a mapping API, don’t send user info that isn’t needed for the map feature. Finally, use API keys or OAuth for authentication to ensure only authorized requests are made, and monitor your API usage for unusual activity.

Risk 3: Unexpected Changes or Deprecation

External APIs can change without warning, which can break your app. API providers might update their endpoints, change how data is formatted, or even shut down the API entirely—a process called deprecation. For example, in 2022, Google deprecated its older Hangouts API, forcing developers to migrate to a new version or find alternatives. If your app isn’t prepared for these changes, it could stop working overnight.

Even small changes can cause big problems. If a weather API you’re using changes its response format from JSON to XML, your app might not be able to parse the data correctly, leading to errors. These updates often come with little notice, especially from smaller providers who may not prioritize developer communication.

To manage this risk, keep an eye on the API provider’s changelog or developer blog for updates. Many providers, like Stripe or Twitter, have email notifications for API changes. You can also version your API calls—most providers offer versioned endpoints (e.g., /v1/endpoint) to ensure stability. Finally, have a backup plan, like switching to a different API or building a workaround, in case the API gets deprecated.

Risk 4: Performance and Latency Issues

Using an external API can slow down your app if the API’s performance isn’t up to par. Every API call involves sending a request over the internet, waiting for a response, and processing the data. If the API is slow, your app will be too. For example, if you’re using a geolocation API to show a user’s location on a map, and the API takes 5 seconds to respond, your users will have to wait, which can hurt their experience.

Latency can also vary depending on the API provider’s server location. If your app’s users are in Europe, but the API’s servers are in the US, the distance can add delays. High traffic on the API provider’s end can also cause slowdowns—think of a payment API struggling during a Black Friday sale.

To minimize performance risks, test the API’s speed during development using tools like Postman or curl to measure response times. Choose providers with servers close to your user base, or use a content delivery network (CDN) to cache API responses. You can also implement caching on your end—store frequently used API data locally so you don’t need to call the API every time. For example, if your app shows weather data, cache the data for an hour to reduce API calls.

Risk 5: Cost Overruns and Rate Limits

Many external APIs aren’t free, and costs can add up quickly if you’re not careful. Most APIs use a pricing model based on usage, like charging per API call or offering a tiered subscription. For instance, the Google Maps API charges based on the number of map loads or geocoding requests. If your app suddenly gets more users, your API usage—and your bill—could spike unexpectedly.

Rate limits are another issue. APIs often cap how many requests you can make in a given time—like 1,000 calls per hour. If you exceed this limit, the API will block your requests, causing your app to fail. For example, if you’re using a social media API to pull tweets, and your app goes viral, you might hit the rate limit and lose access to the API temporarily.

To avoid cost overruns, monitor your API usage closely using dashboards provided by the API provider, like AWS’s billing console or Stripe’s usage tracker. Set budget alerts to warn you if costs get too high, and optimize your app to make fewer API calls—caching and batching requests can help. For rate limits, design your app to handle them gracefully, like showing an error message to users or queuing requests to stay within the limit.

Risk 6: Dependency and Vendor Lock-In

When you use an external API, you become dependent on the provider, which can lead to vendor lock-in. This means your app is tied to their service, making it hard to switch to another provider if needed. For example, if you build your app around the Twilio API for SMS, and Twilio raises prices or shuts down, you’ll need to rewrite parts of your app to use a different API, which takes time and effort.

Vendor lock-in can also limit your flexibility. If the API provider doesn’t support a new feature you need, you’re stuck until they add it—or you’ll have to find a new provider and migrate. This dependency can slow down your development and make your app less adaptable to changes.

To reduce dependency, design your app with flexibility in mind. Use abstraction layers—like a custom wrapper around the API—so you can swap out providers without rewriting everything. For example, if you’re using a payment API, create a generic payment module in your app that can work with Stripe, PayPal, or another provider with minimal changes. Also, choose APIs with open standards or wide adoption, as they’re less likely to disappear suddenly.

Tips to Mitigate Risks When Using External APIs

Here are some practical tips to stay safe when using external APIs in your projects:

• Research the Provider: Before choosing an API, check their reputation, uptime history, and security practices. Look for reviews from other developers on forums like Stack Overflow or Reddit to see if they’ve had issues.
• Test Thoroughly: Test the API during development to understand its performance, reliability, and error handling. Use tools like Postman to simulate API calls and see how the API behaves under different conditions.
• Monitor Usage: Keep an eye on your API usage with tools like the provider’s dashboard or third-party monitoring services. Set alerts for rate limits, costs, and unusual activity to catch problems early.
• Plan for Failures: Build fallbacks into your app, like caching data or showing error messages, so it can handle API downtime or rate limits without crashing.
• Document Everything: Keep detailed documentation of how you’re using the API, including endpoints, authentication methods, and fallback plans. This makes it easier to troubleshoot issues or switch providers later.
• Stay Updated: Follow the API provider’s updates via their blog, changelog, or email notifications. This helps you prepare for changes or deprecations before they affect your app.

By following these tips, you can use external APIs confidently, knowing you’ve planned for potential risks and can handle them if they arise.

A Real-World Example of API Risks

Let’s look at an example to see these risks in action. Imagine you’re building a fitness app that uses the Fitbit API to pull users’ step counts. One day, Fitbit’s servers go down (downtime risk), and your app can’t show step data, frustrating users. Later, Fitbit gets hacked (security risk), exposing user data and putting your app at risk of legal issues. Then, Fitbit updates its API, changing the data format (change risk), and your app breaks because it can’t parse the new format. Meanwhile, your app’s user base grows, hitting Fitbit’s rate limit (cost/rate limit risk), and you’re charged extra fees. Finally, Fitbit raises prices, but you’re locked into their service (dependency risk), forcing you to either pay more or rewrite your app for another API. This scenario shows how API risks can pile up, but with proper planning—like caching data, monitoring usage, and using abstraction layers—you can avoid these pitfalls. (Fitbit was just an example - I don't imply that this happens to Fitbit).

Final Thoughts on Using External APIs Safely

External APIs are a game-changer for developers, letting you add powerful features to your app without building everything from scratch. But they come with risks like downtime, security issues, unexpected changes, performance problems, cost overruns, and dependency. By understanding these risks and taking steps to mitigate them—researching providers, testing thoroughly, monitoring usage, and planning for failures—you can use APIs safely and effectively. Whether you’re building a small app or a large-scale system, being aware of these risks will help you create more reliable, secure, and cost-effective applications. So, the next time you integrate an external API, take a moment to plan ahead—it’ll save you a lot of headaches down the road!

Resources for Further Learning

Want to learn more about using external APIs safely and managing their risks? Check out these helpful resources:

Books on Amazon:

APIs: A Strategy Guide by Daniel Jacobson, Greg Brail, and Dan Woods (Buy book - Affiliate link) – A great book on API design and management, including risk mitigation.

Designing Web APIs by Brenda Jin, Saurabh Sahni, and Amir Shevat (Buy book - Affiliate link) – Covers best practices for working with APIs, with a focus on security and reliability.

RESTful API Design by Matthias Biehl (Buy book - Affiliate link) – Explores API design principles and how to handle risks like changes and deprecation.

YouTube Videos:

Top 12 Tips For API Security

Understanding The Fundamentals of API Security | How APIs are Attacked and How to Secure Them

Unmanaged APIs are hurting your productivity and security. Start managing your sprawl with API Hub

Keeping Up with Security Fixes and Patches in Software Development

Introduction

Every other day, headlines scream about another security breach. Hackers have stolen credit card data, passwords, or even social security numbers. These stories might seem distant, but for the organizations affected, the damage is real and often severe. The consequences range from customer data loss and reputation damage to layoffs and crashing stock prices. While billion-dollar companies might survive such shocks with minimal tremors, smaller or mid-sized businesses can face lasting consequences.

You might feel immune to such threats. Perhaps your project has never faced a major breach. Maybe you're not even on a hacker's radar. But security risks aren’t always about direct attacks. Sometimes, vulnerabilities lie hidden in third-party components or outdated libraries quietly integrated into your software—a ticking time bomb waiting to be exploited.

How Hidden Security Flaws Enter Your Project

Most modern software projects rely on a variety of external components. These include libraries, plugins, media decoders, frameworks, and even code snippets. It’s neither feasible nor efficient to write everything from scratch. Developers use these components to accelerate development, reduce costs, and integrate complex functionalities quickly.

A great example? Media decoders. Handling all image, audio, and video formats from scratch would be a massive undertaking. Instead, developers include libraries or use built-in OS-level capabilities. While convenient, these additions come with their own risks. Once an external component becomes part of your application, so does any vulnerability it carries.

The Real Risk of Inaction

Here’s the problem: if a flaw is found in a component you've used and the fix hasn't been applied (or your users haven’t updated yet), the vulnerability persists. Tools and scripts to exploit such holes are widely available, making it easy for even low-skill attackers to cause harm. And if a breach occurs due to an issue in your distributed software—even if the root cause is third-party—your customers will hold you responsible.

A Simple Example

Imagine your software includes a third-party component for parsing image formats. A security researcher finds a buffer overflow flaw in that component. The maintainers release a fix. But if you don’t integrate that fix, repackage your software, and distribute it promptly, users remain vulnerable. If someone launches an attack using a specially crafted image, the consequences could range from crashing the application to complete system compromise.

How to Stay Ahead of the Threat

You can’t eliminate risk entirely, but there are several effective strategies to manage it:

1. Component Inventory and Exposure Matrix

Maintain a detailed inventory of all third-party components used in your software. For each component:

• Record its version.

• Note its criticality to the application.

• Evaluate whether it could be exposed in ways that attackers might exploit (e.g., input parsing, network interfaces).

This matrix should be accessible and updated regularly.

2. Monitor Security Feeds and Vulnerability Alerts

Use tools or subscribe to feeds that alert you to vulnerabilities in libraries or frameworks you use. Websites like:

• NVD (National Vulnerability Database)

• Snyk

• GitHub Security Advisories

These resources offer real-time tracking of reported issues.

Assign a team member the responsibility of monitoring these sources and flagging any issues relevant to your project.

3. Establish Response Protocols

Define a pre-approved plan to respond to discovered vulnerabilities:

• How critical is the flaw?

• Does it require immediate action or can it wait for the next release?

• Who investigates and verifies?

• Who tests the patch and deploys the update?

Having a pre-determined strategy ensures a calm and measured response when problems arise.

4. Handle Legacy Releases Thoughtfully

This is a bit tricky. What happens when a vulnerability is found in an older release—say, a version two iterations back? You need to evaluate:

• Do you still officially support that version?

• What is the severity of the flaw?

• What effort would be required to fix it?

If the flaw is minor and the release is obsolete, you might decide not to fix it. However, if many customers still use that version, and the vulnerability could cause significant harm, a patch or workaround might be necessary.

5. Define a Clear Communication Strategy

When a vulnerability is discovered, communication is key. Your customers need to:

• Know that you are aware of the problem.

• Understand the impact (or lack thereof).

• Receive clear guidance on what to do next.

Sending timely updates, publishing knowledge base articles, and even issuing patches proactively builds trust and positions your organization as responsible and customer-focused.

Automation Helps, But Can’t Replace Strategy

Tools like Dependency-Check, npm audit, or automated scanners are excellent. They notify you when outdated or vulnerable packages are present. However, these tools only work if you integrate them into your build process and actually respond to the alerts. Technology can assist, but without policies and accountability, vulnerabilities will still slip through.

Best Practices Recap

• Maintain an inventory of all external components.

• Rate the risk level of each component.

• Assign a team member to monitor vulnerability disclosures.

• Define an internal process to assess and respond to each risk.

• Decide how long older versions are supported and what patch policy applies.

• Communicate clearly with customers when a flaw is identified.

• Automate scanning wherever possible, but maintain manual oversight.

The Bigger Picture: Why This Matters

Security flaws impact more than just your application. They affect trust.

• If a customer discovers a vulnerability before you do, their confidence is shaken.

• If attackers exploit the flaw, the damage can go beyond your software to your brand.

• If news of the breach spreads, legal, financial, and reputational harm could follow.

Being proactive about vulnerabilities isn’t just about code. It’s about credibility.

Conclusion

Security isn’t a one-time task; it’s a continuous process. With the speed at which threats evolve and the increasing use of third-party code, staying updated with security fixes and patches is more important than ever. By implementing structured processes, assigning clear responsibilities, and maintaining a strong communication line with your users, you significantly reduce your risk.

Treat security as a core feature of your software, not an afterthought. Because when trust is broken, no patch can fully fix it.

Inter team - Pushing for your bug fixes

When you work in a slightly larger software development organization, you will find that there are numerous cases where teams have dependencies on external teams for getting defect fixes. A simple example can explain. Say, there are multiple teams that need a function for coding / decoding music - and there are so many different audio formats, some of which have free solutions, and others which are paid solutions (and even in the paid solutions, there will be some that are very cheap and others, for some specific audio formats, which are very expensive). To further complicate this, each external solution will have its own set of legal formalities and requirements which may or may not be easy fort the organization to follow (some of the open source solutions are almost non-touchable for typical software organizations because they have some stringent requirements on their own, like insisting that any software that uses them must be open source in its own way).
And there can be numerous examples such as this; we used to have a simple XML parser that almost every software would need, and as a result, there was one team that was mandated to write such a parser and own the solution. Net net, where there are multiple teams that need a common functionality, it makes sense for a central team to create and own this common functionality, to update it as and when needed and provide the required updates to all the teams that depend on them.
However, this dependency on a central team can be tricky. With every organization and every team working on the concept of limited resources, the question of priority comes in. Teams that are more important and critical to the organization realistically have more say in the release timeline of central components, and more importantly, the bug fixes that go into the central component.
For a team that ranks somewhat lower on the priority, it can be a strugle to get the component with your desired bug fixes as per your schedule, and realistically no amount of hollering or screaming is going to change that basic truth. However, you still do need those bug fixes, so what do you do ? It is not a simple solution to write your own code to replace the component - it may not be allowed, the resources or other costs may not be available to do this, or your team may not even have the capability to do this. Another solution is to align your schedule with some of the more higher priority teams, atleast you would get a rock solid component with some of the high priority bug fixes in it. If this is not really a solution, then another method is to ensure your communication is top notch. The relevant people in your team (both management and technical) are part of any mailing lists or discussion groups that talk about the component, its features and defects. Similarly, there is a need to setup regular checkin meetings with the component team to ensure that your relevant defects are passed on along with the required priority and severity. Further, you need to communicate regularly with the other team to ensure that your defects remain on their radar (including with the product management function who decide on features and defect fixes). All of these measures help to ensure that your required defects or features get highlighted; whether they make it or not is still not guaranteed though. It does help though if you are able to get customer inputs about the defects or features which tries to increase the importance of the defect or feature.

Supporting previous versions of the software (Part 3)

This is a line of posts that talk about the reason why software companies may drop support for a previous version of software that they have released. For example, Microsoft has released many previous version of the Operating Systems (out of which a number of them are no longer supported), many previous versions of its Internet Explore Browser (again, many previous versions of the browsers are no longer supported), Adobe has released many previous versions of popular software such as Photoshop or Acrobat (and periodically drops support of previous versions of the software), and so on. Does it mean that there are no problems when the organization drop support of these versions of the software ? No, but the number of users who are outraged by this dropping of support is low or there is an upgrade path for those users and hence it is possible for the company to do this.
In the previous post (Supporting previous version of the software - Part 2), we talked about having analytics and data information about the number and percentage of users who are using the version of software that is proposed to be dropped, and hence the organization can take an informed solution.
In this post, we will talk about a situation where the hand of the organization is forced. For those involved with designing software products, the question of component dependency is a double-edged sword. When you are making your own software (we'll consider the case of building a software product for the Windows environment), you do not build each and every functionality. There are many organizations that have built components that do specialist work much better than you would be able to do so. For example, for building a video application, it would make more sense to license the usage of a specialist video codec that does it much better than you could. With this advantage, there are some disadvantages as well. You have locked yourself to this component (and large modern software products may use tens or hundreds of such components). In most cases, even when the external component gets upgraded, the upgrade would happen in such a way that software products using such a component can still work. However, over a period of time, especially when a number of years have passed, there can be many problems that come up because of this component dependency. For example, the company that has built the component has gone out of business, or sold the business, or did something similar. This may still work, but it gets even more complicated when defects start cropping up in that component (and customers start reporting those defects). In such cases, when the version of the software is pretty old (more than a couple of versions old), the organization starts veering to the decision that it cannot fix the problem. Even if a fix of the component gets available in some way, it would just be possible to easily fix the problem, or the effort involved to fix, and test this problem would be deemed as not justified.
Consider another case where the software dependency is on some component for which support itself has been withdrawn. Consider the case where you would have integrated a previous version of the Internet Explorer browser support in your product, and Microsoft has withdrawn support for this version of the Internet Explorer. When you start running into multiple such problems, then taking a decision to drop support becomes easier.
Read the next post in this series (Part 4)

External components: Sending one's own proposed schedule

This is something that happens in larger software development organizations. Typically, there would be multiple teams within the organization, responsible for specialized stuff. For example, a number of organizations have separate teams installer and build process since that is a function reasonable similar across multiple teams / software applications; there are many common components dealing with technical requirements that are common across applications - such as parsers, decoders, encoders, imaging libraries, document readers, and so on (the list of common technical stuff can be pretty large).
When an organization has multiple software development teams, there will be different schedules for the teams, with many of these schedules being widely different form the other teams. There will also be different priorities for these teams, with some products having a higher priority while other products may not be so important for the component team - this is also dependent on the money making capabilities and strategic importance of the various products within the organization. In addition, with different schedules for different teams, and the component team having a different schedule from our own team, reconciling the schedules in order to ensure that the product quality is good enough to take the component at the time of incorporating the schedule.

Consider an example:
Team XYZ - the team in which we are working
Schedule for team XYZ - Start in Feb, take component of high quality by July and release product by October

Component team - Need to take a component from this team
Schedule for component team: Previous component will release by January; next release will be in December

With these schedules being out of sync, taking a component where features have been incorporated and a good quality level being achieved looks difficult. There is no option to change the schedule of the component team, since they are in sync with another product, and that product has a higher priority. So what can be done ?
Well, this sort of schedule mismatches can happen fairly often, and there are solutions possible. Essentially, there is a need for having an ongoing communication between both the teams. The component team should be fully aware of our schedules, including the timeline by which an initial version of the component would be required, more versions to be taken with defect fixes, and a final version of the component.
In the end, there will be compromises needed to be made, with some features that could be taken, others that could not be taken for the current release, and if necessary, a fork made in the development of the component where a minimal set of features would be taken up and provided to our team.

Using the latest version of external components - Needs attention

Most software applications do use components that are not created by the software team; these could be components created by other teams within the organization, or by using components created by other organizations. For so many different functions, it is not required that the team try to do everything on their own; for example, you could consider many different types of parsers, or system access components, or image manipulation components, or video codecs / decoders, etc. In all of these, these are specialized components created by people far more competent in these areas; it would always make sense to use these components rather than try to replicate such software within our own application.
When your software is larger, there would be more such components that are in use which are created by other parties. Over a period of time, it gets to be a task to track all such components. I have experience where we used such components the first time many years back, pay for using the component at every new version of the application, and the number of such components that are in use is well over 50 within the application (some of those are free, others are paid with minimal charges, and some can be pretty expensive - some of the specialised video codecs can be pretty expensive, although one cannot do business in the video area without using these codecs in order to look professional).
Just like our software is updated with every version with new features and defects, even the components that we use also get new versions. In many cases, we could still continue using the older components since the newer version does not promise any new features that we need, and we can avoid the overhead of trying to incorporate a new version. However, it is still required to monitor these external components to ensure that we know the reasons why the new component has been released.
In many cases, there may have been some critical defects found in the component which required a new version to be released. In such a case, we should need to evaluate the defects that were found to determine whether it is required for us to take the new version. In some cases, the defects could be in a section of the component that we do not use, and hence we could still continue to use the old component. But in many cases, the defects are serious enough that it could pose a risk to the software application unless the new version of the component has been taken. However, taking the component will have an overhead, since other changes that have been implemented in the component would need to be evaluated and testing done to ensure that no other impact is caused due to these changes.
This whole process of ensuring a watch on these components is troublesome and takes time and effort, but it is essential. One would not want to release a software that integrates an older version of the component which has some serious risk. This can have further impact, and in some cases, the external component provider mandates that the newer version of the component has to be used.

Need for doing a legal audit to detect all 3rd party instances

A lot of people do not even know about this concept ? What is a Legal Audit (or a similar name that may be followed by different software organizations). However, most project / program managers would know about using components from many different sources. And you would also have heard about patent disputes, where companies challenge each other about the software that they have written, and whether one of them was entitled to damages from the other for using a certain code over which the other claimed ownership (actually a patent is about the principle or concept or a specific feature, but you get the general idea).
How does this fit into the idea of something called a Legal Audit ? Patience.
Let me take a real life principle. In our team during the course of a product development cycle, the team is informed at the beginning of the cycle that they will not use any component from outside without speaking to their manager. However, during the middle of the cycle, I was speaking to the team about this (as a repeat) and later one of the team members approached me. It turned out that he was looking for an efficient XML parser and searched for an external component that would help him in this; he found something on the internet, downloaded and used it. Seems fine, after all, a lot of people might do this.
The problem was, we are living in a world where we need to respect the rights and copyrights of others, if we want others to respect our software. Our software has a global market of $40 million, and nobody would welcome a case against us for unlawful usage of an external component. It could be that we were fine with using this component, but nobody had done that kind of check. We looked at the component, and found that it had a license that was never going to be allowed for usage. The license wanted $1 for every customer usage of the software where this component was going to be installed, and if you think that we were ready to pay out tens of thousands of dollars for using such a component, I have nothing to say.
The Legal Audit is a way to do a scan of the software code to ensure that all the external components that are being used in the software are known, and the licenses are all approved towards this end. For product development where the product has been going through multiple versions, a lot of the components would have been in regular use over the years, and these can be quickly discounted. Most organizations would have a way to do this process in a way that minimizes the effort required.
Doing this process is essential, and in most cases, would require consultation with some software engineer or manager as well as with a legal expert (to sign off the final license agreements and to certify that the overall set of licenses used in the software are fine from the perspective of the organization).
And the Legal Audit can only be complete when the writing of new software is complete, since only then can it be sure that there is no further new code going to be written.

Getting technical teams to talk to each other for technical discussion of features

We work in a world where a software development team cannot exist entirely on its own. It is true that the software team develops a large chunk of the features of the application, with coding and testing of most of the features of the application. However, software teams do end up using code written by other persons or teams, in the nature of components and functions written by other teams. One of the most common cases is when there are large software organizations, where there are central teams that create common components. Such components could be used for specialized purposes such as reading and writing to the disk and to optical disk drives, reading and writing varied video and imaging formats / codecs, components that are meant to create a specialized user interface, and so on. If you are working for a large organization, there is a good chance that you will be using such examples of components in your product, and also using other bits of code that is written by other people or teams.
As a consequence of this dependency on other teams, there is a need to have a regular synch-up with these teams to ensure that there is a ongoing discussion with these teams - these regular discussion could be related to the requirements, the schedule, the process of coordination, and and so on. However, some of the discussion that gets missed unless the teams have already had an agreement over the requirements and the schedule is that of the technical teams and the architecture. A lot of time there is the assumption that unless there is an agreement between the teams, there is no need for a regular technical discussion.
However, this can be a fallacy. When the discussion is between teams within an organization, there are far greater chances that there will be an eventual agreement between them. And in many other cases, this would not be the first time that the component will be integrated into the product, the discussion would be related to a newer version of the component that will be integrated into a newer version of the product. In such a case, it makes sense to have an ongoing technical discussion between the product team and the component team. It is also very likely that the technical discussion will be as important as the requirements discussion, since most of the issues in such an integration are of a technical nature. Further, having an ongoing discussion also means that then needs of your team remain high in the attention span of the product team, and that also makes it easier to get what you need from the requirements team.

Working with external teams to ensure that they fit your requirements into their schedule

I work in an organization that is fairly large, being a $500 million organization, having a number of products being worked upon by different product teams. As a part of this process, there are also many common components that are made by a few central teams, which provide functionality common to most of the products. For example, when you consider that functionality such as reading and writing to optical media, being able to open and write to video files, etc are common functionality, it makes a lot of logical sense to ensure that these functionality are done by a common team and then other teams pick it up. It is not such a open and dried system though, there are elements of complexity in these systems though:
- The various product teams that pick up these common components or code have different schedules, while the common component teams follow a set schedule (in most cases, this schedule is set primarily by the most important product team - for example, if you take the case of Microsoft, the MS Office or the Windows team will have a much higher priority than somebody working on Skype, and the schedule for a common component will be more geared towards the schedule of Office rather than that of Skype)
- The features needed for each product could be different, even if these are tweaks. The common components may provide a core technology, but even in these, there could be significant differences. A product that is geared towards an expert in the field of video would demand support for a more comprehensive set of video formats, while a more entry level product would just want support for a few widely used video formats. The makers of the common component have to work towards balancing the needs for such different requests for requirements, using the priority of the products that are requesting such features as a variable in making decisions.

As a result, if you are not part of the most important team, you have to keep in mind that your requests, even though important to your team, and critical, may not make it to the final list of items that the component team is working on. We have been in that position, and it can be pretty painful, but you are reminded that it is a decision meant for the good of the organization. What can you do about such a situation ? Well, there are a number of items that you can do:
- When you know that such a prioritization problem can happen, you need to ensure that for requirements which require a modification in the common component, you start working a bit early on those requirements and have the relevant discussions with the component team early. The later you present your requirements to the external team, the more problematic will be the conflicts that the external team will have to factor in, and the higher the probability that your requirements will not make it.
- Strike up a discussion with the product team that drives the requirements of the component team and learn about what are some of the new features that they are looking for. Evaluate those to see which of those fit into your requirements, which will give you a higher chance of ensuring that your features do make it.
- Even if the requirements differ like the point made earlier about different products requiring different levels of video format support, getting into discussions early and having more discussions geared towards such kind of support can ensure that the component team is able to provide alternative functionality, such as the same component providing different levels of functionality depending on variables that are passed to the component.

Working early with providers of external components to test out with your software and verify that everything is fine ..

If you have been reading some of the posts that I have written, there are several dealing with working with those groups within or outside your organization that make the components that you use in your software application (with the assumption that most medium-to-heavy complex products use a number of components inside so as to get some great functionality without having to write all that amount of code themselves). Now, there can be several problems when dealing with components:
- You may have no control about the features being built into the next version of the component and whether those features that are indeed built in work well with the product.
- Your features or defects don't fit into the priority of the component and the schedule of the component does not work for you
- The quality of the component that is delivered to you is low enough that you keep finding defects in the component and are unable to accept the component
- And some more ..

And yet most software applications will use components. For example, there makes no sense for individual applications to write code that replicates the connection to media such as DVD's/Blu Ray, etc. Instead, it makes sense to use a ready-made component to do this; and in most cases, the interaction with the component does not cause significant problems.
But there are steps you can take to ensure that you have as much control over your fortune while integrating with the component:
- You retain in regular touch with the component team, both at manager level and at individual team level; this includes a standing meeting that happens at periodic intervals
- Have discussion with the component team about your interactions with the defect database, defect assignment, and a Service Level Agreement about how to ensure that defects are seen early and fixed early
- This next step may seem somewhat resource heavy, but it is very useful. You need to ensure that you have a request pending with the external team that they provide you this component before it is ready; that is, you get regular copies of the component during the development phase. This ensures that you find problems early, rather than later when there are problems found near the release date of the component, and is pretty much almost impossible to fix such defects. Once you are getting the component on a regular basis, you can work out with the QE team about an optimization method to ensure that these deliveries of the component are all tested and any issues are sent off to the team that is making the component, so that these defects or even feature requests can be handled by the component team.

Application dependencies: Ensuring that third party plugins are upto date with the latest software version

Software development involves working with and resolving a lot of dependencies. I have been writing about the dependencies related to vendors (Article 1, Tools, Process sharing)  and those relating to the use of components (Article 1, Article 2). But this is not the only dependencies that happen in a software project. When you look at big software such as Photoshop or Microsoft Office, these software and other large software deliver a lot of functionality. However, there is always the effort by all such software companies to get a lot of experts and users to extend these software in terms of adding functionality through the use of software. If you take these software, there are actually a number of companies that provide third party components, some of them free and others that users can buy. If you consider a software such as Photoshop, there are a large number of components available that provide extended functionality, such as being able to do a better job of photo manipulation, additional effects for the software, and so on.
Having such components also adds a lot of benefit to the software, since this is ensuring that there is a eco-system that grows around the software, and with these components adding functionality to the software, there is a larger set of users who grow attracted to the software. But, with all these functionality, there is an additional amount of dependency and risk. Any software goes through changes during the product development of a new version, and many of these changes can impact the integration of these components with the product. For example, during the development of a software version, we made changes to the database in which product information was being stored, and this database change meant that a number of such services through which components linked to the database would no longer work, and even if they would work, there could be changes in the way they worked. Such a change is a big thing, since the component makers go through the same challenges as the makers of the software, and there is a lot of synchronization that needs to happen with relation to the component makers. What are some of the processes that need to be gone through for such a change:
- As and when there are changes that could impact a component, there needs to be a discussion with the maker of the component. Detecting such a change is possible for the software team, but it can be difficult. It is far easier to add the component maker to the beta program of the software component maker, and they can check the ongoing version of the software in the beta program with the component and evaluate for any change.
- At the same time, there needs to be a testing effort to ensure that the product team (if through automation, then makes it easier) is also periodically checking the components with the software and informing the component maker if there is any problem
- The product team also needs to have the latest version of all the components to test all of these on a periodic basis. They cannot just depend on the component maker for the same, since if there is a major problem, then there is an impact on the credibility of the product team (for example, in an extreme case, it would be a real problem if the product was crashing on the installation of a component)
- There should be a mailing list which has all the component makers on it, and where the team can send out important updates on any changes in the product that could impact the components

However, there needs to be some limit on the amount of changes that are made in the product in every version. When people buy a component along with a software, they have the expectation that the same component could work in multiple versions of the software, and having to purchase a new version of the component is not likely to win the software company a lot of friends.

Learning about external dependencies - getting information from external teams by getting on their lists

We had a huge problem around the start of the year. Our product is a greeting card application, which allows you to take your images or some standard images, add text or standard greetings, add voice which can be customized or taken from some standard greetings, and then you can convert this into a rich content greeting card that can be sent via email or via social networking. For integrating with social networking, we used the API's that were publicly made available by these platforms. We were not big enough that we could establish a direct contact with the social networking platforms, so we would just use these API's.
Near the beginning of the year, we started getting customer complaints that the product would just not work with a particular social networking site. They would try to use the product to send it, and they would get back an error that was basically saying something like: "Resource not found". This was reported on the user forums that we had for our product and once one person reported such a problem, others were able to confirm. This was good since it confirmed that it was not just a problem with one user, but also meant that people who were not using that particular feature also started feeling unhappy.
However, what really caused us a lot of problems was when one of our more technically oriented users pointed out that this could be because one of the API's that we were using was no longer in existence, it had replaced by another such API. And even worse, the user pasted the relevant notice from their technical forum where it was mentioned, pointed out the tweet where it has been pointed out, and so on. All this was repeated by more users who started making fun. How we had not bothered to keep up, how our problem was affecting a product that they were using, and whether we could finally get our thumb out and do something. Boy, was it embarrassing, and the problem was, nobody had much of sympathy for us. After all, we should have been on the ball, and should have known that the API was going to be replaced. The social networking platform had been talking about that for around 6 months now, so that people had enough time to do something.
The good news was that we could replace the API without needing to make a change in the application that users had, since the API call would in turn look at a piece of code on our website, and we were able to redirect them. It slightly decreased speed by around 5 seconds, but that was acceptable rather than try to roll out a patch to all the affected users.
Another policy was set in place as a result of this. From this point onwards, any external technology that we used was tracked in a database where we also tracked the site of the technology, we tracked all their accounts (twitter, facebook, forums, email) and once every month, we had a person assigned to review these so that if there was any notice, we could something rather than finding out later. It was good that we did so, since we ran into a possibly bigger problem later, but we were prepared and handled it so well that nobody noticed any problem.

Ensuring that there are clear agreements over deliveries from third parties

In today's world of software development, most large products use input components from a variety of sources. So, if you are building a new version of a video editing application, it tends to incorporate a large number of external components - some of these dealing with the ability of read views of different formats and codecs, then there will be the components dealing with burning what you created to a disc for which there are additional components, and so on. In all such cases, it always makes sense to use components that have a specialized function rather than try to build it yourself. In the current case, see how it difficult it would have been if you team was trying to write code to read the different video formats in existence today. You would have mostly given up trying to do such a thing. Even otherwise, there are other components that are used - if you are working for a company that has multiple applications, the company would ensure that common components are built at one place and included in the various application (this is the most efficient way of building such components); for example, you would be using a Help system, your application would be using Installers for installing the application onto the machine, you would have having a licensing system, you might be having a common system for generating the UI of the application, and so on.
Now, this sounds like  the most efficient way of building such an application. However, for somebody who has been there and done that, there are many slips between getting a robust system in place that integrates all these components in your schedule. For example, one of the biggest problems that we used to run into was the quality level of these components. We had a contract with one of our component makers who would supply us a component (and they used to supply the same component to our rivals and other applications in the video space). From time to time, we would run into problems where these components would not be delivered in time, or where we would have to reject the quality level of the component, because we found a critical bug.
Why were all these problems happening ? I am talking about a situation which used to happen a few years back, and it was extremely frustrating. However, it turned out that we had been working with them for many years, and we had never really tried to set some kind of process for these deliveries of the component and hence all the problems. So, we started out by working the timelines for when we need these components, and then did more analysis while working with the development and testing teams about the level of testing that we expected from the vendor end. Now, all this was being done from our end, and we had only aired some level of frustration with the vendor, but never really got in a problem solving discussion.
We set up a series of meetings with the vendor, talking them through what the current system was, pointed out the problems it was causing for us (and for them as well, since when we rejected a version of the component, it would have meant more effort from their end as well). We talked them through some of the solutions that we were looking at, we got our development and testing teams to have discussions with their respective teams on a regular basis. Now, this was not a magic bullet; they did not do everything that we had asked for, and in some cases, it meant that we had to pay around 10% more because of the extra effort on their side. However, in the end, we had a more strict agreement for the delivery of the component along with a quality level, and this allowed up stability in a part of our schedule, which was well worth it.