If I was going to bet on the success or failure of an IT project, the first thing I’d want to look at is the roll out plan. Are they planning a “Big Bang” rollout, maybe with a data migration? If so, that means they are planning on developing, testing and deploying an application all while retraining everyone in the organization to use it, adjusting and replacing legacy processes and legacy workflows. If that is the plan, then I’d put that project in the high probability for failure category for sure. Now if the fact that they call these “Big Bang” deployments doesn’t already scare you, then maybe you’ve heard a few of these ideas thrown out before when trying to work with your own Big Bang project rollouts. How about, “use a duplicate entry system until everyone is up to speed on the new software”, or maybe “Let’s make sure we roll this out off hours or on the weekend so we have time to debug any issues” or my personal favorite “do we still need this database?”, “I don’t know turn it off and see if anyone complains” while cleaning up the pieces after a “successful roll out”.
If you are stuck in a situation like this, having to flip the switch for everyone all at once, it’s usually because you have some off the shelf or proprietary cloud based solution that doesn’t give you any other option. Maybe it’s because it’s too expensive to roll out slowly while maintaining the old system, or you just don’t have a team big enough to maintain legacy and handle a progressive rollout of a new one. Or because of budget cycles or poor planning, you have a timeline you have to keep and “big bang” is the only way out. Either way there is a simpler and frankly better solution. It starts with understanding the lifecycle of your software, and planning for ways to extend it, patch it, or slowly roll out a replacement. Once you get a handle on your actual life cycle, then you need to start accepting that open source software and a strong internal team is not only possible for your IT organization, it’s what’s going to save it, and you, a lot of time, money and headaches. It all starts with these 3 main components.
Iterative development and deployments
Piloted and phased functionality roll outs
Open source software standards and processes
Let’s start with your development team. Iterative processes are fairly familiar to most people these days. Agile has become a real buzzword, but the truth of the matter is that most software developers have been doing this for years, but haven’t been able to get business units to follow and understand. This may be more about trusting your IT department then anything else, but it’s also about understanding that changing processes doesn’t mean you throw everything out, it’s about slow evolutionary steps, and empowering your team. It sounds hard, but it really doesn’t have to be, and once you start this step, hiring the talent and support you need internally will be easier than ever because you will have the tools, process and practices that modern developers are looking to use.
Agile coaches may tell you differently, that you have to follow these strict rules and do very specific Kanban, or Scrum processes, but what you really need to do is break down the work into logical business functionality, and then focus on building that functionality while following a framework for the entire application. It’s less like building a house (the popular metaphor) and more like planning a four course meal, or writing a song. You have to break it down into individual parts and work on each part individually, with a different team member focused on each. Once you have those pieces working, you can then test them with the other pieces at logical stopping points to make sure things are harmonized and working together. You make the process work for you and your team, and more importantly you release the working software early and often to get feedback from the user as soon as possible, because if they don’t like it, you are not going to like it either. The best part is, that now that you have these teams working on individual sections and a Product Owner harmonizing the process, cloud native architectures and open source components or service driven tools like Docker and Kubernetes make it even easier then ever to build this functionality without interfering with the work of others, test and deploy it and most importantly, have the opportunity to reuse it in other applications. More on that later.
So let’s assume you have your team onboard and they have their version of iterative development all worked out and are ready to get started. Should we let them start building a brand new ERP system and replace the entirety of our SAP or Oracle solution, and save hundreds of thousands of dollars a year? No, sorry not going to happen, at least not yet. What we can do though is pilot some new functionality, or get a replacement up and running of something that has not been working or isn’t as customizable to your workflow the way you need it to be. We love our big hulking enterprise systems and we can’t afford to retrain everyone all at once, much less wait for our internal team to develop all of that functionality, so we start small and work on a quick value add or some crucial missing features to demonstrate to the organization that we can bring value and do it fast. Then after we have done that, we grow into the next phase of replacing an expensive module with a custom solution built from open source components and we build organizational trust in the team and the process as we get buy off to work on even more. I hate the term quick wins but that’s what we look for here.
The last piece of the puzzle after the pilot phase is the thing that gets us rolling out new and better software faster than ever, is setting up our own internal component library or marketplace, built on open standards and using containers and a docker registry to do it. An example is when using the Buildly Core (shameless plug) you can develop a component for your application that allows you to upload a document to a central file server, or a cloud based document management system. You can put this in a docker container, write it in python, java or whatever you want, and then upload the container to your registry and reuse that service in any other application. If you build a REST service on top of it and use Swagger (an open standard for API modeling and documenting) it can even connect to our Buildly data mesh and seamlessly connect it into a single interface for cross-service query aggregation and use by Front End developers. Point being that if you use these simple open source tools and standards, the reusability and testability of your code goes through the roof, and your delivering on deadlines faster than ever.
Now you can hear it, the overwhelming praise of those other business units has gone from a rumble to roar as they look to the internal development teams to fix these problems, and the team grows as you add more open source contractors and team members so you can build out your library of modules, save more money and keep delivering on mission critical applications faster than ever. Your supplementing your slow moving massive systems with modern functionality. Your hiring talented internal developers and IT staff because they want to work on these cutting edge systems and have seen your open source contributions to the community. Maybe someday we can even replace that big expensive ERP system with an open source equivalent, now that we have organizational buy in, or even build it out piece by piece internally. It’s your system now, you have control and a massive community of open source developers supporting you.
