Options thinking is a useful way to approach systems architecture. Although the options approach is nothing new, its usefulness was not well known because of lack of formal framework(applicable to systems engineering/software engineering) for options thinking. This post tries to summarize how options can be used in the systems architecture and development.

Options can be present in the project or in the process or both.

It can be noted here that moving away from a waterfall method of system development to spiral or agile development methodology creates options.  At each spiral you can assess the costs, risks etc to decide whether to proceed or to abandon the project before making too much investment.  You can delay the decisions where there is uncertainty and wait till data is available thus creating options. The presence of options should be considered  while carrying out project valuations. Instead of the traditional all or none kind of thinking about the projects, options thinking enable you a variety of options in between limiting the downside losses and unlimited upside potential gains. It can also help in getting management budget approvals by staging the project/product development rather than project the entire project/product cost upfront.

Systems architecture should be built using the options approach. Since the external environment is changing very fast the system should be able to ‘adapt’ to the new situation very fast. This requires lot of flexibility in the systems architecture.  The system should be able to scale up, scale down, put to alternate uses, addition of new functionalities rapidly with less cost cost are some of the features of systems with ‘options’ built into them. Modular, scalable, open, generic architectures include of these options in them. We still need to discuss, debate and understand the options more in depth. I welcome your suggestions, comments, observations, experiences in this regard!

Agile development methodology is gaining more popularity. This is due to the recognition of the fact that -

• Software requirements change and the addition/deletion/modification of features is very essential for a product’s success
• Software is evolves over time like other systems
• Software design/architecture is hard to get right first time
• Maintenance requires significant amount of product’s life-cycle cost

These are the facts from a product’s success stand point. However, there are other factors – team co-ordination, organization structure etc that are also equally important.

I am summarizing salient features of agile development methodology here. I found Jim Highsmith’s article extremely useful. I have summarized his article below for easy reference:

Some important basic assumptions and foundations
1. Works well for exploratory type projects -
“Projects may have a relatively clear mission, but the specific requirements
can be volatile and evolving as customers and development teams alike
explore the unknown”

2. Fits the process to the project. This is based on the assumption that each
project is different hence requires a different approach

3. Agile processes are designed to capitalize on each individual’s and each team’s unique
strengths: they adapt the process to the people

4.To be agile, one must balance flexibility and structure

5. Concepts drive action and behavior

6. Creativity and innovation occur in a slightly messy environment

7. Work with change rather than against it

8. Complex applications are not built; they evolve. People take time to understand systems and
hence are best built iteratively. Collaborative skills are of high importance in building
complex systems

Some factors that corroborate Agile style of development
1. Many ( or most) projects end up being very different from the initial vision

2. With today’s complex projects,understanding comes more from face-toface
interaction than from documentation. Agilists do not believe that a reliance on
heavy processes makes up for lack of skill, talent, and knowledge

3. Demanding certainty in the face of uncertainty is dysfunctional

4. The opportunity for competitive advantage comes from being more agile than the competitors
in one’s market.

5.The implicit and explicit goal of conformance to plan restricts a manager’s ability to steer the
project in innovative directions

6. Prototyping capture more information than the detailed text based requirements

Agile practices
Visioning – A good visioning practice helps assure that agile projects remain
focused on key business values (for example, ASD’s product visioning session).

Project initiation – A project’s overall scope, objectives, constraints, clients,
risks, etc. should be briefly documented (for example, ASD’s one-page project data sheet).

Short, iterative, feature-driven, timeboxed development cycles. Exploration
should be done in definitive, customer-relevant chunks

Constant feedback. Exploratory processes require constant feedback to
stay on track

Customer involvement. Focusing on business value requires constant interaction
between customers and developers

Technical excellence. Creating and maintaining a technically excellent product makes a major
contribution to creating business value today and in the future

Agile orgnizational practices
1. Agile organizations focus on building individual skills and on fostering a high degree of interaction
among team members and the project’s customers. Agilists believe that with today’s complex projects,
understanding comes more from face-toface interaction than from documentation. Agilists do not
believe that a reliance on heavy processes makes up for lack of skill, talent, and knowledge

2. Develops ability of an organization to continue to operate effectively in the face of
high market turbulence

Documenting the architectures is very important for many different reasons. Some of the reasons are cited below:

