Technology as an enabler, not an inhibitor.

Software Solutioning does not have to be complicated, unless you want it to be. We focus on simple solutions that mesh and are often easy to maintain. We build simplified solutions that do not over exaggerate the needs of the problem being solved. There are many examples of complex, multi-tiered, convoluted software solutions involving databases, middleware, EJBs, Business Objects etc. Not all architectural components are essential for all business problems.

Does a standard, run of the mill, IT modernization project intimidate you?

It should. Because it is. Standard technology landscapes and architecture are the bane of IT managers and keeps maintenance teams awake at night. This comes from decisions made and strategies adopted where simplicity and agility were not the primary drivers. Software development and the solutions that come out of an Information Technology investment are all well-intentioned but over time tend to lead to incoherent solutions that need mountains of resources and additional capital to upgrade and maintain. Often these systems are built over time by disparate vendors who add a little bit to the ever-growing list of “stacks” in a software solutions package. Why does it lead to failure? Because the resources needed to maintain these systems often outpace the capacity of organizations to finance the reduction of technical debt. What is technical debt, you ask? It is simply the list of improvements or corrections needed to optimize a software solution over a period of time. Without this optimization, software will simply become non-functional.

Who is to blame for all this? The CTO? The Project Manager? The Lead Tester? Maybe all of them, but the primary blame rests ultimately with the vendor for their choice of the methodology used to deliver the solution. Development teams often focus on building a large solution to solve a small problem. This is because software frameworks were inherently designed to fit a wide array of customer requirements. A framework that has the capability to send a rocket to the moon can also be used to build an inventory management system for an automotive dealer – but it does not have to be done that way. This is because the complexity needed to launch something into orbit does not compare in the real world to the complexity needed to move a carburetor from inventory to the shopfloor.

What do we do differently?

Go small and build up from there iteratively. An inventory management system does not need a J2EE-based solution with Hibernate, Spring, JSF, JavaScript/CSS all hanging off a JBOSS server with Redshift on an AWS cloud. (You don’t have to know what any of those terms mean!) We build our solutions using low code. Low code applications are built primarily using declarative coding practices where the software developer spends the bulk of their time, not focusing on the technology challenges, but on business needs of the customer.

How can a software development team spend more time concentrated on the customer’s requirements? Because low code platforms, while very sophisticated, abstract this complexity away from developers to allow them to turn around functionality faster than all other existing software development frameworks. Also, this gives customers the resources to invest in better software platforms than otherwise possible. If a customer must spend 167K per year on a junior Software Developer to turn around some mediocre screens and reports, how much will be spent on hardware and software acquisition? This is why many IT shops will try to convince customers to buy open source – so that they can keep their overall cost within the customer’s perceived comfort level. And while many open-source solutions are very good choices, they often come with steep costs later on, such as help desk support and maintenance that customers often do not anticipate or budget for.

Why is low code the way to go?

Since low code applications can be developed with a very short turnaround time, it is easy to iteratively develop solutions for customers that they can actually see, feel, engage with and critique. In our experience modules such as a faceted search screen, for example, that takes well over 100 man hours to build in a Spring based J2EE solution using Hibernate to communicate with an RDBMS or Apache Solr data repository, can be built with low-code platforms in a matter of minutes. This speed and the strength of the SAFe® agile process implementations will give customers the best of both worlds in the software industry – cost savings and iterative feedback.

We follow the SAFe® agile methodology for our software development process simply because it works. We’ve used Waterfall, IBM’s Rational Unified Process (RUP), traditional Agile and now finally SAFe®. It is the best possible process improvement we have made. Also, throw in the added benefit of SAFe® working well with low code platforms. Both these ideas were conceived in different environments, but they behave just like newly-wed couples – like they were always made for each other. Who knows? Maybe they were.

What SAFe® brings to the table is a structured way to perform iterative software development without interrupting the natural flow of innovation. The customer provides their requirements which are maintained by the team as a backlog of work items. These are continuously fed to DevOps teams who in turn build solutions. These solutions are iteratively built every two weeks called sprints and reviewed by customers at the end of two weeks. This iterative development pattern ensures the customer has a 100% stake and insight into the decisions taken to develop the end product. It is a win-win for both the customer and the DevOps team. This repeatable feedback loop also ensures that there are no surprises at the conclusion of the development phase of the project. At the end of a sprint, the circle is repeated again. A set of 6 sprints (roughly 3 months) are classified into a Program Increment, PI for short. The DevOps team plans for each PI in conjunction with the customer.

While the DevOps team implements customer functionality in each PI, they are concurrently identifying and prioritizing the architectural runway to account for future development work, code improvements, scaling infrastructure etc. This process ensures the business is insulated with an additional layer of protection and the delivery pipeline comprising of software solutions are continually being delivered on a pre-determined schedule.