 |
|
Murray Cantor on RSDC 2006 Dr. Murray Cantor is an IBM Distinguished Engineer and a member of the Rational Software CTO team, focusing on governance and systems development.
Cantor’s areas of expertise include development and IT governance, software and system engineering processes, and system development management and leadership. Cantor was the lead architect of RUP SE, the extension of the Rational Unified Process for system and enterprise engineering. He has been a system architect, team lead, project manager, development product manager, architecture manager, program manager, and lead consultant. Throughout his career, he has focused on the management of large-scale, cross-discipline development efforts.
In addition to numerous articles, he is the author of two books: Object-Oriented Project Management with UML, published by John Wiley in 1998, and Software Leadership, published by Addison-Wesley in October, 2001
|
|
|
Is variance good or bad?
At RSDUC, I gave two talks on the use of statistical variance of program parameters (e.g. cost to complete) as program governance measures. Since variance measures uncertainty and is often equated with risk, we think of variance in as a bad thing. In fact, as I presented in the talks, effective program management consists of working off the variance. This link provides more detail http://www-128.ibm.com/developerworks/rational/library/mar06/cantor/index.html.
I was challenged yesterday by someone who suggested that variance is a good thing. For example, in stock options, the value of the option grows with the variance in the estimation of the price of the stock with the option matures. In applying real options to programs, one discovers that variance can be good as it provides an opportunity for creating value. The value is created by removing the variance in a program.
Hence, variance is bad and needs to be removed in programs. However the ability to accept variance and remove it is good for development organizations. Those organizations create the most value. So, for those organizations who can deal with them, programs with initial high variance may also be good as they provide the opportunity create value.
I hope this is not too convoluted :-)
Jun 08 2006, 04:28:22 PM EDT
Permalink
|
|
SysML - the plan is coming together
On Tuesday at RSDUC, I had meetings with business partners and briefly attended a SysML BoF. Many of you may know that SysML is the 'System Modeling Language', a recently adopted OMG standard for modling systems consisting of software, hardware, workers...
Before the acquisition I led the SysML activity in Rational, working with both OMG and INCOSE interest groups to generate the SysML RFP and was a founding member of SysML Partners, the organization that generated more of the content in the current draft. After the acquisition I passed the Baton to Laurent Balmelli in IBM Research. He was an active and effective member, taking responsibility for the requirements chapter,
In the writing of the RFP and the reviews of the draft, we had several requirements for SysML The partners agreed that the language would be methodology-neutral and would be rich enough to support analysis and simultions required by the system engineering community. In Rational, we monitored the ongoing drafts to ensure the semantics would be rich enough to express the key views in the RUP SE architectural framework and the joint realization mechanism.
Meanwhile, Rational delivered on the Eclipse vision to release tools that provide the means for third parties to add content. Over a year ago, Cory Bialowas and myself visited a small company, Embedded Plus, to discuss their creation of an eclipe based add-on to our modeling tools to support SysML. Since the Cory joined Embedded Plus.
Over the last few weeks, not only has the SysML spec been approved, but also Embedded Plus has announced the the availability for the SysML add-in to the RS(X) family of products. AND, at yesterday's birds of a feather, we have severl business partners to have or will soon be adding analysis and simulation tools to RS(X)using the SysML semantics. In addition, others are adding capability I did not anticipate such as real-time code generation.
For me, it is genuinely exciting to see it all come together. The SysML work has led to just the engineering support we envisioned and more.
Finally, we had other internal discussions on how to move our legacy RUP SE assets to SysML and to ramp up our field. I will share more of this as it comes together.
Jun 07 2006, 05:54:45 AM EDT
Permalink
|
|
Governance, and technical ownership
On Tuesday at RSDUC, I had several discussions on what is governance anyway. Several people jump immediately to various compliance frameworks such as Sarbanes-Oxley. Dealing with compliance is seen as at best a necessary evil; it may be necessary but does nothing for the developer.
Compliance is just an aspect of governance. 'Governance' is about making good decisions on who has the authority to decide what, what measures they use to guide their decisions, and they controls they have to carry out the decisions. Policies may be in place to constrain how the decisions are made. Compliance is documenting that the decisions were made by the appropriate folks following the policies.
When I was a developer and a development manager, I came to realize that developers need clarity about technical authority. Every developer wants and should know what they own. That is, over what parts of the code, design, architecture, test ... do they have decision rights. Clarity of technical authority empowers developers to get on with their work knowing that someone else will not be duplicating their work. It provides clarity to the team in that they know who to go to resolve dependancies. And, everyone knows who to blame when the code breaks the build.
As Martin Nally pointed out in a podcast interview we did Tuesday, developers also want to know that good decisions were made on the requirements and deployment of the code so their work will matter.
Addressing these developer concerns is the result of doing governance well.
Jun 07 2006, 05:23:28 AM EDT
Permalink
|
|
Communities of Interest, Knowledge and Risk
I always come away from RSDUC (aka RUC) with new insights. Danny spoke of communities of interest, integration driven by technology and business trends, and forced complexity. In my presentations, I mentioned how risk is addressed by the extended development team (engineers, developers, stakeholders, managers...) collectively acquire knowledge about the program requirements, architecture, technology, team dynamics... Addressing risk requires effective communities
Yesterday, I realized the importance of focusing on how different communities collaborate to address common development challenges. Examples of communities of interest include software teams whose components need to be integrated into a single application, teams of different engineering disciplines who need to jointly develop a system, and analysts and end users who understand how the business needs to run.
Time after time yesterday, someone mentioned how their problem is not making any given community more efficient, it is how to get the different communities to work together. Client examples include software teams with different legacy processes and communications between the analysts and the developers.
In our extensions of RUP to address systems (RUP SE and Model Driven System Development), we have focused on how the different engineering disciplines and system stakeholders work together. Yesterday, I came to realize that this is an important special case of the general problem. However, I suspect that lessons learned in addressing systems will be useful for helping all sorts of communities of interest collaborate.
Jun 06 2006, 06:48:01 AM EDT
Permalink
|
|
|
| S | M | T | W | T | F | S | | | | 1 | 2 | 3 | 4 | 5 | | 6 | 7 | 8 | 9 | 10 | 11 | 12 | | 13 | 14 | 15 | 16 | 17 | 18 | 19 | | 20 | 21 | 22 | 23 | 24 | 25 | 26 | | 27 | 28 | 29 | 30 | 31 | | | | | | | | | | | | Today |
|
