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
28 June, 2024

Earlier this week, I was talking to one of our prospects – large industrial company that was looking for a...

8 August, 2013

Cloud is going mainstream these days. It happens everywhere. It is hard to find a company or business today that...

13 January, 2024

In my earlier article How to bridge PLM and ERP Systems To Support Modern Product Development and Digital Thread I...

14 July, 2010

My new website and blog is BeyondPLM. The original post is here. Social is trending these days. We can see...

27 February, 2018

The last article inspired by presentations and discussions at PI PLMx last week is about integration and collaboration. That was...

2 July, 2014

One of the companies I’m following on regular basis is Aras Corp. and its Aras Innovator product. Aras represents an...

25 July, 2010

Data management is boring. Data, Numbers, Tables… Even, if I completely disagree, I guess lots of people think so. Nevertheless, even...

27 November, 2011

The announcement made by Dassault System last week, made me think about a huge distance CAD industry passed for the...

30 May, 2013

Enterprise software sucks. How many times we’ve heard that for the last 5 years? Probably too many… I remember one...

Blogroll

To the top