Live from BAWorld: What To Do With Interfaces

Mary Gorman from EBG Consulting presented “Integrating Interface Analysis into your project: Just-enough, Just-in-time”. This talk was one of the advanced topics, with the intent of teaching about how to do interfaces – software, hardware, and user interfaces. I’m going to capture some summary points from her talk, either the key points or the ones I found most important:

1. She talked about just-in-time interfaces, specifically of interest is that idea that you can identify interfaces early in the project (first days even). A lot of projects wait on these, but there is no reason for that and you may miss things if you wait.
2. Do just enough. In some cases you can do minimal formal documentation, just enough to build and demonstrate the system, whereas other times you need very formal structured documents.
3. Business rules are at the center of all models. They are used by all models, and you will discover them in most models.

Mary talked about interfaces in various types of projects. For example in COTS projects, interface work is usually not about the user interfaces, but rather more about system-to-system interfaces since the COTS software has to integrate. When working on a project to update a system, existing interfaces have to be looked at for updates, and new interfaces or users might be added.


And she points out that a nice bonus from working on interfaces is that you also will likely improve your user requirements – by finding new users, new stories, incomplete stories (missing interactions), missing data attributes, and missing business rules.


My favorite part of this talk is that Mary used a role playing exercise in which people played different systems or the customer, and they used a ball that was tossed around to represent data passing between systems. She used it today to demonstrate the concept, but I talked with her afterwards and she does in fact use this technique for eliciting interface requirements.

