A blog by Oleg Shilovitsky
Information & Comments about Engineering and Manufacturing Software

Dogfooding and PLM APIs random thoughts

Dogfooding and PLM APIs random thoughts
Oleg
Oleg
13 November, 2012 | 3 min for reading

If you are long time enough in software business you should be familiar with the term “dogfooding” (or eat your own dog food). This term used to explain the situation or scenario in which company is using their own products to demonstrate their capabilities and quality. If you are not familiar with this process, navigate to the following Wikipedia article to read more. I liked some examples there, specifically, Apple one, which I wasn’t aware about –

Apple Computer president Michael Scott in 1980 wrote a memo announcing that “EFFECTIVE IMMEDIATELY!! NO MORE TYPEWRITERS ARE TO BE PURCHASED, LEASED, etc., etc.” by the computer company, with a goal to eliminate typewriters by 1 January 1981.[9]

The following passage brings few more examples:

One perceived advantage beyond marketing is that dogfooding allows employees to test their company’s products in real-life scenarios,[3][5] and gives management a sense of how the product will be used, all before launch to consumers.[5] In software development, the practice of dogfooding with build branches, private (or buddy) builds, and private testing can allow several validation passes before the code is integrated with the normal daily builds. The practice leads to more stable builds[citation needed], and proactive resolution of potential inconsistency and dependency issues, especially when several developers or teams work on the same product. For example, Microsoft and Google emphasize the internal use of their own software products[citation needed]. For Microsoft, especially during the development stage, all employees across the corporation have access to daily Software builds of most products in development, including the Windows operating system.[citation needed]

Today, I want to speak about specific “dogfooding”, which is related to PDM/PLM APIs or (Application Programming Interfaces). In the world of PLM implementations, the role of Open API becomes very important. Usually, when I’m working with customer requirements, I can see the following notes – external programming or customization as a way to resolve features or function absence available in the product. Yesterday, I had a chance to read the following TechCrunch article – 5 Rules for API Management. Even if you are not programmer or software engineer, have a read and make your opinion.

The article made me think of the complexity of API delivery in PDM/PLM as well as about “lifecycle”. The latest is important – PDM/PLM products live very long period of time, and the development of stable APIs is a separate and almost “must have” a prerequisite.  The 5 rules – design, documentation, analytics, universal access and uptime made a perfect sense to me. I found interesting note about the relationships between IT and business group (which is also very typical for many PDM/PLM implementations):

Enterprise API Management must include the entire Enterprise, not just the techies in IT. The SOA solution, and the other gateways as well, is focused on the IT person and not the business owner of the API program. This is reflected in the UI that they present in their free version as well as their language that includes things like “policies”; too much of the business rules are codified in complex policies that require a technical expert to really use.

However, I found the notion of analytics, mostly interesting, since it can address the idea and requirements of API management through the lifecycle of the product. Here is the passage to think about:

[how to] think about the collection and processing of all the statistics associated with the use of the API, with an eye toward supporting and encouraging effective usage and discouraging/limiting usage that is counter to your business or technology goals.

What is my conclusion? The days of single PLM platforms are almost gone. The future belongs to Networks. Data networks, product and cloud services networks. The ability to adapt a product to customer needs, to continue product development in a fast-changing customer environment and strategic goal for cloud, deployment set new goals in front of PDM / PLM developers. The importance of having agile and flexible API that can sustain many product releases and development cycles was never as important as of today. Just my thoughts…

Best, Oleg

Image is courtesy of TechCrunch article (Feature image courtesy of XPlane – under Creative Commons.)

Recent Posts

Also on BeyondPLM

4 6
9 August, 2016

Have you heard about “digital thread”? If not, you probably should, because it might become the next point of debates...

7 January, 2010

For the long period of time CAD/CAE/PDM/PLM were recognized as tools for product development and manufacturing. However, modern trends, moving...

22 June, 2024

In the world of engineering and manufacturing, data integration is paramount. As industries evolve towards more interconnected systems, choosing the...

2 November, 2016

I’m heading up to Detroit to attend CIMdata PLM Roadmap for Global Automotive Industry and their Supply Chain Partners. Navigate...

6 October, 2016

Cloud technologies and applications are trending. Just few years ago the most of cloud PLM debates were about “cloud vs....

8 April, 2009

  Everything in our life is seems to be a project. It can start from a very simple set of...

2 January, 2018

  Dear Friends, 2017 was an important, challenging and successful year for me. As we move into 2018, I wanted...

25 November, 2013

Collaboration is still one of the hot topics in PLM space. I was watching PLM TV report about Dassault’s 3DEXPERIENCE...

19 October, 2019

Imagine you made a choice for what PLM system to use in your company? The process was long, you run...

Blogroll

To the top