Πάντα ῥεῖ (panta rhei) "everything flows", is one of the sayings (well, not quite) of the Presocratic philosopher Heraclitus. If not an actual quote (as Wikipedia informs me, but my first Ancient Greek textbook had no trouble attributing it to him) it stands for what little is known about Heraclitus' thought. The other famous saying of his is "you can never step into the same river twice."

So it is with requirements and systems. While we might like requirements and systems to conform to a Parmenidean view of the world that "All is one" and "Change is impossible", my experience, and I suspect the experience of most of you out there, is that we need to adopt more of a Heracleitan view. To pop out of my reminiscing about my academic background and displaying my extraordinary erudition and to speak plain English, we need to be more iterative and agile in dealing with requirements.

When I talk about requirements, I make the following observations.

Let's say you start a project with 10 use cases (or their equivalent). Your first iteration (or two) of the project should develop one or two of those. You are, of course, trying to explore, establish and exercise the architecture and deliver highest immediate value. Almost invariably, when you finish the iterations, you will find that the priority ranking of the remaining use cases has changed--you may have learned something that changes the prioritization, your stakeholders may have changed their minds (never happens!), or the business situation has changed in such a way as to make some of the remaining use cases irrelevant and has introduced new needs. In other words, the river has moved on. Everything flows. Without a good strategy for dealing quickly with change, both in your projects and in the external environment, that is, without some way of being agile in today's complex world, you will be up that river without a paddle.

My colleague Eric Naiberg wrote a blog entry on this topic last October: http://su.pr/5SWJwK. In November, we held a Virtual Roundtable on Agile Systems Engineering: http://su.pr/1OROS0 which also touched on the topic in several posts. In the meantime--Go with the flow!

Last week I spent 3 very enjoyable days at the 23rd INCOSE International Symposium in Philadelphia. As representatives of IBM Rational we are often asked what we do--how we help out customers, and we produce a lot of collateral to explain our "value proposition". I'd like to write here a personal, as opposed to corporate, expression of "what we do".

At IBM Rational, we magnify, amplify, and enable--we don't so much build products ourselves (with the exception of our software tools)--that is, planes, trains, automobiles, and the like. We help you do things better, faster, less expensively, and we help you lower the risk of building innovative products. But without telling you how, this is just "motherhood and apple pie"--everyone claims to do this. So it is my responsibility to tell you how I think we do this.

First of all, we try to discover powerful abstractions to help conquer complexity. I will write in a separate post about one of these, joint realization, because it is one that I am most familiar with. Professor Sangiovanni-Vincentelli talked a fair amount about mathematical abstractions--clearly the abstractions we use in mathematics are very powerful. Modeling is very important here. We create powerful models which encapsulate the innovative hard thinking of thought leaders and package it in a way that others ("mere mortals") can leverage/benefit from the innovation of the thought leaders--Wizardry at your Fingertips (webcast). To continue the mythological allusions I have been using in previous posts, we provide Perseus with the idea and the mirror with which he can slay Medusa,

or Theseus with the magic thread to navigate back through the labyrinth after slaying the Minotaur of complexity.

Second, we help you constrain and optimize processes--strategically limiting choices to minimize errors, analysis paralysis, and undirected churn. We encapsulate best practices, and automate wherever sensible and possible. This promotes more effective learning and internalization, and promotes reuse of process. Used judiciously, this significantly reduces errors. We elevate capacity by automating whatever can be automated.

Third, we provide power tools to help make this happen. Powerful thinking tools, process tools, data management tools, and modeling tools, among other things. For example, check out the Rational Engineering Lifecycle Manager. Powerful tools are magnifiers and amplifiers--we make the software equivalent of levers and pulleys, chainsaws and steamshovels. We strive to find and provide a calculus for building better products, a process model to accelerate production, and a toolset to help it all work.

My college nickname was Socrates. That's because I talked about him a lot my first semester as a freshman, and because I was a Classics major. My first college course in Ancient Greek, at an all male undergraduate college (at the time) consisted of myself, the professor, and a woman graduate student (wife of one of the deans). What a surprise when I walked into the first class--nowhere to hide!

