The Dow Jones Industrial Average is down another 600 points at the time of writing this ZapFlash. Banks, investment houses, and insurance firms are succumbing to a combination of tight credit markets and their own bad decision-making. Consumers are feeling the pinch at gas pumps, grocery stores, facing home foreclosures, and unable to get credit, and businesses are feeling the squeeze even more, laying off employees and unable to get credit they need to fund operations. Yes, the world is in a global recession and we're probably just at the beginning of what can potentially go wrong. So, you're probably thinking, now's the time to pull up the stakes and cancel your ongoing investment in SOA and related IT efforts. After all, why bother investing in something as future-looking as SOA when you can't even afford to keep the lights on? Right? Wrong.
Businesses often go through a dysfunctional, schizophrenic sort of decision-making that seems to continuously put them at a disadvantage. When times are going great, companies are focused on rapid growth. There's so much money to throw around that there's little reason to be focused on efficiency and the longer-term efforts of enterprise architecture. From this perspective, businesses reason that they don't have time to get things right, but rather have time to do things over. Then, the inevitable happens, and the economy cools, customer demand slackens, and belts tighten. Now, there's no money left to invest in growth and agility. Rather, money must be spent on the inefficient operations because there's no additional funds to invest to make things better. Damned if you do; damned if you don't. It seems that enterprise architecture will perpetually get short shrift.
So, when's the right time to invest in enterprise architecture? NOW. Yes, now. Think about it: when can you least afford inflexible, inefficient, redundant, non-interoperable systems that have high cost of maintenance and little ability to provide for future, unknown requirements? When you don't have the money. When must you invest in architecture? When you can feel the pain so acutely that you can focus on short-term wins to make enterprise architecture efforts effective.
Stop multi-year SOA efforts. Focus on iterative, process-driven SOA efforts
The business is only partially to blame for the continuous cycle of enterprise architecture non-investment. The blame lies equally with the IT organization. IT departments have inappropriately approached SOA efforts are Web services integration projects and bought infrastructure before they figured out which services to build, and before they figured out which problems to solve. Even worse, many IT departments approach SOA as a solution in search of a problem, without crafting a business justification or proving to the business that SOA can work to solve a small problem before throwing in millions of dollars of investment to unsuitably address a large one. Many vendors are equally to blame, pushing their "SOA" products down the throats of customers without ensuring that their customers will even be successful with SOA initiatives, and often misrepresenting the capabilities of their products in the process.
In times of stress and uncertainty, the best way to move forward is to take small steps and measure the results of each step to make sure you are heading in the right direction. From that perspective, SOA is not particularly risky. Remember that the fundamental objective of a SOA effort is to enable continuous change in heterogeneous environments by abstracting capabilities through services. There's nothing inherent about SOA that requires that you service-enable every system you have or every API, nor does SOA mandate that you address every business process in the organization. You can get immediate benefits from SOA by simply building one service that is broadly consumed in the organization and, more importantly, addresses a key business process problem relating to change. How do you know that a problem is worth solving in a Service-oriented way? If you can identify a continuous cost or time consumption associated with changing that business process in any respect.
I was recently on a panel with a number of other notable architects at a ComputerWorld event run with IBM, and one of the first questions I got was, "what's the best place to start a SOA initiative, and how can I convince my boss it's the right thing to do?" The resounding answer from the whole panel was to start by identifying a single business process that can be improved from a cost and/or time perspective by service-orienting it. Don't start with a system. Don't start by buying an ESB. Don't start by doing a two-year, enterprise-wide, organizational top-down service analysis exercise. Start by focusing on the business, and more specifically, a business process. When you talk in terms of business process, you're talking the same language that business talks, and miraculously, you've achieved business-IT alignment.
No budget? Recover costs with SOA
But even more miraculously, if you can find a process to improve, you won't need to convince senior management to part with precious funds. Rather, you can simply offer the business to recover the costs by improving the business process and using those recovered funds to reinvest in the enterprise architecture, starting the cycle again. How would a cost-recovery approach to SOA budgeting work? The key is to start with the smallest business process you can find that is the most inefficient, where the inefficiency is caused by an aspect of continuous change (a lack of agility) and the business is nevertheless forced to continue to invest in that inefficient business process.
For example, let's say that a business must spend $2 million annually on B2B integration expenditures because it continues to add, modify, or remove business partners as part of its daily operations. The investment is required because the IT systems are so rigid that every time the schema is modified, or a new connection point is added, a policy is modified, or the process is altered, the IT department needs to write new code, purchase more licenses for adapters, or otherwise perform some continuous expenditure. What if instead of spending that $2M doing the same old broken thing the same old broken way, the IT department can say that they will spend the $2M improving the business process so that over the next iteration, that expense will not be required again? Can this be done? Surely – the cost of architecture is simply the cost of doing good design.
The ZapThink take
In fact, architecture itself is simply an aspect of planning. It would be foolish to say that when times are tough, companies should throw planning out the window and resolve to do things the same old broken way they always have in the past. Indeed, when times are tough, it is imperative that businesses rethink the way they are doing business – i.e., their business processes – and improve them to wring out every dollar of inefficiency they can. It is the role of the enterprise architect in the organization to help identify and improve inefficient business processes, and it is the opportunity for SOA to provide value to recover the cost of that inefficiency.