Monday, January 25, 2010

KISS and Standards

Several years ago (about 2002?) I was given the assignment of writing a systems engineering document related to spacecraft initilaization for a NASA project. The contract required that we write the document "to a level four specification."  I spent more time than I should have trying to find: a definition of level four (or any level); a level three document to base the new work on, or; anyone who knew what the customer wanted. No luck.

That program still has not flown, but since that time I've done enough research to learn that there is no such definition.  So in 2006, so as to avoid this problem in the future, I initiated a standard development effort on spacecraft initialization and commissioning.  Last week our standards project team in ISO, Technical Committee 20, Subcommittee 14, Working Group two, submitted resolution to ISO (Geneva) on comments to the final Committee Draft.  We should see a new standard (actually three documents) on Spacecraft Initialization and Commissioning published within six to nine months.

This is an example of part of the reason we need a good standards base for the space industry.  Too many engineers, scientists and managers need to get work done for their projects to move along, but they do not have sufficient experience to clearly state what needs to be done.  They are not delegating technical tasks effectively. And no wonder, if it takes over a decade to fly a single space project.

If you are working on a project and you find yourself stymied by the task definition you are assigned, do you look at which standards may exist to help you? Working from a standard basis is the surest way to deliver a credible product.  If there are no standards, does it make sense that writing down the basics of what you did may save you, or a co-worker, some time in the future? And that you can save your customer time and money on future projects!

When (not "if") you find yourself in need on standards development for space systems or services, contact us at the Space Infrastructure Foundation.  You can get me at freds@spacestandards.org.

____________________________________
Unless otherwise noted, the blog posts are written by Frederick A. Slane, Executive Director of the Space Infrastructure Foundation.

Friday, January 15, 2010

Architecture - A definition you can get your hands around?

Architecture seems to be used all over the place, and unless you are building a house, the word seems to differ with each use.  I've struggled with the less well defined terms and concepts in Enterprise Architecture such as: architecture, viewpoint and view.  Sometimes everything makes sense.  Other times, not so much.  Here are some thoughts that might make it all easier to grasp.

For large enterprises, architecture has evolved to describe the enterprise and the logical decomposition of its elements. The purpose in the evolution of architecture is to enable visibility of appropriate levels of detail from relevant perspectives.

For those who are mathematically inclined, I introduce the following description:

First, think of an enterprise information set which includes all the data and the information of that enterprise and capture all that information in a multidimensional matrix we will call E.

Second, define a multidimensional matrix, IX, which is has dimensions less than E, and the subscript X can have values X=O, Sys, Ser, T or other. IO will correspond to the identity matrix for an Operational viewpoint; ISys will correspond to the identity matrix for a Systems viewpoint; ISer will correspond to the identity matrix for a Services viewpoint; IT will correspond to the identity matrix for a Technical Standards viewpoint; and, Iother matrices will correspond to the identity matrix for any other viewpoints.

Taking the product of the matrix E and the matrix IX is defined as EX. EX is the view based on the X viewpoint. In equation form

E * IX = EX

There is no definition of these matrices beyond this conceptual level.

In words, if I look at the enterprise from a particular viewpoint such as systems, then what I see is the systems view of the enterprise. In Enterprise Architecture common viewpoints are systems (also known as products), services, functional and operational. Other, less common, viewpoints are financial and communications. Any perspective however, can generate a view of the enterprise. A perspective has value when it provides insight into the enterprise for decision makers.

If we want to define the architecture for the global (actually, transnational) space enterprise, we must include the common views at a minimum.


Thursday, January 7, 2010

The New Year 2010

Looking forward on a transnational space industry, signs are encouraging.  Commercial space activity is on a growth path and government constraints to market forces are under review.
The space standards community is struggling with the effects of commercialization, but at least the community knows the future will be more commercial than the past.
New activity this year will see manned spaceflight as an emerging area for international standards development.  Regional and national level standards are also growing, but there is awareness that the market is transnational. New strategies will include some aspect of technical architecture.  In parallel, technical architecture is being defined in a more stable fashion.
In 2010, expect the barriers to trade to continue to fall. Expect the realization of opportunities for space infrastructure development to continue to mature, driving the need for better architecture and well defined standards.