• To convey the system architecture to the developers of the system so that they understand the rationale behind some of the decisions taken
• To communicate the system evolution information to different stake holders of the system
• Documentation of some of the key architectural decision have a far reaching effect during its enhancement  and maintenence phases
• Documentation of not just the final architecture but also the alternative architecture gives the rationale behind the selection of current architecture
• Provides a common reference for discussions and understanding the system 
• Sets down some of the ‘rules’ to be followed to get the correct system behavior
• Provides information( services provided by the system ) to system integrators who want to integrate your system with other systems
• Provides the basis for planning for managers(basis for WBS )
• Provides basis for forming team structures
• It is the primary basis for assessing the system performance even before it is built
• It sets some the constraints, limitations on the product/project requirements
• It is the place where make vs decisions is made and is documented

While I may have missed some of the other benefits, it easy to derive them from the points given above. Since many people use UML modeling tools for documenting their architecture, it has some drwbacks:

• It is easy to miss the rational behind some of the architectural decisions
• Not easy to document alternative architectures
• Not easy to capture some of the architecture rules, guidelines mandated by the architecture
• Heavy use of UML constructs and the lack of understanding of UML deters some of  stake holders from using them

Hence it is better to capture the architecture in a word document. UML notation may be used for describing the architecture and supporting text describes the diagrams un ambiguously. Good architectures always provide enough flexibility for improvements and innovations and does not prescribe rigid rules. This allows architecture to evolve over time without much ill-effects. Hence the the architecture document describes just enough information.

While I have tired to list the importance of documentation, how to document effectively is not discussed here. For more information on effective documentation please refer to SEI’s - Software Architecture Documentation In Practice

What is so different in Test Driven Development(TDD)? Its a methodology which seems to work in reverse. That is – you write the test code, write the actual code and refactor. So, what is the advantage? We are so used to – write the code first and then write the code to test it – that this seems a bit counter intutive. But, if you think about it, it makes sense, a lot of sense. Why? Once we write the code we know what we have written and generally we tend to write to tests that seem to test what we know will work! If you reverse the method, you can think about what are the different ways the user can use your functions. This has the following benefits:

• Your functions( or APIs ) will be better since you are trying to find out how the user will use your code even before you have written your code!
• The code seems to be more robust since you are anticipating before hand what are the different ways your code can go wrong!
• It makes your code design and code better
• The test-code-refactor cycle eventually leads to better design and robust code

If you try to decipher how the user will use your code after you have written it, you will realize that the APIs you are providing are cumbersome and non-intutive. TDD will make your APIs more usable, easy to use and robust. Since you are the first user of your to be written code, you can fix some of the issue even before they occur! Why refactor is needed. Refactoring is needed since we all recognize that – doing things right the first time – works only in theory! We usually discover better way of doing things once we realize the limitations of current implementation. These limitations are called ’smells’ in the agile world. Refactoring tends to make the code more robust and easy to maintain and leads to lower life cycle costs over years.

You can use NUnit, JUnit or CPPUnit for writing your test cases before you write the test code. You can use refactoring features available in the Visual Studio or in Eclipse for carrying out the refactoring.

“Safety is a system issue”(Nancy Levenson). Any system is made of subsystems, components etc. Each subsystem, component contributes to system safety. Hence the system has to be analyzed as a whole with safety in mind. There are techniques like – Fault Tree Analysis( FTA), Software FTA, Failure Mode Effects Analysis( FMEA) etc available for carrying out the analysis.

Note that software is also one of the important components of any system. The software safety needs can be derived from the system safety needs. Some of the typical needs are – software should prevent the system from entering an unsafe state by detecting error conditions, handle wrong user inputs etc.

Generally safety issues are considered as part of the non-functional aspect of the system. Some of safety related needs can be identified from a systems safety analysis System safety analysis usually involves – identifying hazards , their consequences and their causes. The hazards are then analyzed to see if they can be avoided altogether. Many times it is not possible to avoid them. They are then analyzed to see if they can be controlled or eliminated if they do happen. Control mechanisms should also be identified for controlling, eliminating them. Some of the techniques are listed below:

• Safety interlocks
• Hardware lockouts to protect against software errors
• Watchdog timers
• Hardware monitor circuits
• Continuous Built In Tests
• Software check points for recovery

