The Cure for Chaos: Is DIY Worth the Time, Effort and Risk?

Now more than ever, the marketplace is flooded with tools that can support, automate, and/or analyze practically any aspect of your application lifecycle. Many of these tools are widely adopted and open source (read: common and free). Does common mean best-of-breed? Is stringing together free (often unsupported) open source solutions a prudent strategy for managing enterprise applications?

Should you DIY?

In this blog, Randall K. Harp, Roundtable Software Engineer, and Jaclyn Barnard, Roundtable Director of Business Development, highlight several key considerations that can help you decide if a do-it-yourself strategy is the best bet for your team.

A total approach

As they say in IT, “The nice thing about standards is that there are so many to choose from.” Therein lies the problem. The number of choices – what they are, how they work, how they are to be implemented, integrated, managed, and controlled – can be overwhelming.

When it comes to managing the development of your Progress OpenEdge application, there are several choices available, each offering a specialized (often very specific) contribution to the larger effort as a whole. Finding the best-of-breed for each part/function can be challenging enough. Stitching them together into a complete system is another challenge altogether.

For decades, Progress has provided a comprehensive toolset for creating world-class enterprise applications, beginning with a programming language and relational database and expanding to adapt to new industry trends and standards. Today’s OpenEdge toolset includes various components that play well together for developing modern and robust distributed applications. While the toolset for creating applications is well established, how teams define their development process and the tool(s) they use to support them is left to their discretion.

A total approach not only includes moving changes through defined stages of a software development lifecycle – such as unit testing, system validation, and production – but also the management of the digital assets themselves with version control and deployment packaging of both code and database schema changes to the end users. One might consider acquiring these functionalities through various third-party offerings.

This Software Configuration Management (SCM) introduction presented by Aneesh Venkata Kirshnan on YouTube in 2014 highlights some of the many considerations involved in an SCM effort. More demands have emerged since then, such as Continuous Integration and Continuous Deployment (CI/CD).

The whole is greater than the sum of its parts

Version control tools such as Git, Subversion, and Microsoft Team Foundation Server can help identify application assets and even help to allocate changesets to different functional areas and/or lifecycle stages. Such tools, however, know little (if anything at all) of OpenEdge compiling, dependencies, or database schema. With these general version control applications in use, one must look to other tools for those functionalities.

While database design tools are relatively plentiful, very few of them work with OpenEdge databases. For the few tools that do, even fewer have a concept of schema versions – let alone associating a set of schema changes with a set of code changes to deliver a cohesive release of an application. While these database tools may be practical, they require external processes to integrate them into the more extensive lifecycle management system. Often those processes are a collection of complex DIY scripts and file transfers.

A total approach to managing a serious software development effort not only requires a clear plan for what processes it should entail but also dedicated time and effort to set them into motion and keep them in motion. In deciding which tool(s) could best support these material efforts, we ask pretty good questions: is it newer (therefore assuming it’s better), is it widely adopted, is it best-of-breed? Yet these questions tend to be only part/function focused. Perhaps the questions we should be asking help ensure the integrity of the whole.

• How many third-party tools will be needed to support our plan?
• What technologies are required for each one?
• Are those technologies trusted and secure?
• Do we have the expertise to implement and maintain them?
• Will these parts work effectively together (if at all)?
• What gaps do we need to anticipate and fill? How will we fill them?
• What happens if one or more tools in this process change or go away?

Conclusion

Just as Progress OpenEdge provides a comprehensive platform for creating world-class enterprise applications, Roundtable Total Software Management System (TSMS) provides a comprehensive solution for managing the ongoing development processes they entail.

Why choose to continually manage an ecosystem of isolated (and often incongruous) third-party tools, DIY scripts, and manual processes when Roundtable TSMS readily delivers complete lifecycle management in a single solution? Maybe it’s time to give a total software management solution like Roundtable TSMS a look. And, with a complementary solution like Roundtable Automation, you can achieve more with Roundtable TSMS than ever!