On 22/12/06, Sebastian Stein <[EMAIL PROTECTED]> wrote: > > > > > > > Steve Jones <[EMAIL PROTECTED]> [061222 08:28]: > > ... > > First of all, thanks for your valuable comments! > > > > 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. > > Yes, but are we talking about the business architecture or technology/IT > architecture? I hope we are talking about the first one! Introducing this > process view in an organisation is since a long time the message we try to > teach. The implications of it are big for an organisation structured > functionally.
But only certain parts of businesses are best viewed a process perspective. I'm definately talking about business architecture here rather than IT/Technology. My experience with process driven business approaches is that they work well for back-office and commodity parts of the business but are weak at the differentiated parts, and regularly miss cross-functional opportunities for shared services and the like. > > > > 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), > > Ah sorry, if I write BPM, I always mean Business Process Management. This is > not just modelling. Okay, another term that doesn't have a "P" in it. If the goal is truly to get a holistic view, rather than purely a process centric one, then it would help not to have the P in there. > > > > 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? > > If you mean with goals the overall strategic goals of a company... you would > describe them for example in balance score cards with our strategy tools. > You do this before you start with modelling, because basically you want your > enterprise model to implement your strategy. Also, after executing your > processes, you have to measure if you achieved your strategy. You can for > example create KPIs to measure this and feed this back into your strategy > design. And parts of the organisation that are goal driven rather than process driven? How would you model these _operational_ goals? The problem I have here is that it assumes that everything must have a process to be executed, fine in the back office (which is why these tools often work hand in hand with apps vendors), but weak in the front office. > > > 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? > > Well, IT estates should not be managed by pure business people. Why not? At least in terms of ownership there is always a business person at the top of the chain (CEO) so the question is the switch between business management and operational management of IT. The business should at least be able to understand IT within their own language and terms. > They only > have to define the requirements on the IT, so for example which services > they need. On the other hand you have IT experts taking care of the IT > infrastructure. We also provide a tool for that called IT Architect. > However, you can also use other public frameworks like Zachmann or Dodaf. But this is part of the problem, namely it has an "over the wall" feel about it on the communication between the business and IT with IT being a mysterious world where business should not tread. I don't agree that this helps. > > > > 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. > > We are aware of that at the moment it is a little bit complicated to define > services from scratch. We will take care of this in a next version. However, > with the solution today it is possible to turn business processes modelled > with EPCs into executable business services by an automated EPC to BPEL > transformation. Note that you are again talking in process, and not in services as the modelling and driving asset here. > You can re-use those business services again in your > business modelling. In the end, the business service is described by a > business representation (we call this an application system type), a > business process model (EPC), an IT model (BPEL) and of course it > standardised interface (WSDL). As a quick question, can a single service definition contain multiple EPCs or is there a one to one match of service/WSDl to EPC? (N.B. clearly an EPC can invoke several WSDLs but the question is whether one WSDL can describe several EPCs). > > > > 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). > > Well, if you have seen at least a demo of the ARIS tools you know, that we > use many different graphical symbols and that you can place them on various > diagrams. To represent a service, we do not use just an UML object, but also > a so called "application system type" object. Which are at a technical level and not a business level and also do not help when trying to do decomposition (if memory serves me right). > Both objects are connected to > each other so that you can navigate from the business view to the IT view > and the other way around. In addition, we provide with the ARIS SOA Designer > a so called Service Browser. This dialog visualises the services you have in > your repository with the requirements supported by them as well as the data > objects they can handle. Which is a technical tool attached to the WSDLs, not something aimed at the concept of modelling business services. > Important -> the data objects are not the message > types of the WSDL but are business data objects like technical terms or data > clusters. A business expert only uses the application system type object > while modelling. So he is completely independent of the IT view on the > service. Not really because what he is seeing is an abstraction of that IT representation, it is not as if the business expert can create a clearly abstracted hierachy of service and then have a mapping performed elsewhere. Independence would mean that the business expert could model services independently. > > > > 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). > > Well yes, you are talking about creating new services from scratch. In > general, you have to do both. In general you have to define what the business services are from scratch, as this will be the first time it has been done, you then need to map those services onto the existing capabilities (not services) in the IT estate. > You have many infrastructure services (like > sending an email), which you do not have to create again. On the other hand > you have business services orchestrating some of the infrastructure services > (and also some business services). You can describe such a service using > EPCs and transform it later to BPEL. You can describe _some_ services as _collections_ of BPELs/EPCs, but not all business services are best described that way (goal orientation is another style). The challenge here is that you are assuming that services are constructed bottom up, (EPCs co-ordinate infrastructure -> biz service) rather than top-down. > > > > 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? > > It is the ARIS SOA Designer and the ARIS IT Architect (you can combine both > products). SOA Designer allows you to import service descriptions. This > import generates the business and IT view for you. It 100% does not create a business view, it creates a "simpler" picture of the IT view, this isn't the same thing. > However, you probably > will need to structure your service landscape and you can do this with the > IT Architect. For example you can define overall application systems you > have and assign the services exposed by those systems. You can also describe > the hardware infrastructure, so that you can analyse e.g. which business > processes are impacted if a certain server goes down. Are you spotting how this doesn't actually tell me how I model business services from scratch? I don't care about the tin or the existing estate here, I'm talking about the modelling that is done before I worry about the mess that I've got to clean up. What I'm after is something ala CBM (IBM) or my methodology, the modelling of businesses based around a structure of services. > > > > 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. > > Yes, you can't put everything in one paper. This would be too much. We have > methods for this, but not published there yet. It would be great to see that, so far it looks very technically driven :( > > > > > 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" > > Yes, you have to provide such sections, because that's what people know. Nope, anyone who thinks that WS = SOA is wrong, repeating something wrong isn't something that has to be done. > People reading this group are quite advanced in their understanding of SOA. > However, the majority of people out there have not looked so deeply into > SOA. Agreed, but what has been done here is to take a myth (SOA = WS) and then push that line to prove that a product "does" SOA. In some ways you are capitalising on people's ignorance of SOA to help sell a product, which isn't nice. > > > 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" > > Again, this paper represents only a small aspect of our SOA approach. We > will take care of providing more details in further papers with less > marketing bla bla :-) :-) As ever I'd love to see (and am willing to help) a tool that enables a proper business service architecture to be created. I hate marketing departments too :) > > Sebastian >