From the system safety needs and safety analyzes, software safety needs to be derived. The software needs thus developed needs further safety analysis. The purpose of this analysis is to identify:

• To verify that the software safety needs are correct
• Software correctly implements the safety related features

With all these, it is still difficult to achieve the required system safety. So, the software can include the following features to make it more safer

• Built in tests
• Heart-beat monitors
• Using pre conditions, post conditions for filtering wrong inputs
• Checking for buffer overflows
• Continuous built in tests
• Checking for wrong or invalid commands
• Checking for out of order data / commands
• Entering a wrong state due to multiple events etc

The question still remains how to identify the system failures and hazards. Some of the guidelines for identifying these are:

• Explore historical records
• Look at energy sources
• Develop “what-if” scenarios

There are many known sources of software safety problems that can be addressed explicitly by adding them as requirements. Some of them are listed here for reference.

• Use of wrong engineering units
• Assumptions about the environment
• Assumptions about users
• Assuming that inputs are always correct
• Not following relevant standards

This entry relies on the following sources. These can provide you more information on the subject: http://satc.gsfc.nasa.gov/assure/nss8719_13.html
A Software Fault Tree Approach to RequirementsAnalysis of an Intrusion Detection System
Guy Helmer et al

Concurrent programming has been around for some time now. Programmers have been writing multi-threaded applications wherever they can. So, what has changed now?

According to Herb Sutter, the free lunch is over. Processor manufacturers had been coming up with faster and faster processors for some time. But, now, it looks like they have hit the physical limit. Now processors aren’t getting any faster anymore. Instead, the processor manufacturers are now putting more than one processor on a single chip i.e multicore processors. What difference does that make to us? According to Herb Sutter it is going to change the way we program, think about the program logic, debug, test etc. He has summarized the trends:

1. Applications will increasingly become concurrent if they want to fully exploit the CPU throughput
2. Applications are likely to become increasingly CPU bound
3. Efficiency and performance will get more important
4. Programming languages and systems will increasingly be forced to deal with concurrency

People who are familiar with lock-based programming might think that moving their programs to new multi-core systems should work just fine. This, however, need not be true. The true parallel execution might expose some of the inherent race conditions. They need to prepared for some surprise if they move their so called ‘concurrent application’ to multi-processor systems. This trend will force people to think in a different way i.e think in terms of concurrency. People still need to carefully design their applications for achieving better performance as before. The complexity of algorithms still matter.

Some of the tricks that can speed up your application include:

• Data-structures should be designed such that less or no synchronization needed for accessing them from different threads
• Application’s working set should, as much as possible, fit into the cache. This reduces the memory access and speeds up the application
• Perform loop optimizations
• Try to reduce the algorithm complexity. If you can reduce your algorithm complexity from O(n2) to O(n long(n)) you will witness significant speed up
• Align data ( 32 or 64 byte boundaries depending on the machine architecture)
• Use compiler features for exploiting processor architecture related features
• Some operations can be made faster using SIMD, MIMD instructions

Use case is a powerful tool for capturing functional requirements of the system. Its primary use is to capture the contract between the stake holders of the system about its behavior. Note, however, that use cases may be used by some teams to capture the requirements in the traditional ‘shall’ based format. Or the use cases themselves can be used as requirements by some teams.

A use case is almost always started by an agent called an actor. A primary actor is a stake holder of the system and initiates an interaction with the system to achieve some goal. As the system interacts with the system its behavior, alternate behaviors, constraints etc are captured as part of that use case. Deciding who is an actor for a given use case is, some times, not trivial. Discovering use cases for a system is not simple. Capturing the use cases effectively requires some skill and an understanding of best practices immensely helps teams/individuals. Use Case is not object-oriented. It has nothing do with object-orientation. Simple text can be used to capture use cases. Refer to Alistair Cockburn’s excellent book “Writing Effective Use Cases” for more information. This post owes much to his excellent book.

The style of description of use cases might vary depending on how the use case is being put to use. Use cases can be used as white box use cases (ex: a business process or internal working of a system) or also as black-box use cases (ex: system requirements etc). Even the level of detail might vary from project to project or from team to team. For example, projects with safety, regulatory issues might decide to use detailed use cases, where as a project team with experienced developers might decide to use only brief use case descriptions for the system development. Projects following agile development philosophy tend not to generate detailed use case descriptions and instead rely on the good internal communication instead. They tend to keep the rest of the requirements in prototypes, continual communications and frequent incremental releases.

