Archive
The Vault Of No Return
In big system development projects, continuous iteration and high speed error removal are critical to the creation of high quality products. Thus, it’s essential to install flexible and responsive Configuration Management and Quality Assurance (CMQA) support systems that provide easy access to intermediate work products that (most definitely) will require rework as a result of ongoing learning and new knowledge acquisition.
As opposed to virtually all methodologies that exhort early involvement of the CMQA folks in projects, I (but who the hell am I?) advise you to consider otherwise. If you have the power (and sadly, most people don’t), then keep the corpo CMQA orgs out of your knickers until the project enters the production phase. Why? Because I assert that most big company CMQA orgs innocently think they are the ends, and not a means. Thus, in order to project an illusion of importance, the org creates and enforces Draconian, Rube Goldberg-like, high latency, low value-added, schedule-busting procedures for storing work products in the vault of no return. Once project work products are locked in the vault, the amount of effort and time to retrieve them for error correction and disambiguation is so demoralizing and frustrating that most well-meaning information creators just give up. Sadly, instead of change management, most CMQA orgs unconsciously practice change prevention.
The figure below contrasts two different product developments in terms of when a CMQA org gets intertwined with the value creation project pipeline. The top half shows early coupling and the bottom half shows late coupling. Since upstream work products are used by downstream workgroups to produce the next stage’s outputs, the downstreamers will discover all kinds of errors of commission and (worse,) omission. However, since the project info has been locked in the vault of no return, if the culture isn’t one of infallible machismo, upstream producers and downstream consumers will circumvent the “system” and collaborate behind the scenes to fix mistakes and clarify ambiguities to increase quality. If and when that does happen, the low quality, vault-locked information gets out of synch with the informal and high quality information in the pipeline. Even though that situation is better than having both the vault and project pipeline filled with error infested information, post-delivery product maintenance teams will encounter outdated and incorrect blueprints when they retrieve the “formal” blueprints from the vault. Bummer.
Distributed Vs. Centralized Control
The figure below models two different configurations of a globally controlled, purposeful system of components. In the top half of the figure, the system controller keeps the producers aligned with the goal of producing high quality value stream outputs by periodically sampling status and issuing individualized, producer-specific, commands. This type of system configuration may work fine as long as:
- the producer status reports are truthful
- the controller understands what the status reports mean so that effective command guidance can be issued when problems manifest.
If the producer status reports aren’t truthful (politics, culture of fear, etc.), then the command guidance issued by the controller will not be effective. If the controller is clueless, then it doesn’t matter if the status reports are truthful. The system will become “hosed”, because the inevitable production problems that arise over time won’t get solved. As you might guess, when the status reports aren’t truthful and the controller is clueless, all is lost. Bummer.
The system configuration in the bottom half of the figure is designed to implement the “trust but verify” policy. In this design, the global controller directly receives samples of the value streams in addition to the producer status reports. The integration of value stream samples to the information cache available to the controller takes care of the “untruthful status report” risk. Again, if the controller is clueless, the system will get hosed. In fact, there is no system configuration that will work when the controller is incompetent.
How many system controllers do you know that actually sample and evaluate value stream outputs? For those that don’t, why do you think they don’t?
The system design below says “syonara dude” to the global omnipotent and omniscient controller. Each producer cell has its own local, closely coupled, and knowledgeable controller. Each local controller has a much smaller scope and workload than the previous two monolithic global controller designs. In addition, a single clueless local controller may be compensated for if the collective controller group has put into place a well defined, fair, and transparent set of criteria for replacement.
What types of systems does your organization have in place? Centrally controlled types, distributed control types, a mixture of both, hybrids? Which ones work well? How do you see yourself in your org? Are you a producer, a local controller, both a local controller and a producer, an overconfident global controller, a narcissistic controller of global controllers, a supreme controller of controllers who control other controllers who control yet other controllers? Do you sample and evaluate the value stream?
Lesson Unlearned
Whoo hoo! We finally said screw it, we overcame our fears, and we mustered enough courage and determination to say “hasta la vista baby” to the stifling corpo citadels that we were shackled to. We huddled together, we created a flexible plan, we busted the cuffs, we scaled the prison wall, and holy crap; we actually freakin’ succeeded. We started our own company. And it’s growing. And our people feel useful and appreciated. And life is good. Ahhhhhhh!
Well duh, of course we need to track and manage revenues and costs, but in our company, unlike the herd we left behind (mooo!), those two obviously important metrics will always take a back seat to taking care of, and leading the people who create, develop, build, and sustain our product portfolio. Because we’ve personally experienced living in the quagmire, we’ve learned our lesson. We get “it” and we’ll never forget “it”. There’s no way, we mean no way, that we’re not gonna end up like our previous corpo hierarchs, who managed to turn it all backasswards – numbers first and people second (even though they innocently espoused the opposite).
Ummmm, yeah…… right. Check out the two parallel timelines below that purport to track the growth and maturity of a hypothetical startup company in the technology industry. I honestly don’t know squat, but I assert that the story reflected by the graphical depiction below is pervasive and ubiquitous, especially throughout the western world. If you could possibly be delirious enough to resonate with the content of this blarticle, then you may interpret the situation as a hopelessly sad state of affairs. Believe it or not, I interpret the situation as neither good nor bad. It just is what it is.
UML and SysML Behavior Modeling
Most interesting systems exhibit intentionally (and sometimes unintentionally) rich behavior. In order to capture complex behavior, both the UML and its SysML derivative provide a variety of diagrams to choose from. As the table below shows, the UML defines 7 behavior diagram types and the SysML provides a subset of 4 of those 7.
Activity diagrams are a richer, more expressive enhancement to the classic, stateless, flowchart. Use case diagrams capture a graphical view of high level, text-based functional requirements. State machine diagrams are used to model behaviors that are a function of current inputs and past history. Sequence diagrams highlight the role of “time” in the protocol interactions between SysML blocks or UML objects.
What’s intriguing to me is why the SysML didn’t include the Timing diagram in its behavioral set of diagrams. The timing diagram emphasizes the role of time in a different and more precise way than the sequence diagram. Although one can express precise, quantitative timing constraints on a sequence diagram, mixing timing precision with protocol rules can make the diagram much more complicated to readers than dividing the concerns between a sequence diagram and timing diagram pair. Exclusion of the timing diagram is even more mysterious to me because timing constraints are very important in the design of hard/soft real-time systems. Incorrect timing behavior in a system can cause at least as much financial or safety loss as the production of incorrect logical outputs. Maybe the OMG and INCOSE will reconsider their decision to exclude the timing diagramin their next SysML revision?
SYSMOD Process Overview
Besides the systemic underestimation of cost and schedule, I believe that most project overruns are caused by shoddy front end system engineering (but that doesn’t happen in your org, right?). Thus, I’ve always been interested and curious about various system engineering processes and methods (I’ve even developed one myself – which was ignored of course 🙂 ). Tim Weilkiens, author of System Engineering with SysML/UML, has developed a very pragmatic and relatively lightweight system engineering process called SYSMOD. He uses SYSMOD as a framework to teach SysML in his book.
The figure below shows a summary of Mr. Weilkiens’s SYSMOD process in a 2 level table of activities. All of SYSMOD’s output artifacts are captured and recorded in a set of SysML diagrams, of course. Understandably, the SYSMOD process terminates at the end of the system design phase, after which the software and hardware design phases start. Like any good process, SYSMOD promotes an iterative development philosophy where the work at any downstream point in the process can trigger a revisit to previous activities in order to fix mistakes and errors made because of learning and new knowledge discovery.
The attributes that I like most about SYSMOD are that it:
- Seamlessly blends the best features of both object-oriented and structured analysis/design techniques together.
- Highlights data/object/item “flows” – which are usually relegated to the background as second class citizens in pure object-oriented methods.
- Starts with an outside-in approach based on the development of a comprehensive system context diagram – as opposed to just diving right into the creation of use cases.
- Develops a system glossary to serve as a common language and “root” of shared understanding.
How does the SYSMOD process compare to the ambiguous, inconsistent, bloated, one-way (no iterative loopbacks allowed), and high latency system engineering process that you use in your organization 🙂 ?
Dweeb In the Cellar
Check out the figure below and please heed the advice it dispenses. If you’re a Dweeb In the Cellar (DIC), don’t piss off the people in the highlighted boxes above you. As a DIC, you can (almost) safely piss off anyone else in the corpo caste system. However, each cookie cutter corpo command & control hierarchy is slightly, just slightly, different. For example, if your direct boss and one of his level 1 peers are great friends, you can’t piss the friend off either. As you might guess, it’s usually OK to piss your fellow DICs off, but again, each corpo org is slightly different.
Pray Or Play
Do you follow the rulebook and worship at the altar of the corpo pyramid, or do you break the rules in defiance of the chain of command to get stuff done in a timely fashion and add value to your organization? To some extent, everyone has to obey some basic ground rules so that chaos won’t reign, but do you question those rules from time to time to evaluate whether they’re still applicable? Do you experience pangs of fear when you ask tough questions that “aren’t supposed to be asked”? How do you ask a tough question without implying that someone is being ineffective? As just another dweeb stuck in a vertical silo at the bottom of the corpocracy, how can you point out cross-silo communication problems without pissing “important” people off? Do you faithfully, quietly, and unquestioningly sit behind the pew and pray, or do you at least try to play – in spite of the chance of incurring a potential career ending injury?
Directagers
Director of communications, director of operations, director of engineering, director of marketing, director of strategy. Yada, yada, yada. Everyone is, or wants to become, a “Director” of something. The ultimate directorship, of course, is to be elected to sit on one or more cushy Boards Of “Directors”.
Not discounting the title of “Chief”, the title of “Director” seems to have overtaken “Manager” as the coveted corpo title dujour. Compared to an honorable and esteemed “Director”, a “Manager” is now almost as unimportant as an “associate”, or equivalently, an “in-duh-vidual contributor” (gasp!). The title of “Manager” is……. so yesterday.
So what’s the next title to be inserted into the divisive corpo caste system, the “Directager“? Come on, take a guess.
Bend It Like Fowler
Remember the popular soccer movie “Bend It Like Beckham“? Well, I like to “Bend it like Fowler”. Martin Fowler, that is. In his terrific book “UML Distilled“, Martin recommends bending the UML when you need to communicate some application-specific design information and you’re not a UML language lawyer. Rather than leaving an important snippet of information out of your model because you don’t know how to capture it via a language formality, do whatever it takes to record it. It’s the stuff that falls through the cracks which causes downstream schedule delays and rework.
As a survivor of the structured analysis CASE (Computer-Aided Software Engineering) tools fad of the 80s, I’m leery of the expensive automated UML and SysML tools on the market today (Telelogic‘s Rhapsody and Artisan Studio come to mind). I think that both the UML and SysML are great languages for communicating a shared understanding of analysis and design information across a diverse team, but unlike general vector-based drawing tools (e.g. Microsoft Visio), language-specific tools are “handcuffers“. They usually require you to be a language lawyer and they force you to be syntactically and semantically correct or else your model won’t “compile“. Being goaded by a piece of software into spending a ton of time looking up and learning some obscure and arcane language detail when you’re under schedule pressure to produce output is not kool. I think that’s the reason why the 80s CASE tool push failed, and it may be why the UML/SysML tools won’t take hold (without coercion) in the mainstream now.
Disclaimer: I’ve dabbled with, but haven’t actually used one of the big, formal UML/SysML tools on a “real” project, so I’m just pulling this stuff out of you-know-where. Thus, don’t believe a word I say 🙂 .
SysML Resources
Unlike the UML, the SysML has relatively few books and articles from which to learn the language in depth. The two (and maybe only?) SysML books that I’ve read are:
System Engineering With SysML/UML: Modeling, Analysis, Design – Tim Weilkiens
A Practical Guide to SysMLThe Systems Modeling Language – Sanford Friedenthal; Alan Moore; Rick Steiner
IMHO, they are both terrific tools for learning the SysML and they’re both well worth the investment. Thus, I heartily recommend them both for anyone who’s interested in the language.
The books’ authors take different approaches to teaching the SysML. Even though the word “practical” is embedded in Friedenthal’s title, I think that Weilkiens book is less academic and more down to earth. Friendenthal takes a method-independent path toward communicating the SysML’s notation, syntax and semantics, while Weilkiens introduces his own pragmatic SYSMOD methodology as the primary teaching vehicle. Weilkiens examples seem less “dense” and more imbibable (higher drinkability :-)) than Friedenthal’s, but Friedenthal has examples from more electro-mechanical system “types”.
What I liked best about Weilkiens’s book is that in addition to the “what”, he does a splendid job explaining the “why” behind a lot of the SysML notation and symbology. You will easily conclude that he’s passionate about the subject and that he’s eager to teach you how to understand and use the SysML. Friedenthal’s book has an excellent and thorough SysML reference in an appendix. It’s great for looking up something you need to use but you forgot the details.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 