Despite some indications to the contrary where I live in the northeast US, it is finally spring in the northern hemisphere—which many people traditionally view as the best time to take on do-it-yourself projects and improvements around the house that have been piling up over the winter.
Painting the front staircase. Finally organizing the garage. Tackling that garden overhaul.
When it comes to your job, spring can also be a good chance to invest some time and energy in improvements to the applications that your development team is building and how you work on them. There are always plenty of back-burnered items that you’ve been meaning to get around to.
Things like ensuring you have a process to respond to security problems. Understanding how to answer obscure licensing questions for the components you use. Making an inventory list of all of the open source components you use like your boss asked you for six months ago. Not to mention, of course, plenty of things which are specific to your own application architecture.
Here’s a starting point for your to-do list:
1. Inventory what you have
- Make a list of all of the third-party SaaS services that are being used across your entire organization. Are you paying for software or seats that you’re not using? Do you have good security controls in place, for example through a single sign-on provider like Okta or OneLogin?
- Make a list of your in-house applications. Where are they in their lifecycle? Who’s on point for maintaining them? Are they aligned with your broader IT strategy? For example, can they be migrated to the public cloud, or do you need to start thinking about re-architecture or retirement of these services for the next growth period ahead?
- Make a list of your open source components. Now that you’ve inventoried your applications, dig into them to discover what third-party open source they are using.
2. Clean it up to eliminate inefficiency
- Cut unneeded expenses. With your newfound visibility and an idea of your near-term priorities, cancel SaaS services which you aren’t using anymore and ensure access to these services is locked down and centrally administered.
- Communicate the plan. Now that you’ve got a plan around your internal application development, come up with a communications plan and roll it out to the application developers on your team starting with the high level strategy. Be sure every application has a clear owner. They’ll be happy to hear about the big picture and understand how their work fits into it.
- Centralize your open source management process. Now that you’ve got a list of your current open source components and a roadmap for where you want to go, finally tackle that task of creating a central repository of known-good open source components that will meet your standards today and in the future. To get the heavy lift off your to-do list, consider partnering with the independent open source maintainers behind the projects that you use via the Tidelift Subscription.
3. Planning the next steps
- Plan for your internal apps. Create a database (or just a spreadsheet or wiki page!) of your custom-built applications with key attributes such as the primary owner and reference to your company’s security, licensing, and maintenance policies.
- Plan your open source management policy. Establish a baseline policy for open source components that go into your applications. How will you handle security vulnerabilities? What open source licenses work for your organization? Do you want to favor actively maintained packages over found source code? (You can learn more about how to work through these questions with these resources from Tidelift.)
And there you go—done and dusted. By taking time to get your arms around the application development resources you’re already committed to and making a plan for the future, you will be in a better place to have your development team working on the important things—like building applications that matter to your customers.
50 Milk St, 16th Floor, Boston, MA 02109
.svg){kind=icon}