IT managers are now faced with the proverbial task of “doing more with less.” When faced with an edict “from above” to cut unnecessary costs and prepare for nuclear winter, the natural instinct is to eliminate all new projects and focus on rationalizing and maintaining existing infrastructure. However, in a world where IT holds an increasingly critical place at the core of the enterprise, this “doing less with less” approach is counterproductive-and can spell eventual doom.
If simply eliminating projects across the board doesn’t make sense, what are some approaches that IT managers can take to help their businesses gain critical competitive advantage, even amidst a shrinking budget environment? Consider existing service-oriented architecture, or SOA, projects. If the SOA initiative was originally put into place for valid business reasons (for example, improved agility, increased visibility across business silos or operational efficiency through integration), then pulling back from that initiative would damage the business in kind.
Fortunately, the available tools and approaches have evolved dramatically in the past few years. SOA no longer represents the high-investment/high-risk undertaking that early adopters once faced. In many cases, overwrought standards (for example, SOAP/WS-*) and complex, heavyweight infrastructure software are being replaced by simplified approaches (for example, representational state transfer, or REST) and lightweight, open-source tools.
This means that organizations can learn from the mistakes of the early adopters, pursuing SOA in a much more pragmatic, needs-driven fashion. SOA as a top-down initiative for its own sake is unequivocally “out,” as organizations can’t afford to rearchitect everything from scratch in these lean times. Instead, today’s successful SOA projects will take advantage of new tools and techniques, squeezing every last bit of value from existing IT assets.
The following are five steps that IT organizations pursuing an SOA strategy can take today to make sure they are not throwing out the proverbial “baby with the bathwater”:
Step No. 1: Identify business goals and how IT is expected to support those goals
Investments in technology-enabled business processes (for example, merchandising, supply chain and pricing) can deliver up to 10 times the bottom-line impact of traditional IT cost-reduction efforts. Delivering against business goals does not mean IT becomes a “utility,” taking orders from business owners. Instead, IT needs to work in partnership with business owners to help them understand what’s possible and to be an advocate for technology-enabled change.
Brutally Prioritize Projects
Step No. 2: Brutally prioritize projects
Separate the need-to-have from the nice-to-have. Once you have identified the key business goals for IT at your organization, apply a surgical knife to your current project portfolio. Only retain projects that have a direct need-to-have impact on those goals. This is not merely a cost-reduction exercise, but rather a way to focus limited resources on projects that will have immediate business impact.
To be clear, prioritization does not necessarily mean an end to experimentation or evaluating new approaches or tools. To the contrary, your increased focus may afford you additional resources to try multiple approaches to solve your highest priority problems, or to take calculated risks while building a solid Plan B.
Step No. 3: Save yourself first, then build the business case
Navigating an economic crisis for IT is like sitting in a depressurized airplane cabin: You’ve got to put the oxygen mask on yourself first before helping others who are dependent on you. Similarly, IT needs to make sure it saves itself first before it can help the business achieve its goals. The best way to do this is to build a bulletproof business case for priority projects, quantifying how those projects will impact the bottom line.
The good news for SOA-related projects is that SOA can often be justified on a stand-alone basis. This means that IT organizations can see return on investment just from IT-related savings alone, even before the following three business benefits are taken into account:
a. Lower application development costs through code reuse. Analysts have pegged benchmark savings at as much as 20 percent of overall application development costs over the long term.
b. Lower integration and maintenance costs. Research indicates that solid SOA architecture and tools can reduce integration costs by 30 percent or more, as well as reduce maintenance of integration by up to a whopping 75 percent.
c. Retiring or modernizing legacy assets. Moving to an SOA approach might enable IT to reduce legacy services or maintenance costs. For example, The Leukemia & Lymphoma Society recently built a service-oriented platform for its fundraising activities, replacing a legacy-hosted application provider. It ultimately saved millions of dollars per year in transaction fees.
Explore Ways
to Do More with Less
Step No. 4: Explore ways to do more with less
Once the business case is built for SOA, it is critical to learn from the many organizations that pursued aggressive, “strategic” SOA initiatives and ultimately failed. Avoid at all costs any “big bang” vendor-driven approaches that involve any rip/replace of infrastructure, long service engagements and promises of ROI in the “out years.” Instead, focus on tools and approaches that enable low entry cost and incremental investment, with the ability to prove the ROI before scaling further. Any infrastructure should adapt to existing IT assets, including both application assets and even existing SOA infrastructure (for example, existing Enterprise Service Buses, integration brokers and governance tools).
During the planning stages, perform a comprehensive total cost of ownership analysis, taking into account all capital and operational costs, along with timing. Some of these considerations might include the following three:
a. Software costs and timing. For example, upfront license costs versus pay-as-you-go alternatives such as SAAS (software as a service) or open-source subscriptions.
b. Architecture and implementation considerations. Such as rip/replace versus infrastructure that works with existing assets.
c. Resource allocation. Focusing limited in-house resources on high-value activities (for example, fulfilling business requirements) rather than commodity activities (for example, troubleshooting) by selecting professionally supported tools (for example, open-source platforms with commercial support offerings).
Step No. 5: Govern and measure
It is now widely understood that SOA does not stop at implementation. Indeed, it is imperative to set up the organizational processes and tools for ongoing governance and measurement. In a constrained budget environment, a targeted and pragmatic approach to SOA governance makes the most sense. Determine the key levers that drive the business case (for example, is it savings through code reuse? lower maintenance costs?), and develop metrics to track those levers. Implement processes and tools (for example, an SOA governance registry and/or repository) to help aggressively measure performance and enforce best practices.
In general, these five steps are applicable to IT in good economic times as well as in bad. However, in a time of recession, following these principles ensures that critical IT initiatives such as SOA don’t get thrown out with the proverbial bathwater. In addition, although the principles stay constant, restrained budgets necessitate a highly pragmatic approach-one that is focused on shorter planning cycles, incremental investment and aggressive measurement of success metrics.
Ross Mason is CTO and co-founder of MuleSource. Prior to founding MuleSource, Ross was CEO of SymphonySoft Limited, a EU-based company providing services and support for large-scale integration projects. Previously, Ross was lead architect for RaboBank and played a key role in developing one of the first large-scale ESB implementations in 2002. Ross has also worked with NatWest Bank, Credit Suisse and UBS.
Ross founded the open-source Mule project in 2003. Frustrated by integration “donkey work,” Ross set out to create a new platform that emphasized ease of development and reuse of components. He started the Mule project to bring a modern approach, one of assembly rather than repetitive coding, to developers worldwide. Ross holds a BS (Hons) in computer science from the University of Bristolin Bristol, U.K.He can be reached at [email protected].