Costa Concordia: The Goals of Software Architecture

With the tragedy of the Costa Concordia, design with the human in the control loop comes to mind.  A cruise ship is a large system with many moving parts and error points. 

In a large mechanical system like a ship have long used computers, in the past the computers might have been the sextant to determine position, the length and angle of a rope pulled by a rock for speed, as well as other analog types of tools.  In some cases, though not many, analog computers can be faster and more accurate than digital computers.  No matter what you use, what are the goals of Software Architecture?

So what is good Software Architecture?

So with the command issues onboard the Costa Concordia, how do you design software for these kinds of systems, systems that must function safely?  In this case you need to make sure at the beginning of design or if you are pulled in during the design or implementation phase that the software architecture has these goals in mind:

  • Expose the structure of the system but hide the implementation details.
  • Realize all of the use cases and scenarios.
  • Try to address the requirements of various stakeholders.
  • Handle both functional and quality requirements.

What do you do if one or more of these items are not met?  Carefully work with the management to get these items into the design process.  After all, you may not see the big picture, and it never hurts to ask about these items.  If the questions are ask in a non-threatening method, most manager would be happy to answer these questions and feel that you are a good worker.

Like the captain of a ship, you need to have an overriding guidance, and these four items are part of the guiding ideas.

Here is an image of a generalized process of Software architecture, as you can see this fits with the simplest games to the most complicated systems like a Cruise ship.



More to come on the Software Architecture of complex systems

Comments (4)

  1. cron22 says:

    But how then can you build a complex computer system and hide all of the implementation details?  That's kind of odd.  

  2. Surf4Fun says:

    cron22, Thank you  for the comment,  please understand that my response is a respectful one.

    I believe you are referring to:

    • Expose the structure of the system but hide the implementation details.

    If I understand your question, the architecture would allow better understanding of all of the details of the system, not only by the software stakeholders.  In my experience software is the servant technology for people who live in the real world.  At times I have felt that my software work was the actual end component, but I now view all software as a servant, not the ends.

    Why?  For instance on the Costa Concordia there was a system to flood tanks counter to the rip to prevent tipping while the ship was being evacuated.  This could be accomplished by a technician opening valves and observing meters that they compare to a chart or graph.  Or you could have software do the work and save the life of a brave techncian.

    With the Costa Concordia laying on it's side, clearly there was some reasons that system didn't work.  In well designed system, if the flooding system was engaged and the ship heading into waters less than it's draft, then an alert would be given to the bridge crew.  The use of software architecture would allow the stakeholders to understand the process and maybe create a simulation for training of the bridge crew.

    It would then be up to the bridge crew to make a decision, as the bridge crew might decide that it is better to beach the ship then to remain in deep water.  A software architect would be able to present the concept to the stakeholders and then they make the decision or what to do in an emergency.  The bridge crew would be the humans in the loop and ultimately they would make the final or even terminal decisions.

    As to hiding implementation details, my opinion of software architecture is to include the non-software stakeholders in the ALM process.  Software implementation is a few layers away from including stakeholders in design decisions.  And ultimately it is the stakeholders that own your software.  Software is not the top of the design hierarchy when it comes to real life products like ships, planes, weapons, enterprises, etc.  So it is critical that the other stakeholders can determine what impact the software implementations will have on the ultimate use of the technology will be. 

  3. cron22 says:

    ah.  I see it now.  I keep forgetting that, for since I belong to the open source community, I tend to think of software only in terms of my own projects.  I think it's my fault then.  I should think more of the higher places in the world where software isn't at the top.  My bad.  

  4. Surf4Fun says:

    cron22, Software isn't at the top outside of software.  A surgeon doesn't care that the DeVinci robot that is using software or hydraulically implemented augmentation (which would be possible).  The driver of a car doesn't care if you are using open source or paper clips.

    You and I provide a service, and it is a service that humanity only  recently found a need for.  It's fun to think we are on the top of the pack.  But software is a service, and in this case I mean we are a servant to all of the other engineering systems.  Sure with games we kind of look good, but even there, we are nothing without graphic artists.

Skip to main content