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
16 April, 2012

I was very busy since last Thursday. As you probably know, I was attended COFES 2012. It took all my time...

13 April, 2017

While PLM research and analytic companies are running cloud PLM surveys to understand what causes slow cloud PLM adoption, manufacturing industry...

12 February, 2010

Recent SolidWorks World Event brought a significant splash of discussion about cloud based applications. It is interesting to see different...

3 October, 2017

Blockchain is one of these technologies that very much misunderstood by enterprise, but it has a potential. If you want...

24 December, 2015

Dear Friends, The Holiday season is an opportunity to reflect on both the past and the New Year ahead. It...

15 December, 2017

For many years, to have CAD system installed on a very powerful workstation was the only option to design something...

23 June, 2015

My earlier attempt to compare PLM vendors and cloud services raised many comments online and offline. I want to thank everybody who...

8 May, 2015

Traditional manufacturing companies are associated with large manufacturing facilities, manufacturing equipment and significant initial investment to take business off the...

30 July, 2009

There are numerous ways in which people changed way they communicate for the last decades. Email is definitely one of...

Blogroll

To the top