There is some decent stuff in here but it does take a rather optimistic view on why you'd start with a business process (which isn't the language of the business BTW) especially at the end
" 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." Putting aside the process view for a second, the challenge here is that this places SOA as being a cost-saving exercise with an ROI case to justify investment. This is just a project, it doesn't need to be SOA at all, indeed if you want to reduce the costs of non-core business processes (the bits where they tend to really exist is in the back-office) then there is a simple answer - outsource. That is a simple business answer to the challenge. Yes I work for an outsourcer but throwing SOA as the answer in for this is a very dangerous task, "switch to SAP" would be another non-SOA required option. Cost constraints always mean companies will take a more tactical rather than strategic view and this will mean delivering in smaller increments (something I've always championed even when people have larger budget) but focusing SOA around process inefficiencies sounds to me like a technical SOA view and something about implementation rather than about architecture and planning. Where I'd targeted SOA is working out which services are important to the business and which aren't and then using that knowledge to dramatically reduce the costs in the non-important areas by changing people's organisation, behaviours and measures. I'd look at SOA as a way to reduce IT spend by concentrating any development into areas where it can really add value rather than looking at processes (which often cross multiple value areas). Personally I'd be looking at going for the higher value areas where investment can be justified rather than in pure cost reduction areas where a contractual structure is probably a better, and certainly simpler, way of achieving the same end. Steve 2008/10/10 Gervas Douglas <[EMAIL PROTECTED]>: > > > 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. > > >
