22 Responses

  1. Hugo Vega
    Hugo Vega January 7, 2009 at 8:30 am | | Reply

    Excellent comments!

    This just makes me believe that this is a great opportunity for companies specialized in transformation processes. Companies that do more than just IT.

    Hugo Vega

  2. Погибла ли SOA? | ERP, SAP, SOA and other buzzwords

    […] чего, почитайте и комменты тоже. Dan Foody ее поддержал. А MikeKavis так вапще всем напомнил про […]

  3. steve
    steve January 8, 2009 at 5:45 am | | Reply

    What annoys me is that you’re now listing the reasons why SOA is failing, when these exact same reasons were pointed out years ago. It didn’t stop the SOA Architect Astronauts from hogging into the budgets, screwing the business seven ways from Sunday, then bailing out to the next brand new fad.

    The next problem is now going to be all those incompetent “not an architect” people now leveraging up on the new glossy brochures, burbling out a load of rubbish about the next brand new thing (PaaS?), and screwing the business seven ways from Sunday yet again.

    Your mea culpa posting here is both a part of the original problem, and a tissue thin layer of excuse over your previous participation in being part of the original problem such that we’re even talking about “SOA is dead”. SOA never even bloody existed in the first place.

    Even talking about this topic is part of the problem, because it makes it sound like that there are options, considerations, and various balances to be weighed before making a selection. When the options are vapourware (cloudware!), they are not valid in the first place and should have been completely and utterly ignored so as not to waste resources.

    Until computer science and IT is overhauled with a new approach, we are still stuck with the problems and engineering tradeoffs of the previous approach, which is still von Neumann and mathematical mappings onto physical behaviour. Therefore all the solutions from the 1970’s are still valid for the problems we have now. Too bad, so sad. That’s reality.

    It’s still the same old “mainframe vs PC” battle, with different terminology and new bunches of money being thrown at new monkeys with new sales pitches. People with no knowledge or understanding of computing history will always caper up and down, but people who have been around will yawn at the same old shit with the new blinkenlitchens.

    Unfortunately, people with budgets and spending authority aren’t always the ones who have been around for a while, and that’s your real market there. Gullible idiots in the wrong area. Scam them while you can, and screw that business seven ways from Sunday!

  4. steve
    steve January 8, 2009 at 6:25 am | | Reply

    Yes, Mike. There has been no real innovation since the 1970’s. For every idea that is “new” now, I can find old videos and papers from the 1960’s or 1970’s that lay out the foundations. As an outstanding example, I can point to Douglas Englebart’s “mother of all demos”, or I can point to Alan Kay and Ivan Sutherland’s work with Smalltalk. Even John McCarthy’s work with LISP is making a comeback.

    EA doesn’t really have any merits in itself, as it is just a term that covers the area that is the problem. In that respect, it is better than SOA or SaaS because those names don’t even describe the problem. However just using the term “EA” doesn’t solve any of the “we suck at architecture” issues or the shortage of people who can actually make stuff work.

    To really direct attention at the problem, we can’t pretend to have a solution and then sell people on the new terminology. We need to admit that we in fact don’t actually have a solution, and then the problem is more clearly defined!

    To clarify the specific point I’m making… pretend I’m a business that bought into SOA. You now want me to buy EA. What exactly are you proposing, other than changing the letters of the acronym?

  5. steve
    steve January 8, 2009 at 7:23 am | | Reply

    I agree that the infrastructure and tools have improved to the point where it is easier to implement a solution than it used to be. The difficulty is that the solution may not precisely match the problem, and therefore add its own problems.

    I don’t really know which tools and platforms that you’re associating with EA, but Dave Linthicum did make a good point – which is that there are not enough qualified architects to go around. You have an advantage over the SOA crowd in that your EA label is a better description of the problem.

    Where I lose faith is when you bring in the tools and platforms and frameworks, as that’s just another set of solutions for the same old problems with a different label on it. EA instead of SOA. To misquote Animal Farm, “meet the new solution, same as the old solution”.

    I think it’s better to directly describe the problem by simply saying that there is a shortage of people who can make stuff work.

    Fantastic tools with great amounts of snazzy output cannot create more people who can make stuff work, it can only create the impression that stuff is working. This is sufficient to create the “silver bullet” market, as there is a time lag from implementation to discovery where profit can be made.

    Note that I’m on the other side of the fence from you. As a consultant, you want to know the most about a set of solutions that you can adapt to suit a range of problems, hopefully leading to a win-win situation. I have to consider when that doesn’t happen, and what consequences there are.

    Even if you implemented EA and it worked, I still have the problem of solving the time lag until I know that it works, and whether the “EA” that you implemented is really “Mike can make stuff work” or a valid way of transforming numbers of people into “can make stuff work”.

    If it is going to take time to find out if things are working, and if it turns out to be Magic Mike, then I may have solved a business problem at the risk of creating two larger ones. How do I reverse out of business processes being critically dependent on Magic Mikeism?

    The ideal situation is to have a group of people who can make stuff work, and identifying those people is very difficult and the real problem to be solved. With the right people, real work can be done. Observe Lockheed Martin’s Skunkworks and the SR-71 Blackbird’s development.

  6. Mike Rollings
    Mike Rollings January 8, 2009 at 9:39 pm | | Reply

    Mike, I enjoyed reading your post and I also believe that the enterprise architecture discipline can help. But, EA is acronym-challenged too. Any time we get fixated on an acronym (e.g. SOA, WOA, EA), or any shiny new IT focused thing, we remove our focus from the important stuff – the business outcome and the transformation we are trying to enable.

    I also commented in our Executive Advisory Program blog(http://eapblog.burtongroup.com/executive_advisory_progra/2009/01/soa-kill-the-acronym-and-focus-on-business.html).

    Mike Rollings
    Senior Analyst, Executive Advisory Program
    Burton Group

  7. Architecture + Strategy : SOA – End of Life 2009.01.01

    […] there are many, many identified technical reasons why most SOA projects don’t succeed, Mike Kavis in his post has articulated one perspective nicely at a high level (just summarizing his list […]

  8. SOA – End of Life 2009.01.01 « Circuitous windings in thought

    […] there are many, many identified technical reasons why most SOA projects don’t succeed, Mike Kavis in his post has articulated one perspective nicely at a high level (just summarizing his list […]

  9. MicrosoftSoCalArchitectBlog : SOA – End of Life 2009.01.01

    […] there are many, many identified technical reasons why most SOA projects don’t succeed, Mike Kavis in his post has articulated one perspective nicely at a high level (just summarizing his list […]

  10. A rational explanation of SOA’s troubles | Service-Oriented Architecture | ZDNet.com

    […] Mike Tavis, jumping into the “SOA-is-Dead” […]

  11. Ron Cleaver
    Ron Cleaver January 16, 2009 at 6:59 pm | | Reply

    I’ve been in IT about 40 years. SOA and EA and SaaS and cloud computing all seem to be, in one way or another, just the latest attempt at centralization.

    But the rise of decentralization changed all that. It allowed silos to form. You can’t get silo owners to give up their silos. You will have to pry the silos from thier cold dead hands.

    I’ve seen it dozens of times. I’ve seen “new” systems that start back on the trail to centralization be retired or abandoned, while the silos survive.

    Look at how long the federal government has been trying to do EA. They even call it FEA. And it seems they now believe it’s really SOA. But there are NO successes, just feeble attempts that did accomplish something but have nowhere to go.

    I’ve talked to executives who agree that EA and all the other stuff is just a solution (maybe) in search of a problem. Plenty of them are content with working silos, and don’t even believe that SOA or anything else will provide any value they can’t get anyway. Many of them think (and rightly so) that the cost will far outweigh the (often vague) benefits.

    IMO the organizational problems are the kiss of death.

  12. Why We Suck
    Why We Suck January 16, 2009 at 7:35 pm |

    […] Did SOA die or do we just suck at architecture? (kavistechnology.com) – January 06, 2009When you bowl it down, what is the real problem here? In my opinion, we suck at architecture! Why do we suck at architecture? Let me count the ways. We think process is a bad thing and it slows us dow… […]

  13. Pragmatic Dictator » Cutting Corners
    Pragmatic Dictator » Cutting Corners January 25, 2009 at 1:01 pm |

    […] summary, making the best of the cloud requires that we take an architectural view, something that we’ve proven remarkably bad at over and over. Simply deploying an application unchanged to the cloud is unlikely to deliver much […]

  14. The Value of EA is in the Eye of the Beholder

    […] deliver incremental milestones in your roadmap towards the future state. Without EA, we might just suck at architecture! VN:F [1.0.9_379]please wait…Rating: 0.0/5 (0 votes cast) enterprise […]

  15. So much failure, so little architecture

    […] have all talked about the Death of SOA, the imminent failure of Cloud Computing,  and countless other IT failures on blogs dedicated to […]

  16. Cloud Computing: Top 10 Worst Practices | Kavis Technology Consulting

    […] architected differently than on-premise solutions.  Let’s learn our lesson from all of the SOA failures and focus on architecture.  You don’t buy security, compliance, failover, performance, […]

Leave a Reply