The use case description style can be chosen on a project-by-project basis. It makes sense to tailor the template depending on the project needs. Since use cases are easy to understand even for the non-technical persons, it is the single most important tool for identifying, clarifying, deciding system scope and its requirements.

If use cases are used as requirements, then it need not be converted to traditional ‘shall’ based requirements. Another thing to note here is that, use cases do not capture all the requirements of the system. They do not capture other important aspects of the system – non-functional requirements, quality requirements, external interfaces, rules etc. These requirements have to be captured using the traditional ‘shall’ based requirements.

Following are some of the best practices in designing use cases.

• Write the main success scenario as part of the main scenario. Identify, in each step, things that can go wrong and how the system should respond to them.
• Use discretion while detailing requirements. The mistake is getting too much caught up in precision and rigor when it is not required. If the system to be built is simple and easy to understand the use cases need not be captured with much detail.
• The best way to identify the use cases is through brainstorming. An experienced user can guide the team in identifying them. The idea to keep in mind during the identification stage is to focus on use case identification and not its expansion. Once the use cases are identified, they can be divided among team members for expansion. While detailing individual use cases, team members can take the help of domain experts, stake holders, and business experts etc to cover all the alternative scenarios of the use case. This procedure of identifying the use cases first and detailing them later provides the opportunity for the stake holders to correct any of the wrong assumptions made during the identification process. The thing to remember – once the use case is accurate, you can add precision during its expansion.
• It makes sense to include narratives or concept of operation before writing use cases. They provide context to the requirements and help clarify the environment in which the use case runs.
• Identifying an Actor – An actor is anyone one or anything with behavior. It is external to the system under consideration and its behavior can not be controlled. Note that the actors need not be humans always. It could be an external system, a timer or state based invocation.
• Primary Actor – An actor who initiates the dialogue with the system for achieving goal. The use case starts at the triggering point (initiated by the primary actor) and ends when the goal is fulfilled or abandoned.
• A use case can succeed in a number of ways. A use case can fail in a number of ways. The detailed use case description should enumerate all the possible scenarios. Note however that it is not needed to write all the sequences from start to end. Only those steps that can fail and the alternative steps for them need to be enumerated. In short, use cases contain scenarios and a scenario contains sub use case as its steps.
• The use case as a contract for behavior captures all and only behaviors related to satisfy the stake holder’s interests. It should satisfy all stake holders’ interests including the primary actor. For example: keeping a log will protect the stake holders in the case of any disputes. For a use case to be complete, all the stake holders (that are affected by the use case directly or indirectly) must agree on the success criteria and also the guarantees they want from the system. Listing the stake holders and their interests ensures that none of the required steps are left out in the use case description.
• The name of the use case is best described with primary actor’s goal. Most of the time it’s the primary actor who triggers the use case. It is possible to initiate the use case with the help of an intermediary or it could be time or state based initiation.
• Scope can be added to each use case if the use case context is not clear from its description. The scope could be – for example: enterprise, system, sub system etc. Graphical icons can be added to highlight use case applicability.
• Use cases can be applied even to describe the architecture or design. Many people find it easier to understand the design, architecture this way.
• Use cases can be written at different levels and this can be indicated as the scope to which the use case applies. At the outermost level the use case is said to be a ‘summary’ level use case. Similarly use cases can be written that are applicable to subsystems etc. Note that there are very few outermost level use cases. And these use cases provide context for other use cases.
• Having a clearly defined vision for the system helps in deciding whether some of the features should be part of the system or not. Similarly, having context diagrams, actor-goal list and in/out scope list helps in defining the system scope and helps in arriving at use cases at different levels.
• Use cases need to protect all the stakeholders’ interests even though they are not the primary users of the system.
• Finding the actors and goals is an iterative process. New actors may arise when the use case is being described – for ex: while writing a failure case. Start first with identifying the actors that interact with the system and list their goals. Then as you start detailing each use case, you may discover new actors. Add them to the list of actors and identify their goals. Iterate through this procedure till you can not find new test cases or actors. It is important not to miss any actors and their goals otherwise the system will not meet the expectation of all the stake holders.
• Writing down the backgrounds, skills and job descriptions of each actor would be useful. User interface designers can use this information for designing appropriate user interfaces.
• Use cases can be partitioned into different packages based on the actors and can be handed over to different teams for development.
• It is best to avoid naming actors based on their job titles for ex: dispatch clerk etc. It is best to name them according to the role they play with respect to a goal. Note however that, initially actors names can be identified based on their specific jobs and later can be replaced with more generic roles. The reason behind this is that – an actor may play different roles as part of his job responsibility. Or many actors can play the same role. It may so happen if we name the actors based on their job titles that if one or more of his roles are moved to another person it may pose difficulty in maintaining the use case document and also in the software design. Keeping a table of actor to role list might help in user interface and design phases.
• The system may use other systems to achieve the goal of primary actors. These systems are called secondary actors or supporting actors. When the system uses other systems to realize the goal, the interface between the systems, the data format, protocols etc needs to be captured.