We were reading Plato's Apology--Plato's account of the trial of Socrates. Needless to say, as a college freshman, I was captivated by Socrates and his personality.

Socrates got himself into trouble in Athens because he had the annoying habit of exposing how little the Athenians knew, when they were claiming that they were experts in their fields. The only thing Socrates claimed to know, was that he didn't know.

This is a useful point of view for anyone starting out to develop a system of any kind. It is an essential point of view for anyone starting on an innovative, risky system development. The very nature of innovation is that you are heading into the unknown, and what's unknown can get you into trouble--it's risky.

How often do we claim to know what we don't when faced with stakeholders who want to know "how much will it cost", "how long will it take", and then "when will you be done?"

How do you proceed then, in the face of the unknown? How can you estimate, or try to estimate, how long something will take? How do you account for unknown unknowns?

I wanted to call this post "Minoan bull-jumping, the Parthenon, and Vitruvian Man", but am told I need to optimize my title and content to attract the readers I want. I don't suspect there are many other classicists who have converted to engineering--if I knew of any, I could have used that title.

My point today is that Agility, Architecture, and Measurement aren't new concepts. On the contrary, I maintain they go back to the roots of our civilization and culture.

Who would need to be more agile, than someone whose life depends on it? I suspect jumping over the back of a bull required agility.

What building is more elegant and beautiful than the Parthenon? It is a standard by which all other buildings are measured, the archetype of architectural beauty.

Leonardo da Vinci spent a lot of time measuring, sketching, modeling and prototyping, to get his proportions and designs right. And his works have never been equaled either.

So, how do agility, architecture, and measurement relate to systems and software engineering in Aerospace and Defense? Check back, or sign up for my feed to find out.

, and attended a session on FACE, the developing Future Airborne Capability Environment. FACE has a number of objectives, one of which is reuse of standardized components. A question was raised from the audience "But what about sustainability?" I believe the questioner was referring to the ability to replace/upgrade components on fielded systems, as opposed to an ecological/green context, and also as opposed to reusability in the design phases of system development.

Well, whatever the actual context, it brought to my mind (which of course is the important thing), the Temple of Hera at Olympia. While the temple is now in ruins (of course), it provides an interesting ancient example of plug and play "sustainability". Perhaps it is not clear from the picture, but each of the capitals (the pancake looking part) of the columns is different. This is not usual for Greek temples. Here's how archaeologists think it occurred (at least, this is how I remember the explanation). The temple originally had wooden columns. The columns support the roof of the temple (now missing). As they rotted (at different rates of rot) they were replaced with stone columns. Each replacement stone column had a capital that accorded with the current style of capital in vogue at the time. The capital on the right of the picture is broad and flat, the one on the very left not so broad and flat, and the one in the middle least broad and flat of all. So essentially, they upgraded the columns based on current "specifications" (in this case, architectural style), while keeping the building in use--they didn't rebuild the whole thing just because a single column rotted.

Back to FACE--the questioner wanted to know, how can we keep the system working, while providing necessary upgrades with a minimum of disruption and expense?

Tomorrow, I'm attending a Systems and Software Engineering Symposium in Waltham, MA: event agenda.
While we won't be drinking wine all day as they did in ancient Athens,
we will be exchanging information on a variety of topics, and having a
good time doing it.

I suppose I should explain why this in an A&D blog? Well, my background is that I have a Ph.D. in Classics, that is, Greek and Latin literature in the original languages. The derivation of certain words particularly interests me. So, συμπόσιον, symposium, or, a drink together, is the original meaning of the word we now use to indicate a conference or a meeting. However, a Ph.D. in Classics was not (and is still not) a hot item in the market when I came out of graduate school, so I took a personal odyssey which brought me from Classics to computers, systems and software engineering. The learning of natural languages somehow made learning computer languages somewhat easy, and seems to have trained me in abstract thinking, which is somewhat of a miracle since I was a math-phobe (φόβος--fear) through all of my academic years.

