.webp)
McKesson's Lease and Portfolio System Shows What's True Today. Getting Historical Answers Required Building Its Own API Pipeline.
Drew DePriest is the Director of Real Estate Operations Technology at McKesson, a Fortune 10 company responsible for one-third of the daily pharmaceutical supply in the US. DePriest is responsible for managing real estate lease and portfolio data. Every couple of months, someone from a business unit asks the same type of question: How has the number of my distribution centers changed over the last year? What did my pharmaceutical divisionās footprint look like three months ago?
The platform that should answer those questions canāt. Corporate real estate systems of record are built to show the current state: every property, its lease information, critical dates, rent, and geographic metadata. These systems are not built to store historical data. So DePriestās team built the infrastructure itself. On a monthly basis, code blocks fire API calls to the system, pull all columns, and push the snapshot into a data warehouse. Over time, those monthly snapshots become the historical record that the system never kept.
What makes the pipeline reliable is the quality of the API at the other end. DePriest has spent 15 years building and consuming integrations and has a clear view of what separates a workable API from an expensive one. DePriest proposed the question of what makes an API good or bad to his community of experts. Poor documentation was identified as the most common failure point. If a developer canāt find a publicly accessible page showing what data is available, its format, and its data types, thereās no foundation to build on. Inconsistent data formats are the next problem: a field that returns a number in one call and a string in another breaks everything downstream. For an enterprise like McKesson, a sandbox or lower testing environment is non-negotiable before anything touches production.
.webp)
DePriestās benchmark for what good looks like is Twilio, a communications platform that published its full open API and swagger spec on GitHub, free to all, covering every endpoint, with code samples showing exactly what a call returns. Postman templates let developers test in a sandbox before writing a single line of production code. That level of transparency makes integration predictable rather than expensive.
The other risk is treating an integration as a finished project. A well-documented integration can still cost as much to fix as it did to build if the vendor changes the API laterā¦ and vendors always change their APIs. DePriestās framing: treat APIs like products, with version control and ongoing governance. Not set-and-forget.
ā
Register for the next Nexus Labs event.
Sign up for the newsletter to get 5 stories like this per week:
Drew DePriest is the Director of Real Estate Operations Technology at McKesson, a Fortune 10 company responsible for one-third of the daily pharmaceutical supply in the US. DePriest is responsible for managing real estate lease and portfolio data. Every couple of months, someone from a business unit asks the same type of question: How has the number of my distribution centers changed over the last year? What did my pharmaceutical divisionās footprint look like three months ago?
The platform that should answer those questions canāt. Corporate real estate systems of record are built to show the current state: every property, its lease information, critical dates, rent, and geographic metadata. These systems are not built to store historical data. So DePriestās team built the infrastructure itself. On a monthly basis, code blocks fire API calls to the system, pull all columns, and push the snapshot into a data warehouse. Over time, those monthly snapshots become the historical record that the system never kept.
What makes the pipeline reliable is the quality of the API at the other end. DePriest has spent 15 years building and consuming integrations and has a clear view of what separates a workable API from an expensive one. DePriest proposed the question of what makes an API good or bad to his community of experts. Poor documentation was identified as the most common failure point. If a developer canāt find a publicly accessible page showing what data is available, its format, and its data types, thereās no foundation to build on. Inconsistent data formats are the next problem: a field that returns a number in one call and a string in another breaks everything downstream. For an enterprise like McKesson, a sandbox or lower testing environment is non-negotiable before anything touches production.
DePriestās benchmark for what good looks like is Twilio, a communications platform that published its full open API and swagger spec on GitHub, free to all, covering every endpoint, with code samples showing exactly what a call returns. Postman templates let developers test in a sandbox before writing a single line of production code. That level of transparency makes integration predictable rather than expensive.
The other risk is treating an integration as a finished project. A well-documented integration can still cost as much to fix as it did to build if the vendor changes the API laterā¦ and vendors always change their APIs. DePriestās framing: treat APIs like products, with version control and ongoing governance. Not set-and-forget.
ā
Register for the next Nexus Labs event.
Sign up for the newsletter to get 5 stories like this per week:
This is a great piece!
I agree.