Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Mark Little on Oct 18, 2007 03:30 PM
Over the past few months we've been hearing more and more about the death of SOA. From what we've heard so far, maybe this is just what Gartner calls the Trough of Disillusionment. However, as InfoWorld mentions:"... the model is potentially in danger of misdirection and ignorance rendering it a worn-out moniker that represents mere product features. That's more or less what happened to EAI, after all. Forces that might be assassinating SOA include: integration platform vendors, enterprise architects, certain industry analysts, CIOs."It's with this in mind that the latest article from ZapThink tries to put things into perspective.
"Any trend that demands such a significant portion of executives’ and practitioners’ time and budget demands to be critically examined so that the good of all parties are being met. After all, very few people benefit from trends that are all hype and no substance."According to the analysts, the most frequent cause of failure of SOA is inappropriate use. The "one size does not fit all" argument would appear to be an accurate summary of this pitfall, where companies try to use SOA across the enterprise when the business case would not be justified.
"The rationale goes that SOA is an aspect of Enterprise Architecture and therefore its scope is enterprisewide, or because it is so important and strategic, it must be implemented at an enterprisewide level. Other IT practitioners are simply used to implementing all of their major initiatives enterprisewide, so why should SOA be different? Because SOA is not a project or a technology – it is an approach, that’s why."SOA is simply not appropriate for all problems and determining when and where (and if) to apply SOA principles should always be the first step in any attempt to use SOA. The inappropriate use (or overuse) of a technology, methodology etc. has often resulted in its downfall in our industry:
"When companies seek to implement hundreds of unproven Services against a business case that is not justified using millions of dollars of untested technologies, they risk significant failure. And when those SOA projects fail to deliver as promised, do they blame their own efforts, the products they used, or their methods? Of course not. They rest the blame on SOA itself."As far as the authors are concerned:
"On the flip side, well-scoped SOA projects are often remarkably successful. Most case studies of SOA success relate to organizations fixating on a particular business problem, perhaps at even the departmental level, and solving that in a Service-oriented way. The champions of SOA know full well that success comes from focusing the solution on a particular problem and solving it well."
The article goes on to make the case for Enterprise Architecture Teams as the best way to apply SOA principles, because very few individuals have the skills to understand the business combined with the technical acumen necessary to understand how SOA best practices can drive business solutions. Building cross-functional teams that include, for example, line of business representatives, application development, data modeling, process modeling, security, and network operations roles, can be a key element in the success of SOA deployments.
There's also a strong educational requirement needed throughout organizations:
"Where business can see a solution, sometimes IT is blind. Too many times IT departments try to use the SOA hammer to approach every problem as a nail. Indeed, the symptom of ill-scoped SOA projects is partially caused by this inability (or inexperience) to utilize SOA properly. ... Technologists often get stuck in defensive positions regarding particular technological approaches (REST vs. Web Services anyone?). These arguments relate little, if at all, to the business problem at hand and tend to devolve into pedantic arguments of semantics. The truth of the matter is that any technology approach that can solve a business problem is valid, and probably will be displaced in favor of a better one in a few years anyways."
However, the article finishes with some sound advice for those looking to deploy applications based on SOA principles or wondering whether they have the right skills in place to continue with existing deployments:
"Smart architects and business managers who seek to apply SOA to solve their problems should have a firm grasp as to when SOA will provide success and when it is being inappropriately shoe-horned. Such a grasp includes realistic assessments of the people, technologies, processes, and methods of the existing environment and proposed solution, and the drawbacks of any potential solution. Having such a balanced approach serves to further the likelihood of success with SOA, and doesn’t by any means kill the value of SOA itself."
Usage Landscape: Enterprise Open Source Data Integration
Give-away eBook – Confessions of an IT Manager
Business Benefits of Open Source SOA
Agile Development: A Manager's Roadmap for Success
The Agile Business Analyst: Skills and Techniques needed for Agile
Would you enroll in an India Forex Group i.e http://www.indiaforex.com Groups?
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
No comments
Watch Thread Reply