Hhhmmm....I guess this catchy play on words has been done before - HYPERLINK "http://www.hurwitz.com/index.php?Itemid=58&id=294&option=com_content&task=view" http://www.hurwitz.com/index.php?Itemid=58&id=294&option=com_content&task=view Dave << SOA is dead – long live SOA HYPERLINK "http://www.hurwitz.com/index2.php?option=com_content&task=view&id=294&pop=1&page=0&Itemid=58"; \nPrint HYPERLINK "http://www.hurwitz.com/index2.php?option=com_content&task=emailform&id=294&itemid=58"; \nE-mail Written by Judith Hurwitz, President & CEO Monday, 01 October 2007 Change is hard and threatening. In a nutshell, this is the problem facing the movement to service oriented architecture. Many programmers are threatened by the idea that they will lose control of the development process. If I move to service oriented architecture will I still be able to develop code the way I like and know? What about “agile” development? If I get better at coding isn’t that good enough?
On the larger front, IT management is afraid that SOA will end up being a money pit. After all there have been many efforts over the past 25 years to break the code on how to develop more predictable, flexible, and modular software. In fact, one of the common complaints I see when I read various discussions in the media about SOA. Here is a sample of what I am seeing: · SOA isn’t really new; it is very much like subroutine libraries, so what’s the big deal? · Isn’t this just another way to do object orientation? Remember, that didn’t work. · Early SOA projects haven’t shown a significant ROI so are they really worth the effort? · Maybe SOA is just a big science project. Maybe we should just create simple mash-ups using Web 2.0 instead. · We love SOA and we have really smart technologists in our organization. We’ll do it ourselves. A commercial software provider could never hope to provide the unique capabilities our organization requires. · My organization owns our own data and processes because we are unique. Sharing is not going to make us better. Control is too important an issue. · Our business unit is unique. There is no way that there could be common services. Now, I’d like to take each of these issues and give you my take. Let’s start with the first: SOA isn’t really new Of course not. SOA is based on the learning from everything from subroutine libraries, mainframe message transports, to object oriented development, and custom coded encapsulated business services. In the early 1990s companies were creating business services to be reused as they rebuilt crumbling applications using custom coding. Startups emerged that were intended to create a marketplace for reusable services. It is the natural evolution of any industry. How long did it take the automobile industry to mature? How long did it take to harness electricity so that it could become a utility? Experimentation and failure are simply part of the process of turning ideas into practical reality. Service orientation is a foundation built on more than 20 years of early efforts that technologists can build upon is the prerequisite for technology that is maturing. Isn’t this just another form of object orientation? Again, refer back to the first question. The objective of an object orientation was to provide a way to create reusable software components. In these early days, however, the approach to object orientation was flawed. The typical object that developers created was simply too granular and therefore too hard to reuse. If a developer created thousands of small objects, it became apparent that reuse would not be practical. Right idea – wrong execution model. But it was the right thinking. One more issue faced by these pioneers: The connective tissue that would bring all of these small grained objects together did not exist. Therefore, it was impractical to build true systems out of the piece parts. There were no standard interfaces and no consensus on connective tissue or middleware. SOA projects aren’t providing the expected ROI. This is a loaded statement. Many organizations have been able to achieve tremendous initial benefit from their pragmatic early stage SOA projects. Some successes were as simple as creating a configurable business service that makes it easier to add a new partner. And while the application may seem simple it has added millions to a company’s bottom line. Many companies we have spoken with are gaining clear benefit from their early experience with SOA but don’t want to reveal the details of their investment and the return. Why would you alert your competitors when SOA is giving you a competitive advantage? In fact, many of the companies that Hurwitz & Associates analysts have interviewed about their SOA strategy will not publicly discuss their SOA ROI. But more important than these early successes is the fact that SOA is a long term strategy, not a quick fix. Pragmatic companies are implementing SOA in manageable pieces starting with their most immediate business problems. The long term benefits will be there because they will – in time – change the very fabric of how organizations are able to harness their corporate IP to react to business innovation and changing market conditions. Within the IT communication, there is a short attention span. A typical developer wants the opportunity to work with cool new stuff. A ten year journey is not quite as sexy. SOA as big science project. SOA is not a short term project. It can indeed to be implemented in an incremental way but it is something that organizations should and are viewing as part of a long term strategy that directly impacts a company’s ability to innovate its business model. Why get caught up in something complicated when we can just create some cool Web 2.0 stuff. Now, don’t get me wrong. I like mash-ups and Web 2.0. Both of these are important innovations – however, they do not exist in isolation. For example, let’s say that you create a few components that are to be used in a mash-up. What is the origin of these “mash-up services”? Are they well architected? Do they include code that might actually be dangerous? Could they introduce problems into an unsuspecting company? Could they lead to a poorly designed process? It would be better if the organization created well designed and vetted services to be used in a mash-up or composite application. The same can be said for Web 2.0 applications. It becomes a composite application that requires sophisticated client side communications middleware. Ironically, good mash-ups must have a service oriented infrastructure in order to be well designed. I guess there is no free lunch after all. We are the masters of the Universe. Sometimes really smart technologists are quite dangerous. I have seen some of the best and brightest companies in many different industries deciding to avoid commercial software. These companies believe that because they are masters of their industries that they must create their own SOA software. This is a myth. Those companies that wrote their own registries and repositories have lived to regret their own innovation. A financial services company or a health care group is not a commercial development organization. Maintaining unique software is not a task that brings revenue to the bottom line for these companies. Keep your hands off my data and processes. Let’s face it – control of infrastructure is political. Business management often sees service orientation as a pragmatic way to control the way technology can be used for business benefit. It makes sense that a service like process a claim or open an account should be common across the entire enterprise. Why should there be 100 or a 1000 different ways to say or code the same thing? After all, it is fundamentally about business process and codifying rules. Many IT professionals see it differently. They wonder if their jobs are at risk. Will the business begin dictating programming practices? The empires grown over decades might be crumpling. The same issue applies to the data developed and controlled within one business domain. Whose data is it? Departmental management often feels that control over that data is critical to maintaining control sometimes of quality and sometimes control of the data itself. After all, information is power. Our organization is unique – you just don’t understand. There are organizations that proclaim that they are so different that there is no way that there could be a way to share business services with others. While there may be components that are different and innovative – most services are common across business units. Unique implementations of the same services are simply that – repetition based on aging business models that simply have outlasted their usefulness. In the end – we are making progress Ironically, when the failure stories and talk begin to take shape, it is the first sign of success. With every innovation there is a stage of euphoria based on discovery that the world is about to change. It seems like magic and everyone is optimistic. And everyone wants to jump on board. Reality, of course, is different. In reality, change is hard. Undoing decades of trials, experimentation, and aging infrastructure is complicated. It is easier to try to stay with the old rather than embrace change. But in the end, we do embrace the new and the innovative and we move on. >>
<<attachment: printButton.png>>
<<attachment: emailButton.png>>