I was excited to attend this talk because I have a lot of respect for Ellen and Mary from EBG, they seem to know a lot about practical things about requirements (as compared to a lot of the speakers who talk so high-level it's not usable material). They have some good books and whitepapers to learn from outside this forum if you haven't read them.

Signing Out from INCOSE 2008

Well, I hate to say it, but my week here at INCOSE 2008 has come to an end. And though I must say goodbye to my INCOSE friends, I'm not headed home quite yet - first I will enjoy a few days in Amsterdam, just up the road from Utrecht.


A few final comments from this side of the pond (some of these are purposefully non-INCOSE related to keep it interesting!):

• After hours of listening to talks about process, I have to say - systems engineering processes are heavy! There are images dancing in my head of things like a project plan circle diagram that even in a 3x3 foot printout, you have to squint to read the tasks. Or there are the matrices that don't even come close to fitting on a page, yet they try to squeeze them in for demonstration of a concept.
• I spoke with some systems engineers who, when I explained what Seilevel does, said things like "Really? Requirements as a job?" or "You have a business around that?" or "I never thought of them as a separate thing, they were just some other task on my project that maybe got done." or my favorite "Why are you at a systems engineering conference then?"
• It's a small world. In a city of more than a million, today I ran into a fellow INCOSE member from San Antonio, TX on my way back from the Rijksmuseum.
• Most all of the presenters like to use words on slides! Seriously, I almost think it must have been in the presentation requirements - "Must have wordy slides". Perhaps I can suggest Beyond Bullet Points.
• I enjoyed reconnecting with my friends from what I like to call "Seilevel Europe", the HOOD Group (and mind you, they would and should probably call us "HOOD Group USA"). We have very similar companies, with similar methodologies, in different parts of the world. If you haven't heard of them, I encourage you to take a look at their work.
• Sadly, Holland just lost in the quarter finals of the Euro 2008. I say sadly because I've actually become quite fond of watching the "Oranje" games (or maybe just the crowds hanging outside of bars).
• I once again was reminded that so many Americans have a tendancy to focus on just us. This is by no means a generalization though. I personally like to intermix with those from other countries, though I'm also quite guilty of speaking American and little else. Anyway, it was frustrating to listen to talks from Americans who would only quote American statistics, or American events, or American disasters. My European friends were quick to point it out for me "Oh another American talk!". Thankfully some of the talks were very different than that though, making me much more proud.
• We should do more peer reviews, but not for the obvious reasons. A systems engineering organization requires team members to be on peer review boards, not so much for improving the quality of the deliverables, but more importantly, to expose the engineers to more projects and ideas that they can then apply to their own projects. Brilliant, I say!
• The field of systems engineering has many many many outstanding success stories, ranging from the Airbus 380 to the ProRail system of the Netherlands. There are lots of great lessons to be learned here that can be applied to much simpler projects. But really, how cool would it be to build a network of thousands of kilometers of rail or to put a new airplane in the air?

Anyway, in a few days, I will return home with many fond memories of the Netherlands and INCOSE 2008.

INCOSE 2008 - Can You Build an Airplane with an Agile Approach?

With all of the buzz about Agile, I have to mention that here at INCOSE 2008, I did not hear a single mention of it (except when I asked about it directly!). Actually, that’s not true, at one point I was excited to see a speaker’s slides which referenced applying agile processes as a step in a project. Then he spoke to the slide and I started to suspect he meant agile in the pure definition of the word, to move quickly. At the end, someone asked him the specific question as to whether he meant the agile software methodology and he clarified that he did not. So I left the conference wondering - with all the discussions about processes at a conference like this, why are they not ever speaking about agile?

Airplanes Are Not Software Requirements

My first guess - this probably relates to some of the core differences between systems and software engineering. I am going to over simplify this and just say that it is about scale. Systems projects are just a superset of software and hardware projects, integrating and deploying some combination of these. The teams of people deploying systems projects are quite large. And many of the projects discussed here are for government or regulated systems where specification and traceability is necessary. I could see how subsets of systems projects could in fact be developed using agile (pure software components), but I’m not convinced that an entire end-to-end project can. To put this in context, imagine you are building an airplane - a very commonly referenced type of systems engineering projects. Can you see this working using agile?

All skeptism aside, I do think that iterative development most certainly could work well on systems projects, and most people here would not argue that. In fact, I would love it if we could find examples of agile working on systems projects, because the number one feeling I get at systems engineering conferences is a craving for lighter processes.

I decided to do a little research outside the conference walls, and low-and-behold, I found a great article on this exact topic – “Toward Agile Systems Engineering Processes” by Dr. Richard Turner of the Systems and Software Consortium. The article is very well laid out, and I highly recommend reading it. He defines what agile is and what he believes the issue why most systems engineering projects are not agile. For example, he suggests that executives and program managers tend to believe that the teams involved have perfect knowledge about systems we are building, so we can plan them out in advance and work to a perfect execution against a perfect schedule.

Agile Can Work With Complex Systems

He talks to how to the agile concepts can work in systems projects. Here are a few examples summarized from his article:

• Learning based: The traditional V-model implies a one-time trip through, implying one time to re-learn. However, perhaps the model can be re-interpreted to allow multiple iterations through it to fulfill this.
• Customer focus: Typically systems engineering processes do not support multiple interactions with the customer throughout the project (just up front to gather requirements). That said, he references a study indicating the known issues with that on systems projects. Therefore, perhaps processes should be adapted to allow for this, particularly allowing for them to help prioritize requirements throughout projects.
• Short iterations: Iterations are largely unheard of because the V-model is a one-time pass through the development lifecycle. That said, iterations of prototyping through testing could be done in systems engineering in many cases. The issue is in delivering something complete at the end of each iteration. He suggests that this is not as important to the customer in large deployments as is reducing risk, validating requirements, etc. This is a great point to rememember the airplane example! Could we have even a working part of an airplane after 2 weeks? What about even the software to run a subsystem on the aircraft?
• Team ownership: Systems engineering is very process driven, so this one is tricky. Dr. Turner puts the idea out that perhaps allowing the systems engineers to drive it instead of the process to drive them, while more uncomfortable for management, might produce more effective results.

So while he does give some suggestions to adapt systems engineering processes to be more agile, I don’t think this will qualify as purely agile. And frankly if it we tried it, I think I'd be fearful to be in the airplane! But to quote Dr. Turner directly “…other hand, agility is much more a state of mind or philosophical approach than a set of rules that have to be followed regardless of appropriateness.” Using that idea, combined with what I saw at INCOSE 2008, I can see some definite opportunities for improvements for the field systems engineering.

INCOSE 2008 - Technical Team Accountability for Requirements and Delivery

James Andary, Maria So & Barry Breindel from the NASA Goddard space center presented “Systems Engineering Technical Authority: A Path to Mission Success”. The goal behind this program they call “Technical Authority” (TA) is to give a voice to the engineers on projects. Under the previous model, project managers were the central path to communicate with upper management. Looking at a history of success, this old approach worked well on their robotic missions, but not for human space flight missions. As an example from the Challenger report, there were specific technical warnings from people that were ignored, never making it up the chain to the people who had the authority to delay a launch to investigate them.

Under a TA model, the lead systems engineer on a project still has a dotted line reporting to project managers, but ultimately they report up to the engineering director, up to the center director and finally the NASA chief engineer. This means that an engineer can take an issue to the top of the chain if they believe it’s not being addressed properly. Part of the reason for using this model is that, there is a natural conflict between engineering (who wants to build a perfect system) and program management (who wants to launch on time), and this model is supposed to help eliminate issues from this conflict. They gave an example of a battery engineer who was about to quickly escalate an issue – there had been a series of launch delays which meant some specific batteries on the flight had expired. He brought the issue to the attention at a director level and they employed the appropriate people to quickly research it to determine if it should delay the launch again.

A result of this organizational model is that the engineer now has accountability for the product – and while generally a positive thing, this will probably be hard for some people to accept. The engineer now also has responsibility for understanding and implementing both enterprise requirements and project specific requirements. I admit that when I first heard this, I thought “You mean they were not accountable before if the space mission failed for a technical reason?” I think the point is not that they were negligent, so much as they were not being heard – more of a communication failure.

With this model, there no longer should be finger pointing “the project manager didn’t listen to me” and instead a focus on everyone doing their part to have a successful launch.

One final point made - when dealing with large systems project, it is important that someone on the project has a holistic view of the project. This team is working with MIT to study how you infuse that in people. They are trying to do a few things to improve this, such as exposing engineers to more of the overall mission activities, holding focus groups to share experiences, and requiring engineers to participate on peer review panels. I think there are some great take-aways from this that we can apply to all organizations, encouraging cross-project awareness.

INCOSE 2008 - Imagine the Complex Systems for Hydrogen-Based Transportation

Tuesday's favorite talk for me was "A System-of-Systems Framework for the Future Hydrogen-Based Transportation Economy" by Michael Duffy & Debra Sandor of the National Renewable Energy Laboratory. This was an interesting talk, less because of any discussion of requirements and more because it represents a complex systems engineering challenge. Also, I just wanted to share some of the topics that are prevalent at this conference outside discussions about requirements specifically.

In 2003, Bush allocated $1.2M towards developing clean hydrogen-powered automobiles. The administration has actually followed through and by the end of the year, will have spent just about $1.2M. The work at the National Renewable Energy Lab is using this funding to research and develop technologies to support the aim, including determining how they might guide the transformation of energy sources in application.

So “conveniently”, the generalized hydrogen supply chain looks a lot like the supply chain of petroleum. First, there is what they call feedstock (natural gas, biomasss, coal, or water) which logistically must be delivered (by pipes, trucks, rails, barges) to hydrogen conversion plants (this part varies by feedstock), and then from there, the hydrogen must be distributed (by trucks, etc. to fuel stations).

However, over the next 30 years, there is an expectation that as a society will move through internal combustion engine improvements, cleaner renewable fuels, then to hybrid electric and eventually to hydrogen fuel cells. The big systems engineering challenge is in the transformation from petroleum to biofuel to hydrogen systems. There is no single solution for the future, the mix of technologies will change over time, and there will never be a "flip the switch" moment in transition. Add to this a challenge that corporations will not build hydrogen cars if there aren’t convenient fueling stations for drivers to refill. But they won’t build the stations if there aren’t cars to use them.

Ultimately, the described projects at the laboratory to solve these challenges are a long way from complete – they are currently focused on system definition, and nowhere near design and development. Though, I suppose at this early stage, they are spending more time now on requirements than anything else! Dr. Duffy's presented timeline looks like 2015-2020 for the government to be using hydrogen fleets, around 2020-2030 we will have personal vehicles powered by hydrogen, and by 2040 everyone would have one.

(*All data here is sourced from the talk at INCOSE 2008, and the actual paper should be review for references).