Several years ago, my wife Han and I stopped at a nice independent bookstore on the shores of Lake Winnipesaukee in Meredith, New Hampshire called the Innisfree Shop. We are both bookaholics, and the selection of books was good, so I looked at her and said, "Innisfree, but out is expensive". We escaped, however, without having to take a second mortgage on the house due to buying two piles of books.

"Innisfree, out is expensive" is a corollary to several other maxims such as, "pay me now, or pay me later" and perhaps "measure twice, cut once".

A few other examples.

Many years ago now, when personal computers were just making their way into the workplace (this of course tags me as a grey-haired old fart), a young co-worker came up to me and showed me a nicely formatted list of names and phone numbers, sorted by name, with borders around each name and phone number pair. I looked at her, and said, "that looks great--but what happens when you have to put a new name and phone number in the list?". She had manually sorted the list, typed it in, and manually formatted it with borders. "Oh," she said, with a crestfallen look on her face, "I'll have to redo the whole list". If she'd invested her time in learning how to use a database with reporting, or made the list less fancy, without borders, she could insert and sort much easier when needed.

More recently, I am somewhat abashed to say, my department has been using spreadsheets as databases. I'm actually ok with that, if done with the limitations of a spreadsheet kept in mind, and with some knowledge of database principles. The problem in this case is multiple items are being placed in a cell/field. This is being done because it's extra work to create multiple rows to hold the data being entered in the cells. Extra work at entry time, that is. "Pay me now or pay me later". When you want to extract a unique record for one of the items in a field with multiple entries, you can't, or you can't without a lot of extra work. The same is true if you use the color of a cell (red, yellow, green, for example) to indicate status--it will be difficult, if not impossible to sort by status unless you also include a text value for the field.

Systems Engineering in general, and model based systems engineering in particular, are, I submit, a similar situation. You can save a lot of pain, rework, and expense later if you invest in them up front. I'm not going to cite a lot of data here, just point out the similarity/analogy. By investing in modeling, you can save time and money in a wide variety of contexts--invest now, and reap the benefits later. In this case, innisnotfree, but out is less expensive, and most likely quicker too.

Can you cite similar situations in Aerospace and Defense, where Innisfree, but out is expensive? or in other industries?

Developing modern software intensive products involves conquering the minotaur of complexity, and finding your way back through the labyrinth of complex product development. Traceability provides the magic thread for coming out alive.

Come join me on Wed March 14, as I present with my colleague Justin Dyer this webcast:

When you are developing a product with a significant software component, you need to be able to assess the impact of change in requirements, or uncover the root cause of a problem – you need to be able to do effective impact analysis. Traceability from requirements through design artifacts and beyond is critical for both effective impact analysis as well as for analyzing defects and errors. This webcast will show how to trace from requirements through design and test with the IBM Rational Systems and Software Engineering Solution to improve your ability to do impact and fault analysis.

In this webcast you will learn:

How the appropriate requirements structure and requirements attributes can improve traceability

How effective requirements and design processes can improve traceability

How automation and a linked data approach can significantly enhance your ability to do impact analysis

I forgot to add to my first entry the Rational Harmony Deskbook, written by Peter Hoffmann. It's a great resource for those wanting to learn how to use IBM Rational Rhapsody to do model based systems engineering using Harmony/SE:

I am Brian Nolan, Go to Market Manager for Aerospace and Defense, IBM Rational Systems Marketing. I'm starting this blog to cover my interests in A&D, systems engineering, model based systems engineering, and anything else that comes to mind in this general arena. I hope to have several colleagues from IBM posting here as well.

For starters, I'd like to point you to two works I've had a hand in:

A recently released e-book from Wiley--Systems Engineering for Dummies: http://bit.ly/SEForDummies

An IBM Redbook--Model Driven Systems Development with Rational Products: http://bit.ly/mdsdRedbook

I've been told to keep things brief ("best practices for blogging"), which I will find very difficult, as I think will several of my colleagues