On 21/12/06, Sebastian Stein <[EMAIL PROTECTED]> wrote: > > > > > > > Steve Jones <[EMAIL PROTECTED]> [061221 17:38]: > > Its one of those interesting bits how old approaches suddenly become > > "required" for SOA. The paper proposes a top down process > > decomposition approach (which has several issues in my experience) and > > a bottom up (from technology) discovery of services than then "meld" > > together. > > The proposed approach should not be taken as a complete methodology, but > instead as a way of thinking about approaching SOA. The model highlights > that you have to start with BPM first and not with investing a lot of money > in ESBs and technology infrastructure. Also it tells that the IT should be > driven by the business needs and not the other way around.
Complete agree with the later statement, and I completely disagree with the former. Now certain "Process" models at the enterprise level are no such thing (e.g. companies have a Level 0 "Sell" process, its not a process as it has no order or co-ordination). Processes describe only parts of how an organisation operates, goals define other pieces and goverments define others. Starting with BPM means your architecture starts with process and hence is process oriented. > > > In reality therefore this is a Process Oriented Architecture (as it > > places process as the important entity) and then use a technology > > driven approach to define services. This makes three big assumptions > > > > 1) That process can be used to describe everything in an enterprise (it > can't) > > No, we do not have this assumption. Please, take a look where IDS comes > from and you will understand that we always try to teach that BPM is not > just processes. You might want another term then rather than "Business Process Modelling", and you might want to have a tool set that doesn't pull all the 5 views heavily into the process view (from my experience), > Our tools are based on a method identifying 5 main views on > your business: organisation, data, function, process and products. Only > those views together form the enterprise model! Where would goals come in within those views? How would you describe non-organisational cohesive boundaries? And my personal favourite given these are claimed to be business tools, how do you easily represent to the organisation what its IT estate should look like and how its IT estate should be governed? > This is also the reason, why > we heavily question that BPMN modelling is BPM. For us, this is just > workflow management, because it has only basic support for data, > organisation and function view (product view is not represented at all). In > addition to the different views, you have a lifecycle. So just business > modelling without having a guiding company strategy won't pay of either. +1 on that. > > To give you a concrete example let's see how we represent services > internally. If you import a service description (WSDL), we do not simply put > this complete file into a database as many other vendors do. Instead, we > create a business and IT view for the service. You see this is where you have lost me. Firstly this assumes that services are IT only assets, and secondly it assumes that services are only consumed by modellers rather than being modelled themselves. > The IT view is an UML > component diagram representing the service as a component with interfaces > (port types), operations, parameters and parameter types. Internally, the > parameter types are represented with different diagrams from the data view. > On the other hand, you always have the business view on the service. What is the new functionality in IDS Scheer that gives me this business service view (that is missing from the paper BTW, so if you do have it then I'd really suggest getting it in there, it would impress me much more if you had that). > This is > the part the business expert is dealing with. The business expert doesn't > have to deal with the IT details. In the business view, it is possible to > connect for example "requirements" to the service to describe the service's > functionality in more detail (from a business point of view). Which is a bit of an odd way of thinking of it, surely it would be better if the tool enables the concept of business service to be modelled _first_ rather than retro fitting requirements on to existing IT artefacts (the WSDL). This is what I mean by taking an existing tool and not actually thinking in a different way. > > > 2) That the existing estate is the best place to start when > > considering your service model (it isn't) > > No, it isn't. However, if you go to a big company and tell them that they > have to start from scratch and throw away all their prior investments, they > will kick you out even before you finished your shiny powerpoint slides. So > it is always a good idea to show possible customers how they can migrate > their existing systems to a new architecture. Completely agree and I'm not saying you don't have to use the IT estate to deliver, what I am saying is that the services that exist within the IT estate should be modelled from the business perspective and not from the technology perspective. Out of interest which part of the IDS Scheer suite enables me to model high level business services _before_ I start mapping these onto the existing IT estate which may, but probably will not, be exposed using Web Services? > > > 3) That WS-* = SOA (it doesn't) > > True, and we know that. Therefore, we use internally a 3 tier model for > services and the technology implementing it is just the lowest tier. As the > tiers are independent of each other, it is possible to exchange it with > something else. However, at the moment we only provide support for WS-* for > the technology tier. As a vendor you only have limited resources, so you > have to focus. Focusing on public standards is a good choice. >From a marketing perspective yes, from a modelling perspective no. The piece that is missing (at least from my last demo and Q&A) is that there hasn't been any thought put into how you would _model_ a business service architecture or even a technical service architecture, independently of its current realisation. > > > It would be great if, for once, a vendor took a big step back and > > thought "hang on this SOA stuff is a new way of looking at business > > and IT, so maybe that means more than just re-badging our existing > > product and claiming its a pre-req for decent SOA" > > Don't under estimate what we vendor guys are trying to do. On the other > hand, we also have to ask for an open minded audience not thinking about > each product announcement as yet another "re-badging" of existing products. You can ask that, but quite rightly (given the history oif vendors in IT) will not get that "open-mind" as what has been done here is a quick "hey look a quick XSLT and we've got BPEL and that means we can call Web Services". There is a section in the paper which is classic "WS = SOA" "When these functional units are automated through [....] WSDL, SOAP, UDDI, BPEL, etc, they are called "Services"" The paper reads as a pure BPM pitch in the same way as the papers from 5 years ago would have read, there is no message around the impact of SOA as a business concept it just relegates services to be WS endpoints and thus things that can be consumed within the same world view as existed before. Sorry to be harsh, but there really is nothing in that paper that I'd describe as SOA. And this is summed up brilliant by the summary in the paper "A company's SOA begins and ends with its business processes" > > Regards, > > Sebastian >
