New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Shane Hastie on Feb 20, 2010
The Rational Unified Process® (RUP®) was developed through the 1990's as a framework for software engineering best practices. Key features such as iterations, simplicity, focusing on value and regular feedback were identified as being important for successful software engineering. With the RUP as a starting point a number of authors have built methodologies that adapt UP to different project domains.
Image source: http://en.wikipedia.org/wiki/File:Development-iterative.gif
As well as the core disciplines the RUP® defines supporting the disciplines of Configuration & Change Management, Project Management and Environment Support. More detail about the RUP® can be found here
Agility, for a software development organization, is the ability to adapt and react expeditiously and appropriately to changes in its environment and to the demands imposed by this environment. An agile process is one that readily embraces and supports this degree of adaptability. So, it is not simply about the size of the process or the speed of delivery; it is mainly about flexibility. In this article, I will explain how the Rational Unified Process® (RUP®) is a process framework that allows this flexibility.
The Essential Unified Process
The Essential Unified Process (EssUP) is a collection of practices that together form the essential knowledge of a complete software development lifecycle. This practice-centric approach to software development incorporates and builds on established best practices. The practices in EssUP integrate successful principles from the unified process, agile and process maturity camps, capitalizing on their different capabilities: structure, agility and process improvement
The ESSUP is delivered as a set of Essential Practices, freely downloadable documents describing each of the practices as a set of Things to Produce, Things to Do and Key Competencies, with descriptions and guidelines for each one.
OpenUP - a lean Unified Process
OpenUP also defines a set of Processes, Practices, Roles, Work Products and Tasks that are needed for delivery of a software project. OpenUP is deployed as an Eclipse Process Framework (EPF)
OpenUP is a lean Unified Process that applies iterative and incremental approaches within a structured lifecycle. OpenUP embraces a pragmatic, agile philosophy that focuses on the collaborative nature of software development. It is a tools-agnostic, low-ceremony process that can be extended to address a broad variety of project types.
According to an article in Methods & Tools describing OpenUP by Bjorn Gustafsson
EPF is an open-source initiative that was started in 2006 with contributions by IBM Rational of parts of their RUP content and technology. Since its inception the project has actively involved more than 20 companies, and the first release was made available in September of 2007. Despite being an Eclipse project, EPF can be used to create process descriptions for any type of development, including J2EE on Eclipse or .NET using Microsoft Visual Studio.
In the article he explains the background to the EPF and how OpenUP is deployed. He concludes:
The new OpenUP process synthesizes the best practices from RUP and Agile methods into a light-weight and agile alternative to both. Given its RUP roots, it provides a process that is iterative and incremental, use-case driven, risk-driven, and architecture-centric, which at the same time supports the work habits of agile projects. The OpenUP process features practices suitable for many projects right out-of-the-box, but it also provides the basis for adding 3rd party and proprietary practice extensions, using the EPF Composer tool, to tailor the most appropriate process for each project
Enterprise Unified Process
Another derivative of the RUP® is Scott Ambler’s Enterprise Unified Process
Whereas the RUP defines a software development lifecycle, the EUP extends it to cover the entire information technology (IT) lifecycle. The extensions include two new phases, Production and Retirement, and several new disciplines: Operations and Support and the seven enterprise disciplines (Enterprise Business Modeling, Portfolio Management, Enterprise Architecture, Strategic Reuse, People Management, Enterprise Administration, and Software Process Improvement).
is a simplified version of the Rational Unified Process (RUP). It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. I've tried to keep the Agile UP as simple as possible, both in its approach and in its description. The descriptions are simple and to the point, with links to details (on the web) if you want them. The approach applies agile techniques include test driven development (TDD), Agile Model Driven Development (AMDD), agile change management, and database refactoring to improve your productivity.
On the website he explains the differences between the RUP disciplines and the AgileUP disciplines.
These are some of the variations and derivatives of the Unified Process.
Do you use one of these products, what have your experiences been, and how do they fit in the Agile world?
Shane Hastie is an agile coach, trainer and consultant working for Software Education in Australia & New Zealand
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Case Study: IBM's Agile Transformation
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
...but I'm still confused. I've helped a few teams recover from RUP implementations gone bad. Yes it is possible to good RUP but why would anyone do it? We've Scrum, Crystal, Open Agile, Lean, Kanban - all of these are innovative, why would anyone start with a RUP/ARUP etc. project today?
I open to hearing good reasons.
Cheers
Mark Levison
Agile Pain Relief Consulting
Mark,
I sympathise with your experiences of "RUP gone bad", but equally I have seen many "Agile gone bad" scenarios too.
We all know that we need to maintain a focus on people and their interactions over any process and tools, but your statement that "We've Scrum, Crystal, Open Agile, Lean, Kanban - all of these are innovative" highlights the most common issue:
People don't know what's good for them, and sometimes there is just too much choice.
This is what RUP originally set out to overcome, by providing a customisable framework of practices for people to choose from. Unfortunately, it became so large that few people knew how to scale-back to what they really needed. Hence the numerous "RUP gone bad" examples.
However, in the world of Unified Process described above there has been one particular "flavor" that has tried to address these issues: OpenUP.
Being a "lean" approach that also includes the best of Scrum, XP, and other Agile methods, OpenUP gives you an essential "kernel" and some optional practices for your project team.
So, and in answer to your question, I would suggest that OpenUP is an excellent starting point for a project, particularly if they are inexperienced in process selection, and they want to benefit from the opportunities to scale Agile practices to the challenges that many projects face, such as distribution, regulation, and size.
Cheers,
Julian Holmes
Unified Process Mentors
Julian - interesting points
I sympathise with your experiences of "RUP gone bad", but equally I have seen many "Agile gone bad" scenarios too.
Good point about "Agile Gone Bad", I have seen Agile gone well, my problem I've never seen RUP gone well and was associated with one attempt to implement it that created way too many work products that where write only. I've no doubt that RUP has been well I've just never seen it - even when I was inside IBM.
We all know that we need to maintain a focus on people and their interactions over any process and tools, but your statement that "We've Scrum, Crystal, Open Agile, Lean, Kanban - all of these are innovative" highlights the most common issue:
People don't know what's good for them, and sometimes there is just too much choice.
Yes but that's why you hire a good coach or consultant. Realistically most people pick Scrum by default (because they don't about the others), so I don't buy the claim of too much choice.
This is what RUP originally set out to overcome, by providing a customisable framework of practices for people to choose from. Unfortunately, it became so large that few people knew how to scale-back to what they really needed. Hence the numerous "RUP gone bad" examples.
However, in the world of Unified Process described above there has been one particular "flavor" that has tried to address these issues: OpenUP.
Being a "lean" approach that also includes the best of Scrum, XP, and other Agile methods, OpenUP gives you an essential "kernel" and some optional practices for your project team.
So, and in answer to your question, I would suggest that OpenUP is an excellent starting point for a project, particularly if they are inexperienced in process selection, and they want to benefit from the opportunities to scale Agile practices to the challenges that many projects face, such as distribution, regulation, and size.
I will have to look into it - although I'm interested in knowing why it offers more than Vodde and Larman.
Cheers
Mark Levison
Agile Pain Relief Consulting
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
3 comments
Watch Thread Reply