I did the keynote yesterday at the Open Group conference held in San Francisco. The conference was well attended, as usual for Open Group events, and also as usual very talented enterprise architects made up the audience. I went for a different angle this time, for this keynote. I focused first on the business case for SOA and selling SOA, then moving on to the steps for working through a SOA project (SOA Lifecy I did the keynote yesterday at the Open Group conference held in San Francisco. The conference was well attended, as usual for Open Group events, and also as usual very talented enterprise architects made up the audience. I went for a different angle this time, for this keynote. I focused first on the business case for SOA and selling SOA, then moving on to the steps for working through a SOA project (SOA Lifecycle). In the past I discussed ROI and the business case for SOA more in passing. Also, I attempted to provide some clear and detailed guidance as to how you create a business case for SOA, size a SOA project, and an overview of the SOA lifecycle. In other words, the fundamentals. I think it was well received, at least from the comments from those attending. I’ll provide excerpts from my presentation next week on the Podcast. So, make sure you’re subscribing to that. Of course the bloggers are quick to post their views. Here are a few: From Joe McKendrick’s blog. “Too many times, we’re engaging in SOA for SOA’s sake. In a keynote that helped kick of the conference, David Linthicum said there are many situations were SOA may simply not be necessary. A mainframe system that rapidly processes transactions may be well enough left alone. “You’re not going to increase the speed of your systems by putting a layer on top of it,” he said. “SOA success means applying SOA where needed. But if it ain’t broke, don’t fix it.'” Companies should pull the plug on SOA efforts not delivering ROI, David said. He also repeated his prediction from a few months back that that SOA would eventually fold into Enterprise Architecture. It only makes sense, he said — companies are discovering that they can’t have two separate processes — ‘SOA is EA and EA is SOA.'” From Mike Walkers blog. “Dave suggests to start with ROI first rather than architecture. I think that this is easier said then done, but I agree at a high level. I do agree that this should happen but as many architects know we are hindered by technology / strict business requirements, cost and deadlines. Start the Business case right away! Yes, yes yes!!! Ideally focus first on the capability and then figure out the downstream processes you want to enable to build that business case. Dave asserts that ‘the business’ is not happy with IT. I agree and this is a perception that we need to change. Dave provides a simple cost calculator and suggests us to use our own if we have one He also talks indirectly about the importance of Application Portfolio Mgmt, but doesn’t directly call it out. Rather he speaks of the value of having a catalog of SOA assets that provide iterative value BTW – I love the quotes: ‘Managing SOA by Magazine’ – Referring to what I lovingly call E-Weeker’s that take the guidance from the trade publications to heart and build systems accordingly. ‘Vendor Driven Architecture’ – Organizations that have bought into one SOA stack and allows that vendor to drive their SOA strategy rather than their business concerns.” He has a lot more detail, so you should click over to his blog and check it out. From Tony Baer’s blog. “Maybe it’s time to go back to basics, advised ZapThink’s David Linthicum during his keynote before the Open Group’s Enterprise Architects Practitioners Conference, being held this week in San Francisco. With undercurrents as to whether threats of an oncoming recession are taking its toll on SOA budgets, or whether there is what Gartner terms a “trough of disillusionment” afflicting SOA adoption, Linthicum stated to a room of enterprise architects that you have to start with an ROI case.” “But he raised an interesting point on how to quantify ROI from flexibility or agility, which is to compare a scenario of how the business acted previously vs. a predicted scenario after implementation, such as ability to swap out a business service rapidly. A “hard’ ROI would come from savings of time – how much would it take to make the change with and without SOA. We don’t blame him for not touching the “soft” benefits, such as ability to respond or change course sooner.” “Yet in the next breath, Linthicum stated that it’s advisable to take an iterative approach that blends principles of Agile Development in something he terms “Agile SOA.” Namely, you develop the vision, but not all the details in advance, and then you advance into it, one modest piece at a time so you don’t end up with, what Joe McKendrick termed a couple years ago, “Just a Bunch Of Web Services” or JBOWS.” And, from Jim Phelps. “Dysfunctional architectures that are currently deployed have led to enterprise that are locked up and unable to really improve because of the complexity. The activities have all be driven by tactical needs not strategic needs. Enterprise Architecture are raising their hands and saying we need a ‘master city plan’ but they don’t get the budgets or support so they end up acting tactically also. Need to convince people that the SOA technology and strategic planning are important. Need to start with the business case. The business drivers: Reduction of integration expense, increase in reuse, greater visibility, business empowerment and increase in business agility. ‘Think big, start small, succeed often’.” Good to know people are listening. Software Development