Building Solutions Around Open Source Software

Building Solutions Around Open Source Software

There are of course numerous advantages of using open source software and to be fair there are some real risks too. But one huge advantage of using open source software is the ability to easily create integrated workflows between multiple best of breed parts to a solution –  even when some of those parts aren’t open source.

Earlier I wrote about using WordPress and Laravel to provide a custom interface to use data external to WordPress. Integration between applications is nothing new. There are very few enterprise scenarios where there isn’t some kind of need to integrate between applications. I usually rely on one or more open software frameworks or applications to provide the glue needed to facilitate such integration.

Sometimes complex integration is needed because different business units chose different critical line of business vendors but now need to share data. Or two companies merging operations need to exchange data and collaborate on workflows. These after the fact integration requirements have built many consulting practices and I have done more than my share of them.

But today almost all of the integration requirements I see come from deliberate choices of software to meet specific needs a customer has. For example, I currently have a project with a client who is a long time Blackbaud customer. They use both Raiser’s Edge and Financial Edge and were hosting them on their own servers in their building. In addition, they had a website built using ASP.NET and tightly integrated with Raiser’s Edge. Some of this integration was through the documented Raiser’s Edge API and other was via direct manipulation of data in the Microsoft SQLServer database tables. They also had a number of Access DB applications managing data in Microsoft SQLServer and integrated with Raiser’s Edge.

Their servers were reaching their end of life and instead of replacing them they wanted to move to the cloud. They decided to use Blackbaud’s hosted offering and step up to Raiser’s Edge NXT and Financial Edge NXT. The Access DB applications were replaced with a Laravel based web application to manage their legacy data and a new primary web site built using WordPress.

The only non-open source application or framework in this mix is from Blackbaud and fortunately they have a good API I use whenever we need to access the Raiser’s Edge data. The new WordPress based web site handles member signups, billing and renewals. The information from those transactions are periodically gathered, parsed and sent to Raiser’s Edge via their SKY API. The web application built using Laravel uses the same SKY API to read information from Raiser’s Edge as needed to manage the legacy data. All of the legacy data is still stored in Microsoft SQLServer and while WordPress could be forced to consume it directly via a custom plug-in, it would be overly complex.

To handle accessing and displaying the Microsoft SQLServer based data in WordPress I wrote a simple plugin to interact with an API I built using Laravel. In most use cases search data and authentication tokens are sent to the API and it returns a fragment of HTML which WordPress then verifies and displays to the user. This very lean WordPress plugin I wrote supports short codes to embed in a WordPress page or post and make the appropriate calls to the Laravel based API when activated. It will be very easy to maintain should a conflict arise from WordPress updates. These conflicts are unlikely since there is nothing unusual about the plugin and it doesn’t use any behind the scenes magic to bypass WordPress.

Similarly, the API built around Laravel is also easy to maintain and secure. Because the returned HTML is built from standard Laravel views all of the styling on the WordPress side is applied and the look and feel is seamless. From the perspective of the user everything is happening completely within WordPress.

I get a great deal of satisfaction from solving complex problems in the simplest manner possible. I am always looking to refactor my code to reduce complexity and ease future maintenance. Early in my career I was given some excellent advice. I don’t remember who first said it to me but I have always tried to live by it.

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.


Even though I am usually the one maintaining my earlier code it still reminds me to take the little bit of extra time to make everything painfully obvious and comment not just to eliminate confusion but to give context to any complex choices or trade-offs made during development.

I am always grateful when I return my code months or years later to make some adjustment or fix some bug. And it has happened often enough to constantly remind me to simplify when possible, and document like an investigator when it isn’t. The irony is by focusing on simplicity much of the documentation anyone coming after me needs often comes from the code itself.

Close Menu