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. > 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. 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! 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. 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. 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. 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). > 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. > 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. > 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. Regards, Sebastian