Uncertainty is a fact of life. Uncertainty arises because of many reasons – incomplete knowledge about the reality, complexity, our limitation to predict future events, unforeseen major events etc. We still need to plan, execute and compete in the face of uncertainty. How can we say, then, the probability of success, the best case, worst case, average case estimates of our projects based on the current uncertainties? One of the things we can do is calculate the estimates separately for each of these cases. This is not only tedious, this does not allow asking questions like – what is the probability that the project will be completed within 2 years, 2.5 years, 3 years etc. You can think that a project can take many different paths due to the inherent uncertainties present. Due to this, it can take different time, cost( effort) etc for completion. We may be interested in knowing the spectrum of these time, cost etc variations to make better decisions. This is where the Monte Carlo simulation comes handy. It can walk through the different paths and generate nice graphs that show the time, cost etc distributions with probabilities.

Monte Carlo simulation models can simulate ‘reality’, help make predictions about the future outcome and help in making better decisions. It helps teams cope with uncertainties better. Monte Carlo models can walk through thousands of scenarios and generate predictions by taking randomness into account. Compare this with the difficult mathematical equations which are difficult to solve; some are even intractable. It does not require the users to be very proficient in mathematics. There are many commercial Monte Carlo simulation tools available.

The Monte Carlo simulation models require the inputs to posses a distribution rather than a single number. Generally, normal distribution, triangular distribution etc(also called parametric distributions) are quite popular. If you have historical data( also called non-parametric distributions), the tools will accept them instead of the parametric distributions. By providing the distributions instead if single point estimates we are incorporating randomness into our models. This approach is close to reality than the single-point estimates. How do you interpret the some of the properties of distributions? The mean ( also called the first moment) represents the most expected value. The variance ( also called the second moment) represents the risk associated, the third moment represents the distribution’s skewness and fourth moment measures the peakedness. The accuracy of the model depends on the level to which you have modeled and also the correctness of the data.

If you have data that are correlated you can also include them in the model and make the model know about it. Make sure you include the assumptions as part of the model. You can do sensitiveness analysis of the results on the assumptions. If the results are highly sensitive to one or more assumptions, you need to track the assumptions more closely. You can move them to risks if need be or spend some time to get more clarity on those assumptions.

Monte Carlo simulations can are also used in the robust design techniques. It uses the simulations to carry out the sensitivity analysis, robustness of the design etc. It helps in making the designs robust that can tolerate variations in the process, materials etc and ensures very high quality products.

Monte Carlo simulation tools are also used heavily in finance. It is used for risk analysis, forecasting, sensitivity analysis etc. It is also used by marketing, sales and other disciplines.

Monte Carlo simulation has a wide variety of application than the ones listed above. It is easy to use at the same highly useful.

As always, comments, different views etc are welcome!

One of the useful yet very powerful tools that can be used for selecting among alternate architectures is – Pugh Matrix. Pugh Matrix is one of the popular Design For Six Sigma (DFSS) tools used for selecting among different concepts, tools, ideas etc. It is a recommended practice in Software Architecture that alternate architectures be identified and then compared against a set of criteria during the architecture phase. These criteria are usually derived from the Quality Deployment Function (QFD) matrix. From the QFD, the factors that are important for the success of the product are identified. These factors are called – Critical To Quality (CTQ).

