SOA beyond the hype

Discussions

News: SOA beyond the hype

  1. SOA beyond the hype (16 messages)

    Taken from: soa-eda.blogspot.com The SOA-storm has tempered down. The extremely enthusiastic opinion-makers are cooling down. The hype is over, and SOA is there to stay. Tools are evolving toward maturity and enterprises are serious in adopting the architectural style of SOA. A new layer of governance, the hardest part of SOA, will slowly grow on top of today's IT-governance once the new CIO has convinced the board. Roadmaps are in place. What next? Build and implement new applications with new technologies and new standards, conforming to new architectures. And that leads to new challenges: Selecting the right tools to design, build and implement SOA-based applications; defining services and compose them into business process implementations. And building the services in core code. To get a picture of the current state, I ordered two books from Packt Publishing: Oracle SOA Suite Developer's Guide SOA Patterns with BizTalk Server 2009 I've chosen Packt Publishing as this publisher demands a practical perspective from its authors: concepts must be clearly linked to feasible implementations with available tools. You may click the links above to find out about the structure and content of these books. Both books give a good overview of the respective products Oracle SOA Suite 10gR3 and BizTalk Server 2009. In both books the authors drill down from conceptual patterns to implementation solutions including code snippets and screen shots of the tools in practice. In this respect both books are worthwhile reading, depending on the tools your company is using, to allow yourself a head start. Or - as I did - just to get an idea of the capabilities of tools currently available. I was surprised by the Oracle book. The authors did not only present a very clear picture implementing conceptual patterns with Oracle's SOA Suite, but they went one step further upwards in the design realm. This book explains higher level SOA design principles, such as the arrangement of services in different layers of concern and e.g. the great benefits of using proxies in front of the business services. This book has earned a special place on my bookshelf as it offers excellent insights in good SOA-design - from an IT-development point of view - which can be implemented with currently available tools. The author of the BizTalk book walks quite another road. The author explains the Microsoft concept of Windows Communication Foundation (WCF) and how BizTalk relates to it. A bunch of patterns is described including orchestration, schemas and endpoints, versioning and asynchronous communications. Finally the book mentions the new SOA capabilities of BizTalk 2009: a set of supporting services, components and patterns called "ESB Guidance 2.0". Some low level SOA design principles come to the scene as well in a chapter called "Planning Service Oriented BizTalk Solutions". This chapter focuses on the concepts of a service and the different types of services including variations of request/response services and one-way services. The difference between the two books is that the Oracle book might be seen as a SOA design guide, extensively illustrated by applying the Oracle SOA Suite; it has a main focus on the BPEL level (business processes). The BizTalk book is just a BizTalk guide; it has a main focus on the (web)service level and doesn't even mention BPEL. And what about the current maturity of these tools? Build/Test/Acceptance/Production workflow-support and support for configuration-items (build) control is very poor (non-existent) as far as I could determine, but nevertheless I think both products are mature enough to be used in developing real life SOA solutions. The users of these tools need a good understanding of the SOA-design principles and modern XML-based technologies and standards in order to create added values. The learning curve will be rather steep, but once being accustomed to one tool it will be rather easy to switch to the other tool. And the pace of developing - and modifying - systems will really increase compared to what we are used to.

    Threaded Messages (16)

  2. Re: SOA beyond the hype[ Go to top ]

    It is very much unfortunate that even in a hard recession time; people can think SOA as a readymade solution based on latest and greatest tools from IT vendors. First up all SOA do not have a direct relationship with all the technology terms mentioned in this post. Secondly SOA is an architecture practice which can be adopted in the “IT enablement of business requirements” business of an organization same way the organization utilize other architecture practices such as Business and IT Architecture. However SOA is more effective than other Architecture practice because, all SOA principles are made to establish implementation independent interfaces to explain all parties’ views and concerns in an effective fashion. Success of SOA adoption in an organization is not all based on what kind of tools an organization is purchasing from the IT vendor or what kind of IT standards, frameworks etc an organization support, but how much as organization understand their “capability based maturity level of enterprise domain model to adopt SOA based architecture practices ”. So do your home work before purchasing SOA polished tools from vendors, and if your CTO has a lifelong tendency to cover his/her ASS by backing his decision by tool vendors sales pitch by putting your organization’s stakeholders and consumers hard earned money, FIRE HIM/HER, he/she is not suitable for 21st century IT business.
  3. Re: SOA beyond the hype[ Go to top ]

    Success of SOA adoption in an organization is not all based on what kind of tools an organization is purchasing from the IT vendor or what kind of IT standards, frameworks etc an organization support ...
    Well, of course success is based on tools. In my view, one of the common problems with large-scale visions like SOA is precisely that some proponents forget that nothing works without an implementation. The tools we choose to implement the vision are critical : are they really capable or are they lacking core features? - are they more expensive than they should be to license? - to learn? - is the vendor stable? how does a particular implementation integrate with what we have now ? ... all questions with which all experienced IT managers are familiar. That's not to say an organization's capability to support SOA is not critical, although I personally would not adopt the marketing phrase 'maturity' to describe that capability. It IS critical - but so are the nasty little details of actually writing code that works, and for that we need tools that work well. In my opinion, we lack tools that work well right now. For instance, does anybody really think UDDI is a good or even workable solution for service discovery? Does anybody at this point think SOAP will really be the long-term solution for interoperable services? It's not that systems can't be built with these tools - it's just that they are difficult to use, especially as systems grow large and we reach outside our own organizations.
    ... if your CTO has a lifelong tendency to cover his/her ASS by backing his decision by tool vendors sales pitch by putting your organization’s stakeholders and consumers hard earned money, FIRE HIM/HER ...
    Somehow I don't think you have the power to fire your CTO, any more than I have the power to fire mine (I would not if I could, by the way). Again, there are realities to deal with ... and one of them is that the CTO may well know something you do not.
  4. Re: SOA beyond the hype[ Go to top ]

    ... Again, there are realities to deal with ... and one of them is that the CTO may well know something you do not. Well, part of this "superclass" knowledge might be the kind of insight sovereigns claim w.r.t. their subjects or a class relationship that is not hierarchical but contradictory ? If the CTO "knows" he/she should tell (appropriately).
  5. Re: SOA beyond the hype[ Go to top ]

    In order to communicate you need a phone, that is technology, made with tools. In order to move you need a car, that is technology, made with tools. In order to live in a house, you need to build it, I prefer to use tools for that. Let's stop arguing about what SOA is or is about. Let's try to get the picture complete and respect focus on aspects. Tools is one (important) aspect. As well as organization structure is, as well as program code is, as well as business processes are, as well as governance is, as well as people are... it's holistic.
  6. Re: SOA beyond the hype[ Go to top ]

    Let's stop arguing about what SOA is or is about. Let's try to get the picture complete and respect focus on aspects.
    How can we have meaningful discussions about SOA if we can't agree on what it is? The biggest problem with SOA is there are too many people saying it's something that it is not. It's absolutely correct that SOA is an architecture and that you can't but an architecture. Tools can help you implement that architecture and I think you are merely talking about that. If you aren't careful about making that distinction you are going to continue to get the kind of response that you received above. I don't think you are guilty of it (at least not in this article), but many people (especially vendors) have decided that SOA is whatever they were already selling or doing. This has made the term SOA almost meaningless. For those of us who see a lot of potential value in (real) SOA, that is extremely frustrating.
  7. Re: SOA beyond the hype[ Go to top ]

    James, You might be interested in reading my blog on the subject. There are some articles addressing exactly the issues you pose. My advice is to not get frustrated. Make your own definition of SOA within your scope of interest and from your own professional insights and just do the things you got to do with together your staf. Think of the light bulb just after it was invented. Nobody was able to sell it at that time... no business case, no understanding and no meaning at all, candles were much easier to make, much more practical in use and much cheaper in the shop.
  8. Re: SOA beyond the hype[ Go to top ]

    James,

    You might be interested in reading my blog on the subject. There are some articles addressing exactly the issues you pose. My advice is to not get frustrated. Make your own definition of SOA within your scope of interest and from your own professional insights and just do the things you got to do with together your staf.
    The point of language is communicate with each other. If we all make up our own terms for words, that goal is not achieved. An example of this is where I currently work, the term "unit test" has been redefined to mean something different than the standard definition of the term. Every person who is new to the organization is confused when they are asked to produce "unit tests". The problems caused by this endless. If I'm going to define SOA to mean what I want it to mean, I might as well call it JWA instead.


    Think of the light bulb just after it was invented. Nobody was able to sell it at that time... no business case, no understanding and no meaning at all, candles were much easier to make, much more practical in use and much cheaper in the shop.
    That sounds good but I don't think it's factual. There is a long history of people trying to invent practical lightbulbs. The problems were not with marketing it (the value was obvious) but rather with making them last long enough to be viable at a reasonable cost. There was also the problem of few communities having electricity. Also, on a side note and contrary to popular opinion in the US, Thomas Alva Edison did not invent the lightbulb.
  9. Re: SOA beyond the hype[ Go to top ]

    Let's stop arguing about what SOA is or is about. Let's try to get the picture complete and respect focus on aspects.


    How can we have meaningful discussions about SOA if we can't agree on what it is? The biggest problem with SOA is there are too many people saying it's something that it is not. It's absolutely correct that SOA is an architecture and that you can't but an architecture. Tools can help you implement that architecture and I think you are merely talking about that.

    If you aren't careful about making that distinction you are going to continue to get the kind of response that you received above. I don't think you are guilty of it (at least not in this article), but many people (especially vendors) have decided that SOA is whatever they were already selling or doing. This has made the term SOA almost meaningless. For those of us who see a lot of potential value in (real) SOA, that is extremely frustrating.
    In the main, I agree with this - but my solution is different. To the question "How can we have meaningful discussions about SOA if we can't agree on what it is?" I would answer that we do not need to have meaningful discussions about SOA. It doesn't make a particle of difference to an organization what SOA is or is not. What matters is whether what they are doing works for them. I think that "what SOA is" will be defined by looking at what we have done - after the fact, rather than before, like many things in the IT world. I think it won't matter then, either, any more than it matters now, "what SOA is". I think that we are trying to define this prematurely, before we understand it. No offense intended to anybody who is working hard to further our understanding, but it's pretty obvious that we simply don't have enough experience at this point to know what this should look like, let alone what is actually feasible - or useful. So I think we should all go build what we need and use tools that work for us, without worrying about how to categorize what we are building. After we've done that for another five or ten years we'll have a better understanding of how this works ... and then we can call it whatever we want ;-)
  10. Re: SOA beyond the hype[ Go to top ]

    I would answer that we do not need to have meaningful discussions about SOA.

    It doesn't make a particle of difference to an organization what SOA is or is not. What matters is whether what they are doing works for them.
    The most important thing is definitely that organizations do what is best for them. But it doesn't make sense to define SOA to mean "whatever works for an organization". That's the epitome of a meaningless TLA. It would be like me saying telling you that yoga has really done great things for me when I've redefined yoga to mean 'drinking 2 Belgian ales for breakfast each morning'. Me calling that 'yoga' is not only silly, it's actively misleading. You might think you understand what I mean (quite rationally) but really, I'm telling you something totally different. Seriously, what's the point of everyone calling what we are doing SOA if we all have a completely different definitions of what that means? It's an absurd notion. If SOA means nothing more than "what we are doing" it communicates nothing of value. I'm not saying everyone has to buy into SOA. I'm saying that everyone redefining terms to mean whatever they decide they should mean is stupid. In fact, if you don't buy into SOA, it's way more meaningful to say so than to just redefine SOA to mean something you do think is good and tell me that SOA is awesome.
    I think that "what SOA is" will be defined by looking at what we have done - after the fact, rather than before, like many things in the IT world. I think it won't matter then, either, any more than it matters now, "what SOA is". I think that we are trying to define this prematurely, before we understand it.
    You've just expressed one of the big misconceptions about SOA. It's not a new idea without a history. It's specifically derived based on what has worked over decades of distributed computing. I would suggest reading some basic overviews of SOA. There some freely available articles by Thomas Erl that are a good start. This doesn't mean that SOA can't evolve but it's not an idea cooked up out of a vacuum in a think tank. All in all, I really think SOA is dead as a lot of the original proponents do. Not the ideas, but the term. It's lost it's meaning and is now associated with a lot of major failures that really have nothing to do with the original ideas precisely because people redefined as they pleased.
  11. Re: SOA beyond the hype[ Go to top ]

    James, You keep talking about misconceptions of SOA. Does that mean that your definition is the right one? Please publish some articles to share your ideas with us; or if you already do, please refer to it. I would really appreciate that. I do that too, as an effortful contribution to the discussions and to mature my own insights (besides my daily involvement as a responsible architect). Although not everybody agrees with the ideas expressed, I experience a lot of appreciation and I appreciate the valuable feed backs. E.g. read this article about a 40 your old definition of a "service". It demonstrates you are right on that aspect Or this one about the two faces of SOA, again in line with your insights I guess. Or read this article, about a layered view that adds the function of an ESB as a valuable technical platform-component in the layered concept; technology matters to implement concepts, also with SOA. -Jack
  12. Re: SOA beyond the hype[ Go to top ]

    James,

    You keep talking about misconceptions of SOA. Does that mean that your definition is the right one?
    I don't have a personal definition for SOA. There is already a standard definition of SOA. And that's really the point. If everyone makes up their own definition of SOA, then SOA has no common meaning. Is there a rational argument to the contrary? This isn't just nitpicking either. One person can say SOA is the best thing yet and another say it's guaranteed to fail and they can both be 100% correct because we have no idea what they mean by SOA. My understanding is that Thomas Erl's books on the subject are considered to be authoritative at least in defining what SOA is. There are some articles linked from here that give the basic principles of service orientation (login required but I think mailinator works.) http://searchsoa.techtarget.com/generic/0,295582,sid26_gci1172714,00.html
  13. Re: SOA beyond the hype[ Go to top ]

    There is already a standard definition of SOA...

    My understanding is that Thomas Erl's books on the subject are considered to be authoritative at least in defining what SOA is.
    Huh?
  14. Re: SOA beyond the hype[ Go to top ]

    There is already a standard definition of SOA...

    My understanding is that Thomas Erl's books on the subject are considered to be authoritative at least in defining what SOA is.


    Huh?
    What don't you understand?
  15. Re: SOA beyond the hype[ Go to top ]

    ... Again, there are realities to deal with ... and one of them is that the CTO may well know something you do not.

    Well, part of this "superclass" knowledge might be the kind of insight sovereigns claim w.r.t. their subjects or a class relationship that is not hierarchical but contradictory ? If the CTO "knows" he/she should tell (appropriately).
    The CTO IS telling you what he or she knows, with his or her decisions. My point was that the CTO may well know more than the poster - that is, after all, very likely to be the reason he or she is the CTO in the first place. Aong the realities, moreover, is that fact that the CTO knows how to achieve power within the organization better than most critics - and that is a real skill.
  16. Re: SOA beyond the hype[ Go to top ]

    ...The CTO IS telling you what he or she knows, with his or her decisions... (BTW: there is no CTO telling _me_) In an ideal world this generally were the case, but in any organization of say more than 10 "full disclosure" begins to fade away - not to speak of bigger ones. Holding back information (not necessarily by the CTO) has always meant keeping power: do I spoil a secret here ? All levels of hierarchy have a DSL of their own, and not necessarily very compatible ones, so dialogue and not broadcast is needed. ...fact that the CTO knows how to achieve power ... - and that is a real skill. Skill - yes, but please stay aware of the complete list of those who fit in this description...
  17. SOA "Most Despised Buzzword"[ Go to top ]

    http://www.infoq.com/news/2006/11/soa-despised-buzzword