About Renowned RUP contd.

How to evaluate a project as best fit for RUP or not, what alterations will be required to follow RUP and Agile at iteration levels....remember the questions I had in mind! Today, I found a case of mid-sized financial institutions, adopted the RUP and wanted to tailor it with Enterprise Management concepts from the EUP, in particular they wanted to ensure that the Inception phase and Elaboration phase efforts of individual projects were supported by enterprise-level requirements, architecture, and reuse efforts. This case has also elaborated upon the alterations that can be done to RUP to make it a success. The writer has described very clearly how they started and what support did they get from the management. They were able to get ahead with the inception and elaboration phase when the issues actually started. Please refer to the following link :

http://www.agilemodeling.com/essays/agileModelingRUP.htm#CaseStudy

I have been hearing about SOA from some time, so here comes again a puzzle of my mind: How good is to adopt RUP for SOA Methodology? But Fortunately, I didn’t have to wait too long for this answer; I found it the same night. Eric Roch, a chief technologist for SOA Methodology has a same question on one of the SOA blogs to which he answered and said

While it's possible to run SOA projects in an XP fashion, major concern is that the lack of rigor can lead to an incomplete or inconsistent process around business domains (how they are linked to form composites), the common information model (schemas representing common business objects), and interface design specifications. Since these deliverables become the basis for future reuse, process consistency is critical. It is possible to create lightweight instance of RUP as the SOA methodology for design deliverables. RUP's iterative nature and focus on architecture early in the process are well-suited for SOA. The key to success is to keep the process lightweight and iterative.

What you want to avoid though the methodology is the lack of standards being a barrier to reuse. You don't want to go back and have to look at code to determine what a service does or try to decipher an XML schema to understand its semantics. This is where a set of minimum design deliverables become most valuable. It is much easier to look at a one or two page use case to understand what a service does and a sequence diagram to understand service invocation than to look at code.

All set for getting started but you need to think about what documentation you will leave behind for future developers who wish to use your services. They must at least know that the service exists, what it does and what is the meaning of the data it uses.”

Further, he agrees to the argument that it is impossible to understand a holistic view of the end goal of enterprise-wide SOA. But it is possible to decompose SOA into manageable domains with a strategy to integrate domains and means to handle schema and interface changes through versioning. Hence, he firmly suggests that, Services documentation should include a system level use case, a UML sequence diagram to detail the SOAP message interactions (even if they are simple request and replies there are often exception messages), an annotated XML schema and the semantics for message transformation (from an external canonical message to an internal native format) if transformation is required. It really does not take much time to create these deliverables and they promote the reuse of your services.