September 21, 2020
Listen to this articleInnovation in business workflows and technologies has been a fixture of advanced business practice. But, before going all-in for the latest technological implementation, chasing a new-fangled acronym, it helps to stand back and reassess the quantum of improvement you’d eventually get. An even deeper analysis is needed to figure out whether a business needs new developments from the ground up or merely an enhancement of existing structures and features.
The cardinal rule of “If it ain’t broke, don’t fix it” applies to platform development too.
That said, Greenfield and Brownfield development have some pronounced differences that make them stand apart. While working on a Greenfield approach, you’ll see the benefits of starting on a clean slate, addressing deep-rooted issues, and following the best practices of development and implementation. On the other hand, following the Brownfield approach has its own benefits, like a step-by-step approach, faster implementation, the need for fewer resources, and less business change impact.
For businesses, customer satisfaction and relations take precedence. And lest we forget, it’s Salesforce’s ability to bring customers closer and enhance customer relationship management that’s made it the most sought-after CRM in the market. Its numerous features compel organizations to explore various implementation options. Depending upon the complexity and needs of business operations and allowing for overlap, users broadly lean toward either Greenfield or Brownfield implementations. To commit to a side, they’ll need a look at their bases of distinction, some of which are as enumerated
Greenfield implementation with words like ‘transformation’ or ‘innovation’. It’s because Greenfield is all about building a new project from scratch. In platform terms, this could mean getting rid of the existing system or platform and planting a Salesforce Org in its place. In contrast, Brownfield implementations are all about building on top of existing platforms and getting them to communicate with new ones. The approach extends older business processes and capabilities and depends on workarounds, refactoring & middleware. Schema extensions are a good example of this. You could extend them pretty much anyway by adding custom objects, lookup relationships, master-detail relationships, and all custom fields (except Geolocation) through Schema builder.
Yet another example of a Brownfield project is the existing AppExchange apps. Its collaboration with customers doesn’t end with a launch as a managed package. To meet customers’ ever-changing needs, the app’s existing functionalities are redefined over and over to work well with changes made to Salesforce with each release.
In Greenfield, time constraints are more relaxed and come with no limitations to working with existing systems or infrastructure. Everything starts from afresh and demands more time investment in comparison to Brownfield. Development is also accelerated using updated code libraries that tend to be compatible with other technology from the time out of the box. When it comes to a Brownfield approach, the Salesforce implementation or development project takes comparatively little time as teams tend to have everything set up beforehand.
But this, too, could change if the modification being pushed is a major update. Major updates could take even longer if they’re based on new technology that really qualifies as Greenfield.
Greenfield approach provides enough scope for customization to achieve desired results out of Salesforce CRM. Without any limitation of previous architecture, the process can be initiated in the desired direction and tailored based on business requirements.
But the Brownfield approach holds a few limitations in terms of customization capability. Developers are bound to work with existing codes and architecture. And considering the capacity of in-use features, customization is done.
Coming to code usage, the Greenfield approach isn’t at all tied down to legacy code restrictions and leaves no room for code reusability within Salesforce. Like when metadata is in managed packages, there’s limited changeability, or you may not be able to make any changes at all. Also, the codes are private, and any modification is not at all possible.
On the other hand, the brownfield approach fosters code reusability within Salesforce. To redefine the program’s functionality and enable the speedy completion of a wide range of tasks, Salesforce’s existing codebase is taken into consideration. Like in unmanaged packages, even once the metadata is installed into production, the codes are visible, and you can still make changes related to an app. Further, Salesforce’s modular architecture allows you to reap add-on functionalities at an extra cost to basic offerings. You can pay only for the functionalities of your business.
A Greenfield approach works on the principle of a new beginning. It demands new implementation, development, code creation, etc., which drives up overall Salesforce Appexchange development costs.
Brownfield approach demands working on the existing infrastructure, code reusability, and extending capabilities of already in-use features. Thus, the usage of existing components leads to a reduction in the cost incurred in redefining a business process.
The scope for scale in Greenfield solutions is much wider since initiated development from scratch creates enough room for scaling up the process. In a scalable business process, it becomes easier to meet the extensive demands of users when needed. But that’s nothing to say of the compatibility issues that bottleneck Greenfield systems when they eventually need to interact with legacy systems. Even new processes demand additional and qualified resources to deal with transformed workflows, which further affects the management of the Salesforce Cloud.
While with Brownfield, limitations are tied to the original structure. Their support for scalability is limited but completely backward-compatible. Building on legacy systems translates to easy user adoption and compatibility. This familiarity also helps with the easy management and administration of Salesforce clouds.
Completely new implementations and development are more prone to risks due to unconfirmed business processes. New experiments come with new challenges, so fresh implementations are more likely to come with undetected, counterintuitive risks that could snowball under the hood and may surface when it’s only too late.
Compared to that, the ‘known’ issues that come with Brownfield projects look like a blessing, but the scenario is different. They are built on a stable infrastructure that is already in use. Hence, such projects are less prone to risks.
Greenfield and Brownfield are both crucial approaches for businesses and come with distinctive benefits and serious limits. Where Greenfield aids extended innovation capacities and scalability, Brownfield systems involve less risk and less investment. It depends on one where a firm is in its journey as a business.
