Implementing An Internal Software Development Project In A Technology Consulting Firm (aka EATING YOUR OWN DOGFOOD!)

  dog-610069_1920

 Part One

 “The task of the software development team is to engineer the illusion of simplicity” – Grady Booch

At Pinnacle, we are blessed with a population of senior technologists well versed in a multitude of modern development languages, approaches, frameworks, tools, apps and processes. Each of these elements are honed daily in the various customer environments we are actively engaged in. From time to time, we ask members of the organization to contribute to internal efforts that make life easier for all parties. We are currently in the midst of one of those times.

Like any project we perform for customers, we work with the team to understand the requirement and disseminate information and access pertinent to what we are looking to achieve. The next step is where it gets interesting. We tend to have options that more traditional businesses may not in choosing the technologies in which to construct our solution. We have partnerships with certain technology providers that minimizes our investment costs. And we have strong opinions on the most viable technology stack to use to solve this problem. In a recent LinkedIn post (http://tinyurl.com/heflt83), I wrote that one reason technology has gotten harder is due to choices and we are certainly not immune to this. This is where the combination of self-restraint, esprit de corps and the KISS (Keep it Simple, Stupid) method converge and save us from ourselves.  With our core focus on delivering for our customers, we seek to minimize both construction time and, even more importantly, support time. That leads us to technologies that allow for the consultants to learn while being ones we expect to be around and that any number of consultants could work on in a pinch.

Armed with our application requirements (Enter time from any device, anywhere that feeds our financial package and provides reports to individual consultants and administration) and our architectural directives including:

  • Reuse of existing business logic, where applicable
  • Provide opportunity for consultants to improve their knowledge
  • Utilize technology in demand in the marketplace
  • Take advantage of software provided by our partnership(s)
  • Be conscious of minimizing support requirements
  • Plan for future deployment models, which may change
  • Employ best practices
  • Minimize costs, where practical

We chose the following technology stack for our project and where we leveraged reuse:

  • Trello – Project team collaboration (Reuse)
  • Slack – Team communication and chat (Reuse)
  • CoreOS – Server VM environment (Reuse)
  • Docker – Deployment containers
  • Jenkins – Continuous Integration
  • Git-o-lite – Source code repository (Reuse)
  • Bootstrap – Mobile first responsive framework
  • React – JavasScript Framework
  • Spring Boot – Core Application environment
  • SQL Server – OLTP/Reporting environment (Reuse)
  • KeyCloak – Single Sign On toolkit

As you can see, we are mixing new technologies with our existing solutions to create an update version of our Time and Billing application. We reviewed other technologies such as SQL Server on Linux\Docker, but given it was a private beta we bypassed it. We looked at NoSQL (MongoDB) solutions briefly but our MS partnership provides us great cost benefits and significant use of SQL Server Reporting Services (SSRS) has been leveraged in the original application which would require a rewrite for minimal value.

In future posts, we will drill into the development and execution phases to provide insight and learnings from our journey.