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 Arnon Rotem-Gal-Oz on Sep 05, 2007 11:05 AM
Nick Gall wrote a post claiming that discussion of SOA without also connecting it to technology is problematic. Nick bases his post on a post by Andrew McAfee that attacks the notion of "It's not about the technology" (INATT).Like Andrew, I cringe when I hear this argument -- most especially in SOA discussions and most especially in SOA discussions in the Service-Orientated-Architecture Yahoo Group (British spelling). In such discussions, technology alternatives for implementing SOA are dismissed as irrelevant and the discussion floats away on its own hot air.Burton's Anne Thomas Manes admits she uses INATT however she believes she uses another meaning which emphasizes the technology is secondary to design.
More specifically, technology is an implementation decision. When initiating a project, the project team should first identify and analyze the project requirements, then select an appropriate technology that effectively supports those project requirements.Anne says technologies are tools and you need to choose the right ones for the job - the first thing should be to identify what the job is.

"Clients often want to build only an ESB because that involves a technology challenge without the need for messy business requirements. Building just an ESB becomes an IT field of dreams, where IT builds an ESB and then hopes some SOA will come along and use it. Such an ESB-oriented architecture loses the benefits of SOA. It does not create business value. In fact, it incurs cost without reaping immediate benefit. And it does not align IT and the business. The better alternative to ESB-oriented architecture is SOA-oriented architecture. Do not build an ESB by itself; build it as part of an SOA, preferably one that fits the SOA Foundation architecture that IBM recommend"At the end of the day, technology is important, we cannot afford to ignore it when we design an SOA or any project for that matter. However technology should be places as second chair to business - or should it? What do you think?
Open Sesame: Open Source Solutions for BI and Data Gain Acceptance
Give-away eBook – Confessions of an IT Manager
Achieving Results with Red Hat Integrated Virtualization
Would you enroll in an India Forex Group i.e http://www.indiaforex.com Groups?
I think there are two worlds of SOA: business and technology. . (http://soa-eda.blogspot.com/2007/05/two-worlds-of-soa.html) And I think - in general - at the basis of all business lays technology. Technology creates business: first the train, then Dutch Railway made business out of it. First the phone, that the telecom companies came up. First the microprocessor that Microsoft started to rule the world. Thinking the way around is not innovative...
To my mind it's a question of when SOA is about the technology rather than if. Is it not the case that technology matters whether we like it or not once we actually implement the architcture? In this case the if question is moot and we're left with when. In that case I agree with your second chair analogy because a good solution to the wrong problem is still wrong.
it's a question of when SOA is about the technology
Exactly. And that's precisely where SOA (and I'd argue architectural concepts in general) goes wrong. And why both sides of the argument are, in fact, right. Service Orientation debates per se clearly aren't about the technology, but if they don't very soon lead to practical technical details, there's a real danger they will get hijacked by architecture astronauts who will never land them. Conversely, landing them too early can lead to poorly thought-through ideas that realise themselves quickly into hard-to-change stubborn software, that the business ends up hating. It's often a fine line, and generally it's better to get to code early, but not at the expense of thinking through business alignment properly.
All businesses are subtly different, and therefore each SOA should end up reflecting this. The ESB 'field of dreams' article, referenced in the blog post, talks about a worrying trend that I am seeing a lot these days.
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.
3 comments
Watch Thread Reply