End to an Old and Beginning of a New Countdown

A Year that was... A Year to be... A Year of hopes... A Year for a new beginning... A Year to usher... A Year to venture... A Year of delight... A Year that we invite... A Year of fresh Dreams... A Year that sure gleams... A Year of promises... A Year of surprises... A Year of joy... A Year to enjoy... A Year to forget all the pain... It is A New Year Again!! A Year that is here... Wishing You A Happy New Year!!

A new year has arrived, months, dates and days will repeat in their respective cycles. Last year has shown a flipside of the booming economies. Crashing moment of the year has been the one and only economic meltdown that took the US economy to standstill and other dependent economies to run for their survival. Everything changed with the blinking of eyes. Everyone seen newspapers flooded with the news of Lehman Brothers going Bankrupt, reasons, pitfalls and consequences. I know it was not just that but a lot more of which we have not been aware of. I have heard from people (my acquaintances) telling me that there is just few banks who came into the limelight but there were other 100s of financial institutions that turned bankrupt in US. One can found it similar to the crashing of a building floor by floor with each passing day. Bad news being followed by Good News has always kept us hopeful. Hence, after the hard hit everyone is doing whatever they can. Lets talk abt INDIA now, running through tough times. Somewhere in mid Jan.2008, it was presumed and informally declared that India will be showing a 9% growth rate, cannot be dreamt of. Though, India is facing only the slowdown not the recession but the Toughest times are here. Mantra for current life is “SURVIVAL OF THE FITTEST”
So, do not lose hope and strive hard to party harder. Lets all hope that this new year comes with a new beginning. But not to forget, Learnings from the past are must to turn your future from bitter to Better to the BEST.

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.

About Renowned RUP

Talk of developing software which will do a list of things, all verbal and what runs next is how to go about developing it. Let start implementing... but wait ..is it the right way I am heading to. Really not, atleast this was not what I have been studying. There is term I remember i.e. Software Methodology, means framework for structuring, planning and controlling the process of developing software. Next strikes you is Waterfall model, the most heard and the most cursed J. People thought of building software like constructing a building and devised the above model. Recently , I studied RUP (rational Unified Process) , another software development and methodology. At first glance to it, it again looks like an abstract layer of waterfall model like any other methodologies look like. There are drawbacks of Waterfall model but at micro level of any methodology, we are actually following the sequential steps of waterfall model only. It is just same as adding abstract classes in java so that can be defied or altered according to the changing needs.

RUP contains 4 phases, 9 disciplines, key principles and some concepts. Then in the next round, I studied about Agile Methodology. I have carried out a project following Agile Methodology and hence it was very easy to relate what was being explained. I was at ease relating all the concepts of user stories in Agile Methodology to relate with the ones I created.

On a higher level, following is the RUP Vs Agile deeds

Although RUP is iterative, it follows the phases of inception, elaboration, construction, and transition in a more or less linear fashion. As the development proceeds less time is spent on requirements and analysis, and more time is spent on construction, testing, and transition. Agile processes on the other hand, spend time on each activity in each iteration. During each iteration (usually 2-4 weeks) a little of all steps (requirements, analysis, design, development, test, etc.) are undertaken. The goal is to have stable software which could be shipped at the end of each iteration. At the beginning of each iteration, all stakeholders meet to reorganise requirements and their priorities, while at the end of the iteration, working software is demonstrated to the stakeholders. This ensures that customer value is being added at all times, and that progress is being made on what matters, working software.

RUP is quite comprehensive, and were designed to be modified to suit the project being developed. This adds another layer of complexity to the development effort, as the process has first to be modified before being implemented. While this allows for the flexibility to use RUP on any project, it requires teams to have access to RUP experts to ensure that the process is being defined and used properly. Agile on the other hand tends to be used for small to medium sized projects involving teams up to 10 closely knit developers. Once teams become bigger than this, agile methodologies begin to fail, as they don’t scale to large teams, or teams spread across geographies.

But what stuck in my mind was the RUP Vs Agile. I was not interested in knowing the known theoretical things about the Vs issue but what would have interested me was what kind of projects will be perfect for RUP or Agile, how to evaluate an project as best fit for RUP or not, What alterations will be required to follow RUP and Agile at iteration levels??