RDP, Fake it!!

Executive Summary

This paper is an effort to evaluate and draws a comparison between the paper by D L Parnas that discusses on RDP and the Joomla system design process followed by Joomla community. It is also an effort to evaluate the Joomla architecture documented by my team (!Minnows) in context to the RDP as described by Parnas.
One of the defining results of this study is the ability to understand and appreciate the need to fake the design process. This study also provides an insight in improvement areas of! Minnow’s Joomla system architecture documentation like the need to specify interface and behavior completely and concisely along with a need to avoid myopic approach to documenting architecture.
Discussion

D L Parnas and Clements discuss the need to practice the RDP, to the maximum possible extent (fake) for designing a system with the constraints in the view, in any software ecosystem. They very rightly point out that idealization of the process is not possible in most cases, but the importance of following the process cannot be neglected. Joomla system development process is an ideal comparison to the RDP mentioned in [Par86].
Joomla system architecture is a peculiar case of mix and match of “accidental and planned architecture” and also a classic case of “faked rational design process.”
Well planned architectural decisions in Joomla like MVC architecture, Joomla packages & extensions and the framework in Joomla are very well defined and followed to the specifications in the subsequent phases and releases of Joomla; this makes one think of it as a very much inline with the RDP. But blunders like no support for multi vendor databases and continuous security related issues in most releases immediately points to the fact that the system has large amount of accidental architecture and design decisions. All accidental decisions may or may not cause impacts key success factors or cause failure of the Joomla system; but never the less lack of documenting such decisions impacts the continuity planning, conflict resolution and strategic decisions of the Joomla system, which is also pointed out in section 5 in [Par86].
Joomla development community religiously follows the role definitions and task completion criteria, which answer “What kind of persons should do the work?” and “What criteria that work product must satisfy?”; which is also pointed out in the section IV of [Par86]. The same section also discusses the role of planning on the next course of actions and gathering information required for execution; which is the role of the core community in Joomla. The core community is dedicated to and responsible for envisioning, planning, risk approaches and steering as mentioned in the phase 1 and phase 4 of our documentation.
Critical Analysis

When trying to analyze and compare the RDP described in [Par86] section V to the Joomla system design process; one of the first observations is that the product requirements are not documented upfront. On the contrary, designing and documenting the module structure is religiously followed by the Joomla community and was also followed by us when documenting the architecture. Joomla viewpoints, views and view packets in first three phases deliverables along with the packages mentioned in the last phase provided a really good insight into the module structure of the Joomla system. But one of the things that I think we can improve on is the interface and behavior documentation of Joomla system to describe the architecture of Joomla in an articulate manner. The documentation of Joomla severely suffers with what Parnas defines as Myopia and some of which also influenced our architecture documentation in project phases. This is another thing that I think we can improve on in our architecture.
As most open source systems, Joomla has also evolved substantially over the years due to core community members who decided to start simple and evolve as the system grows following the principle of YAGNI. This does not however mean that Joomla community doesn’t recommend using RDP or does not follow RDP, what they don’t recommend is idealization of RDP (sequential approach with check pointing). Non-idealized (fake) and non-sequential approach to RDP enables agility and a better evolution of the system allowing the system to grow.
Conclusion

Fake it, Don’t idealize the RDP!!
Figure 1: Context independence vs. Understanding

To summarize, I would like to take systemic thinking approach to RDP. Above diagram which is also one of the adopted approaches for Joomla system design process, depicts the context independence vs. understanding [1]; clearly shows that a system evolves only after certain amount of effort and iterations of implementations and cannot be envisioned, architected or designed upfront. The diagram depicts the concept of system evolution; explaining that the first level of gathered input is always data, which after evolution provides information; which by understanding the patterns provides knowledge of the systems real drivers and success factors, and further evolution by understanding the underlying principles makes a system which has the potential success drivers. This state is called Wisdom by the community. This I think is also inline to Parnas’s argument about “allowing a system to grow by faking it” and following RDP as much as possible with the constraints and ecosystem in context.
To conclude, it is not feasible for a system like Joomla! to follow RDP in an idealized manner but it definitely is possible and in fact a necessity to make a genuine effort to follow the RDP as much as possible. Understanding the difference between ideal and fake RDP will be a defining factor for the success in most current and future software systems.
Future Trends
Gartner has recently published a report that SOA [2] are failing due to “idealization” of design process, lack of evolution of system architectural processes and lack of correct governance. This is something that Parnas points out in his paper accurately assessment and provides a guideline RDP which should be faked and not idealized.
Bibliography
[Par86]
A rational Design Process: How and Why to Fake It by DL Parnas & Clements

[1] Systemic Thinking on Knowledge Management http://www.systemsthinking.org/kmgmt/kmgmt.htm

[2] Bad Technical Implementations and Lack of Governance Increase Risks of Failure in SOA Projects
Glossary
RDP - Rational Design process
SOA – Service Oriented Architecture
YAGNI – You Aint Gonna Need It