BPM Strategies - March 2008 - (Page 26) S OA A DV I S O R Mike Rosen is an independent consultant, providing advice and assistance on the design and implementation of SOA, business, application and enterprise architecture. Rosen is the editorial director of SOAInstitute.org, as well as co-chair of SOAInstitute.org’s SOA Conference Series. He has years of experience in the architecture and design of applications for global corporations and 20-plus years of product development experience for distributed technologies. Rosen can be reached at mike.rosen@ wiltonconsultinggroup.com. SOA and Application Infrastructure A few years ago, “applistructure” was all the buzz. It represents the trend toward combined enterprise infrastructure and enterprise business applications. But in a recent Google search for the term, nothing has been said about it since 2005. Did yet another “next great thing” bite the dust? Well, it turns out that, regardless of the term itself, the idea has been proven out. So what’s the big idea? Combining SOA and enterprise applistructure infrastructures is a logical extension of SOA-based architectures. If we look at the business value of SOA, it is to provide agility and flexibility in enterprise solutions. The foundation of this is a set of business services that can be combined together in a variety of different ways to compose new, more flexible business processes. There are two major challenges to achieving this vision and getting the promised value from SOA, including: 1) having a library of business services to draw from, and 2) having those business services share a semantic model so that they can actually be combined together into something meaningful. These two items are extremely difficult to accomplish in enterprises creating their own service inventory, but without them, the promise of SOA cannot be completely realized. So what are vendors to do so that SOA doesn’t wallow in the trough of disillusionment? How about if they provided the semantically compatible business services to the enterprise as part of SOA infrastructure (for a fee, of course), rather than hoping the enterprise might be able to create them themselves? From a different perspective, vendors might wonder how the approaching bandwagon of SOA can be jumped on so that traditional enterprise applications don’t get left behind in the dust. How about if the app vendors were to service-enable their products and provide the infrastructure for building new, composite, SOA-based business processes from their existing and proven enterprise suites? This pretty much explains the strategies of the major infrastructure/application players, depending on whether their current strength is infrastructure or applications. So, who are the major players, you ask? Well, “Round up the usual suspects.” They are made up of the major infrastructure vendors - IBM and Microsoft - and the major application vendors - SAP and Oracle. But wait, Oracle is now both a major infrastructure vendor, thanks to the purchase of BEA, and also a major application vendor, thanks to countless other acquisitions. This buying spree is exactly what we predicted back in 2005. Of course, this isn’t limited to Oracle, but they are a timely example. By the way, I think this is good for BEA, Oracle, and their customers. I have long maintained that BEA had the best technology, but that being an independent infrastructure provider was not a sustainable business model. Now, Oracle customers get the benefits of BEA technology underneath, and Oracle advances its position in the market. Don’t worry, the other vendors aren’t sitting idly by. I don’t want to burst anyone’s bubble, but generally, in the grand scheme of things, there are much more important success factors than which infrastructure you have. They all have strengths and weaknesses, they’ll all do the job. Instead, spend your time worrying about business alignment, or project management, or cultural change, or governance, to name just a few. 24 SOASTRATEGIES http://SOAInstitute.org?s
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.