Most of the times, I use to wonder why Enterprise Business Applications (EBAs) development does not follow the “Rules of Product Development” even though EBA too has some kind of revenue model associated to it like in the product domain business. When I say EBA, I am not referring to the typical enterprise back office applications like HRMS, Payroll, CRM, etc which are more segmented into the world of “cost centric applications” but pointing more to the applications that either directly/ indirectly contribute to the enterprise’s revenue or that have some kind of B2B interfacing.

A typical “EBA Platform” we are referring to can be a B2B solution like Benefits Administration Systems or Financial Brokerage Site or Automated Payment Processing Engine which is not a product that is sold over web or CD, but a platform through which services are sold. Hence, the organization’s bread & butter comes from the revenue generated directly/ indirectly from these “Hosted Solutions’ Platforms” and we call these platforms as Enterprise Business Applications (EBAs).

It would be interesting to see what happens when “Product Engineering Principles” are introduced to EBA development world because even these kind of applications (EBAs) have to be “user generic” but still “domain specific” and they have the need or duty to cater to the rigors of non-functional requirements such as performance, scalability, availability, security, etc. Nowadays we can see a trend where we refer or term EBA kind of development as “Platform Development” rather than application development; because psychologically we are trying to bring the product development mind set to the teams and also ensure the teams understand the revenue model behind these “platforms”.

Before getting into what kind of product engineering principles are needed for EBA development, let’s check on some of the reasons why these EBAs demand product engineering principles. There are many instances where we start developing these EBAs as “general applications” thinking there are only “known set of end users and specific requirements to meet” and we forget that these EBAs are directly mapped to the enterprise’s business growth strategy and that they should be proactively architected for meeting the business goals for the next 5-7 years. Also some of the performance goals related to user growth and increasing volume of data can be given a “miss” which may slowdown the enterprise’s business growth drastically. This is where product engineering becomes essential for successful development of EBA and in the next blog we can have a look at how product engineering principles that cater to EBA development can help the organisation achieve its business goals.