I just delivered a webinar describing the gaps that exist in classic, CMMI-style approaches to maturity when applied to architecture practices. If you’d like the deck, you can find it here:
Architecture Maturity with Rubrics
I’ll post a link to the recording once it is available on Web Age’s webinar page.
If you’d like to discuss the topic, feel free to comment here or give me a shout at Linked In.
You have many excellent insights on architecture, but “Why Maturity Model Don’t Work in Architecture” doesn’t reflect an understanding of the CMMI model and its use. Have you every actually used the model? You cite as disadvantages:
1. Process-centric. It’s true that you can get the process right but not product good artifacts. CMMI doesn’t claim to be the ONLY thing you have to do to build good systems, just an enabler. 2. Binary. The CMMI is not binary (although it has a top-level scoring system). Anyone who has implemented the model knows that there are over 300 practices which can be implemented at very levels of completeness across none to some to all projects within your organization.
3. Idealistic. Totally false that no firms every actually implement the top levels – please cite the source of your data.
4. Wholesale. It is not a wholesale model, and anyone who has implemented the model knows that each project within an organization can be assessed against the model at various levels. Ever CMMI-implementing organization I know celebrates numerous intermediate milestones.
You have an excellent grasp of architectural concepts and even suggest a process for building a rubric, so you clearly understand the value of process. Also, you favor rubrics, and CMMI is a rubric with criteria and standards, and is primarily used to assess and communciate. Your CMMI bashing comes off naive and disingenuous.
Thanks so much for your feedback Rick. I am a huge fan of dialogue. I’ll address each of your thoughts in turn.
Indeed, I have worked with many organizations both in the public and private sector operating both with and without CMMI process guidance.
OK. So we agree that CMMI is process-centric. Furthermore, we agree that good process does not necessarily produce good artifacts. Now we have to wade into the realm of limited resources and limited attention span of most organizations. They will typically only have budget / patience / focus to do one thing from a maturity perspective. In which case, my argument is that they should do things which focus upon produce valuable architecture outputs.
The trouble is that this is how 90% of the organizations that I work with approach CMMI. It is nearly always used as a litmus test to support contracting and is treated as a ‘go’ / ‘no go’ type of benchmark. While it may be true that is doesn’t have to be done in this way, it is so commonly implemented in this fashion that I find I am working with an uphill battle to try and convince an organization to approach CMMI differently. There is far too much inertia around it already.
Every organization of any size that I have worked with that claimed CMMI 5 accomplished this coveted status by selecting a small division or special project to go through the Herculean effort of operating at level 5 long enough to get the designation. The rest of the organization could not operate at that level and still produce sufficient value to justify their existence. It simply is not practical. Maybe I have just encountered all of the exceptions that prove the rule, but this has been my experience in Defense, Insurance, Telecom, and Energy. Moreover, every architectural maturity model that I have ever seen which is based off of CMMI (and remember that my post is in the context of architecture) depicts a utopian top-level that is unrealistic (see Open Group’s OSIMM, Progress / Sonic’s SOAMM, NAS CIO’s EAMM, etc.).
You are right, it can be done in an incremental and as-needed basis. But in practice, I find this is rarely done when applying CMMI to the realm of architecture. Certainly it can work well when applied to IT process maturity, but I have not seen an organization successfully apply it to gauge the maturity of architecture.
Perhaps I have simply encountered a large number of organizations that have misapplied CMMI in the context of architecture, but I have yet to find one that has done it well. I was not setting out to “bash” CMMI but rather to highlight why it is ill-suited for gauging the maturity of architecture. CMMI has its place and I believe that the emphasis that CMMI places upon process is viable if what you need to do is improve the efficient operation of the IT organization. If, however, your goal is to improve the quality and effectiveness of your architecture outputs, then CMMI is not a strong fit for that. Furthermore, if you have limited resources (time, money, attention, etc.) available to dedicate to maturity activities, then I have found that focusing your efforts towards improving the quality of architecture outputs yields far better results than adherence to a traditional process-centric maturity perspective.