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. > > 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. > > 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 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. 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. > > 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. 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). > > 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. 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. 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. > > 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. 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. > > 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. 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. > > 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 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. 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. > 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 :-) Sebastian