Once the CTQs are identified using the high-level QFD, these can be flowed down to the architecture level QFD and the factors that are important for the architectural phase are identified. Typically, an architect comes up with more than one architecture for a given product. Most of the times than not, the process of selecting the best among the candidate architectures is ad-hoc. Usually, the selection is based on experience, intuition and heuristics. The Pugh Matrix provides a method for systematically comparing among different alternatives. Pugh Matrix is very simple to use. As the name suggests, it is a matrix that comprises of rows and columns. The rows are the CTQs derived from the Architecture Level QFD and the columns are the different candidate architectures. The CTQs can be assigned different weights depending on their importance. The alternates are compared against these criteria and the best among them is selected. The process can be iterative.

The Pugh Matrix looks like below:

What is the recommended process of using the tool to get best results? For getting better results, it can be performed with the team so that the results are not biased. The other approach is – each team member performs this process independently and the results are compared. If there are differences in the results among different team members, then they should be discussed with the team and a common consensus should be arrived at.

Cutting down software development time and improving productivity are the most debated topics in the software industry for some time now. The industry has responded to the challenge with new technologies, different software development paradigms, different design methodologies, promoting re-use, use of COTS components rather than developing them in house etc.

The availability of new programming languages like Java, .NET etc have helped improve developer productivity significantly by providing a rich set of libraries and by providing enhanced language constructs. Availability of specialized COTS libraries have further improved productivity and they have also resulted in improved quality of products. Availability of modeling tools, Domain Specific Language(DSL) Tools, Generative Programming Techniques, Software Product Line development methodologies, Software Factory approach, availability of domain reference architectures, Design and Architectural Patterns, application frameworks etc, are some of the techniques used today for building better software systems as well as for improving development productivity.

There are lots of modeling tools available in market today. Many of them support modeling in UML. While these modeling tools allow the designer model the solution using the constructs available in UML, they have many shortcomings. The tools generate only the template code and the developer still needs to write source code manually. Another problem is, generally, the quality of generated source is not good. UML is too vast and this deters designers, programmers from using it. While the experts are of the opinion that 80% of the modeling can be accomplished by 20% of the UML constructs, there is no universal consensus on what those 20% constructs are!. Another related problem with UML is its poor semantics. Because of these and other problems, Microsoft is betting big on the software factory approach.

A software factory approach combines different concepts listed above and provides an integrated environment for software development. The concept is based on the Economy of Scope. The concept is based on the fact that- unlike in the automotive industry where millions of identical products are manufactured(aka economy of scale), the software industry needs to develop ’similar’ but distinct products( aka economy of scope). It combines various approaches – component re-use, generative programming, models, patterns etc to achieve this. Microsoft provides Domain Specific Language(DSL) Toolkit to achieve automatic artifact generation including – source code, configuration files etc. DSLs are domain specific constructs( can be built for each domain using a tool that supports meta-modeling) and do not suffer from the deficiencies of UML tools. The generative programming technique is based on the idea of software generating software i.e. source code and other artifacts from graphical models, textual specifications etc. Microsoft is providing lots of add ins to the Visual Studio for supporting the factory approach. There are also lot of commercial add-ins available from many different vendors. Eclipse is another popular platform that can be exploited for Factory based solutions. INRIA, for example, is developing add-ins called ‘Smart Tools’ that is based on the Factory approach. Eclipse is easily customizable. It is highly flexible and its superior architecture makes it a very attractive tool for Factory based development.

The software product line approach is based on the same assumptions as the factory approach. It recognizes that the products that belong to the same domain have lot of things in common. Main idea behind this is the concept of commonality and variability among different products. The development of common and variable features of products are done by disparate teams. The common features are developed by a Core team(aka Domain development team) and variable features are developed by Application development teams. The software is designed such that it behaves little differently based on different configurations.  Some of the techniques used  by the product line development projects are – configuration files, templates(aka generics), file substitutions, #ifdefs,  reflection etc. By using the same common functionality in different products helps achieve significant savings in development time and also during the maintenance.

In the future, the architect needs only to know different components, patterns etc available. He will use these predefined artifacts and mix and match artifacts and arrive at a solution without much effort. Hope that day is not too far!