Why Product Development today needs a Product Engineering Platform?

[Note: I seem to be landing up on many of my articles which I had written in my pre-blogging days. Few weeks back I had posted another one titled “QA Tester vs. QA Engineer vs. QA Architect“. Once again, rather than having it cold-stored on my file system, I am posting it here with the hope that it might be useful to the wider community.

As a background on this article – this was written when me and my team were in process of conceptualizing the need for an integrated engineering platform in GlobalLogic because of the increasingly different product development landscape today. The motivations and need listed in this article finally resulted in the evolution of what today is referred to as GlobalLogic Velocity. It also won the “InfoWorld Top 100 Innovation Award” for the year 2007]

Main Motivation – Art of Product Engineering Today

There is no doubt today that teams are becoming increasingly distributed. Also the art of building products is rapidly changing now, more than ever in the new world of Web 2.0 or SOA. Product Development is now less upfront and more emergent. Requirements are driven more driven by Black-board, IM, or Wire Frames. Product Development today needs to be more collaborative and collective. The testing process for products is more continuous rather than at the end of the cycle with the practice of Test Driven Development. End users have also started playing a key role in this testing process. Table below provides a quick comparison of how the art of building software products has changed. As tough as it is to practice this in a uni-location team, complexity is much higher in a distributed team.

Then Now
Primary Collaboration Mechanism Mails, face-to-face, one way media (documents, etc.) Web, Sticky Notes, Wiki, IM, Black Board, Wire Frames
Source of Innovation Industry Technology Leaders Users, Customers
Release Cycle Months, Years Weeks, On Demand
Feedback Mechanism Market Research, Surveys, User Group Study, Customer Support Online, Continuous, Community Contribution
Customer Engagement Style Controlled, well-defined Spontaneous, Chaotic
Development Process Upfront design Less upfront, more emergent
Product Architecture Closed, Grounds Up Open, Built to extend, Reuse
Product Development Culture Centralized, Departmentalized, Linear Approach, Individual Heroics Distributed, Highly Collaborative and Collective, Partnership-based
Product Testing Internal, Dedicated Test Teams, Ownership-based, End of Life Cycle Continuous, Test Driven Development, Users as testers
Development Tools Heavy enterprise oriented, expensive, complex. Lightweight, Simple, Free, fast.
Product Engineering Art – Then and Now

One of the thing which becomes clear from the above comparison is that product development is just not about core product knowledge, but also about about understanding the design and the product engineering processes. The different phases of a lifecycle engineering are becoming increasingly more collaborative and knowledge intensive. Thus a product representation must convey additional information/knowledge that answers not only “what” question about a product engineering but also “how” and “with what” questions.

Product and Stakeholders Dynamics in an Organization

Another factor which governs the product development is the way internal department structures are modeled within the organization. Typically there is a Product Management group which interacts with the end customers and prioritizes the business requirements based on the market needs. Program Management has the responsibility of prioritizing these requirements internally along with the roles and responsibilities. Program Management also needs to bridge the gap which typically exists between the business side and the technical side. Product Development Management then takes the requirements and converts that into a working software. Quite occasionally, organizations also have Product Delivery Group which is finally responsible for delivering the software to its users. Figure below represents such dynamics within a product organization
Product & Stakeholder Dynamics in an Organization

Product & Stakeholder Dynamics in an Organization

While the distribution of product development work across departments helps in work categorization, it is also important for Management to have one view of the state of product development. This becomes much more complex when the entire product development is spread across geographies or time zones. Hence there is a need for an efficient integrated platform which aids the complete life cycle of the product.

Any Product Engineering Platform should be an integrated set of applications, systems, repositories and tools used by Software Product Engineering teams which would facilitate –

  • Integration of technology/applications
  • Integration of the business/engineering processes
  • Integration of information and knowledge
  • Integration of people and organizations units
Any Product Engineering Platform (including ours) should be able to facilitate the above characteristics.

[Note – Partial credits to the table titled “Product Engineering Art – Then and Now” mentioned above goes to an article which I had read on the internet. Unfortunately I am not able to locate or find the reference to it now and the old link has now disappeared too. If anyone has any reference to the same, would be great if you could point it out.]

Tags: , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: