ZapThink </>
Investing in SOA in a Down Economy
Document ID: ZAPFLASH-2008109 | Document Type: ZapFlash
/By: Ronald Schmelzer/
Posted: Oct. 09, 2008
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.
