Creating Great Solutions Efficiently Using Open Source Frameworks Augmented by Some Homegrown Glue and Standardization
SWC has always been a framework company. When I started at SWC in 1988, we had a powerful application development tool called “Fast Programming” that enabled developers to build large complex business applications very efficiently. “Fast Programming” allowed developers to deliver full featured business application rapidly without reinventing any wheels project to project.
In 1999, SWC embarked on an effort to develop tools and methodologies to build systems using Java as efficiently as we had done in the years of “Fast Programming.” The product of this effort was our Java Catalyst framework which we have now used for 15 years to deliver applications. Catalyst provides many of the same advantages that we enjoyed with “Fast Programming” including the ability to build complicated things efficiently, pre-built infrastructure elements and a standard way to build applications.
When we built Java Catalyst there were not a lot of great open source choices for full featured frameworks.
- Apache Software Foundation was founded in 1999
- The first version of Struts came out in May 2000
- The first version of Spring came out in October 2002
Everything was just getting started and we needed a solution that included a lot of out-of-the-box oomph! So we built Catalyst ourselves. The framework took advantage of some open source libraries but in large measure it is an in-house framework. Later, we built a similar .NET framework called Catalyst.net which likewise enabled us to efficiently build applications based on .Net.
Fast forward to the 201x’s and the open source world is very different. There are now several very full featured open source options for frameworks and just about anything else you would want to build. There are great online resources, such as maven repositories, stack overflow, github and many others. None of this existed 10-15 years ago. There is a large body of quality solutions to almost any problem. These solutions have been built and debugged by a large community of really smart people.
So how should an organization like SWC adapt our approach?
For the last three years we have been building Java applications using the Spring Framework and .Net Applications with MVC and entity framework. Overall this has been a very positive thing.
One thing you run into when you develop using open source is that there are choices… a lot of choices! Every problem has multiple solutions, each with pros and cons, each with a learning curve, each with potential incompatibilities with other choices you have made. On top of the choices, there are gaps. Capabilities that SWC had solutions for in our own frameworks that either do not exist or are implemented in a way that requires more time and effort than we are used to. SWC, as a software development team that creates many distinct unrelated custom solutions, cannot afford to figure out this labyrinth of options and challenges every time we start a new project.
There is a solution to these challenges. We can build something that allows each new project to benefit from what was learned and built on in previous projects. In the past we just built all of the upgrades into our internal frameworks. With open source, it is similar but there are differences. We can build IP, but now we must work inside the context of the framework that we do not control. Using these frameworks, we have built base libraries to reduce/eliminate code that is redundant from project to project. These libraries will evolve similarly to how our frameworks to in-house did, improving from project to project. We also are standardizing on a set of open source libraries to be used. This reduces effort spent on project startup and configuration. This will not be a static set of libraries. We will tend to stick to tried and true component choices until there is a need to try new options. Libraries that prove to provide advantages will be added to our standard offering. Project standardization and rapid project setup is being accomplished by template and archetype projects. This means that when a new SWC project is started it will automatically be configured with the standard SWC IP pieces and the open source libraries we have standardized.
This approach of selecting the best open source options, adding IP of our own to fill gaps, providing base solutions needed by all projects, and creating standard project templates and archetypes is enabling SWC to create systems using open source technologies with the efficiencies we enjoyed with our in-house frameworks. Building better systems for our clients at a reduced cost.
Let’s Build Some Cool Stuff Together
Watch our video below to learn more about SWC’s custom application development capabilities.
RELATED PAST POSTS
If you enjoyed this post from Bob, please check out a few of our past related posts:
Ask SWC: When It Comes To Custom Application Development What Sets SWC Apart From The Competition?
SWC Video Featuring Custom Application Development Services
Compete: How Developing a Solution for the Salesforce.com AppExchange Launched a New Company