As promised in my last post, following are ten steps for successful implementation of "Tomcat First" strategy within an enterprise.
While I cannot possibly address these elements and offer specific mitigating tactics to address each, below I have outlined 10 steps that my informal research has concluded form the basis for a successful 'Tomcat First' strategy. Again, your mileage may vary and not all of the enterprise that I interviewed employ all 10; conversely, some utilized other elements that did not make the list that I deemed atypical to the company being interviewed.
1) Poll your development community and chief architects and make sure they are at least neutral to the idea. If your corporate culture is pro-proprietary software, you will have a long, bottom-up fight on your hands. If this is the case, you will need to start at the CTO level and work top down.
2) Analyze your Java application portfolio and verify that your opportunity size is significant. If a majority of your applications require EJBs, or, you run very few Java applications, Tomcat may not be the right focus.
3) Model your internal savings/efficiencies (i.e., conduct a TCO study). At this point, you need to decide whether your "Tomcat First" strategy will apply to legacy applications, net-new implementations, or both.
4) Obtain CTO-level support. Even if your developers and architects are wildly fanatical over the prospect of "Tomcat First," enlisting the support of your CTO ensures top-down support and can help overcome pockets of resistance you may encounter from other teams that support the Java applications themselves, and infrastructure upon which they run.
5) Ensure operational support exists. Going into pilot phase, your infrastructure engineering, build, and operate teams must be able to perform basic L1/L2/L3 functions. Moving a pilot application to Tomcat only to have it fall over once it has landed on the new platform will cast a dark shadow over even the most efficient implementation.
6) Identify pilot applications. Selecting higher profile applications can accelerate your program; however, this approach can represent more risk.
7) Execute pilot application deployment.
8) Combine TCO study results, pilot results, and other benefits measured into a "Tomcat First" proposal. For those of you whose proprietary application software is distributed under a software ELA, financial benefits may accrue over the mid- to long-term. To offset the "Why would I use Tomcat when commercial application server X is free?" dilemma created by software ELAs, consider using the community edition of Tomcat and purchasing an enterprise-level annual support agreement from OpenLogic.
9) Present your "Tomcat First" strategy to the CTO and your architecture board. At this point, you need to have all your ducks in a row and should be able to make a compelling argument that puts the benefits associated with Tomcat ahead of any other proprietary application server that is in use in your shop. As such, it is important to push for "Tomcat First" and not come out of this meeting with a "Tomcat Also" result. Finally, ask the CTO and architecture community to jointly author a top-down directive that specifies that application owners/developers and software engineers must use "Tomcat First."'
10) Operationalize Tomcat. Wait, you're not done! This is perhaps the most important step. You need to ensure that your Tomcat deployment will enjoy the same level of asset lifecycle management, software configuration management, and operational support as any other piece of infrastructure software in your company – both now and at scale. Failure to deliver in this area will not only foil your "Tomcat First" strategy, it will make garnering support for future open source adoption efforts much more difficult.
OK, you've made it to the end of this blog! Are you still with me? If so, and you haven't initiated "Tomcat First" within your enterprise, go do so now! Once you're successful, you can then start supplementing the Tomcat and Java architectural approach outline above with other productivity solutions (e.g., those based on Python, Ruby, JavaScript, etc.).
In summary, the first part of this blog was somewhat of a walk down memory lane. The middle part was what I hope served as a strong and compelling argument in favor of enterprise Tomcat adoption. Finally, we culminate with what I call, "The Tomcat recipe for success." Truthfully, you do not have to start with Tomcat (or middleware). The steps outlined above are intended to work with other open source ingredients.
Personally, I view Tomcat as somewhat of a layup. In the words of a peer who manages the open source software program at a major financial institution:
"I try to remind people that our goal is to ensure appropriate use of software. There are cases where the open source component is not the right option. However, in the case of Tomcat, it was a no-brainer."
