I have just read (skimmed, really) Scott Ambler's book The Enterprise Unified Process: Extending the Rational Unified Process
. If you are using the Rational Unified Process (from IBM), or considering doing so, and worried about applying it to a whole IT department rather than separate projects then this book could well be useful. The book has four parts - From RUP to EUP, Beyond Development, Enterprise Management Disciplines and Putting it all Together. Each section has several chapters and the chapters all start with a nice reader ROI section (showing the payoff for reading that chapter). The writing is clear, though I did not find it as readable as Refactoring Databases, and there are plenty of diagrams, tables and helpful tips.
The book starts of with some background in the RUP. I particularly liked the description of RUP as serial in the large and iterative in the small. I liked this characterization as the four big phases of RUP (Inception, Elaboration, Construction and Transition) always made me feel that it was too much a waterfall approach. The differentiation between the serial nature of the main phases and the iterative nature of the details helped clarify this nicely. Within the RUP there are also nine disciplines (Business Modeling, Requirements, Analysis and Design, Implementation, Test, Deployment, Configuration and Change Management, Project Management, and Environment). While a review of this book is not the place for a broader discussion of rules in RUP, I would note that RUP does not really handle constant evolution using rules as it assumes that new iterations are new development cycles and it omits discussion of rules, talking only about requirements in elaboration, for instance. I will dig up some material we have on rules and RUP and post it but, for now, suffice it to say that rules are not requirements or code and need to be managed using a new discipline.
Anyway, the authors outline 10 best practices they see as core to the EUP (they extend the original 6 in RUP) and in many I see a role for business rules and for decision management:
- Develop iteratively - and use agile methods and business rules together.
- Manage requirements - but writing better requirements is a false hope so use business rules too
- Proven architecture - business rules are well proven already
- Modeling - they make the point that models need not be graphic and, in this sense, rules are a form of model
- Continuously verify quality - rules are easier
- Manage change - or come to love change
- Collaborative development - Collaborative Business Engineering
- Look beyond deployment - think about change-time
- Deliver working software regularly - rules is great for this
- Manage risk
In addition to the change best practices, EUP adds a Production phase and a Retirement phase. They point out that the Production phase is not just maintenance or just operations and support but both and more. I think that any organization building systems should spend as much time and effort thinking about production and running their application in production (which includes maintaining it over time) as they do in building it and I was glad to see this so strongly proposed. They also added an operations and support discipline, mostly but not entirely in the production phase. This discipline includes running the system and making hot fixes. Clearly this is another area where rules could shine. I think the Retirement phase is overkill for most organizations but some will find it useful.
They also added some "Enterprise Management" disciplines for use outside the context of a project and this too is a good idea. The disciplines (with some thoughts) are:
- Enterprise business modeling
Compliance and business rules are described as important here. While I agree, I do worry that the EUP implies that business rules are only an enterprise documentation thing. I feel that this is one use of rules but that production rules (business rules executed in production systems) are the best way to implement these high level rules. The authors also focused on policies that"stand the test of time" but my experience is that the details may vary a lot. For example, an enterprise rule to "pass postage rates through without a profit margin" has details that change every time the postage rates do. I did like their focus on automating repetitive tasks as I think this leads naturally to a focus on decisions. - Enterprise Portfolio Management
- Enterprise Architecture
I particularly liked the idea that "modifiability" should be considered as part of an enterprise architecture. Far too few organizations do this well and fail to differentiate between stable services and much more changeable ones. - Strategic Reuse
Again I liked the called-out focus on this. Without a real plan no reuse is going to happen. I also like his definition of something not being reusable until it has been used 3 times! to the various kinds of reuse defined I would add rule reuse - People management
- Enterprise Administration
- Software Process Improvement
Another good one. A timely reminder to all that you should keep improving your software processes. Check out this post on lean manufacturing techniques in development too.
Overall I liked the book, though it was a somewhat dry subject (as methodologies often are). There was a lot of good advice, some nice tips and some clearly hard-won experience being shared! You can buy the book here and Scott has posted a bunch of useful information at www.enterpriseunifiedprocess.com and has a manager's overview of RUP here
Technorati Tags: agile, business rules, change time, decision service, Enterprise Unified Process, EUP, Rational Unified Process, RUP, Scott Ambler, requirements
