System Design

The process of defining the architecture, components, modules, interfaces, and data for a system so that it meets the needs of its target audience by delivering required functions and capabilities.

The Interaction of Business Policy, Strategy, and Architecture in System Design

Most Software systems are developed by corporations to gain parity with, or advantage over, competitors. These systems are either intended for sale as products or to be used internally but in both cases they are supposed to produce positive business results for the corporation that uses them. As anyone who has ever been involved in the development of software systems will know they often fail to produce a return on investment and sometimes fail to produce any benefit at all. This failure to achieve business value stems partly from difficultly system designers have in tracking the changing relationships between Policy, Strategy, and the Architecture they are responsible for designing.

Continue reading

Posted in System Design | Tagged , | Leave a comment

A Process for Prioritizing and Managing Problem Resolution in a Complex Environment

Just because you can make a decision or solve a problem does not mean you should. There are times when it’s better to delay until the last possible moment, others when its best to go half way and stop, and of course times when action must be taken immediately. Recognizing the best way to handle any given situation is fundamental when handling large numbers of problems. Recently I’ve been working with a client on defining a change management process for a large system and have been thinking about these issues.

Continue reading

Posted in System Design | Tagged , , | Leave a comment

Convergent, Iterative Optimization of Solutions – Why Solving some Problems is Easier Said than Done

For some problems the challenge is not to identify the solution. The real challenge is working out how to put the solution in place. Anyone who has setup a theodolite will understand what I mean. The solution is simple to describe. Position a precision optical measuring device so that it is; perfectly level, at a reasonable height for operation and directly above a predefined mark. Sounds easy, but given a tripod and a theodolite most untrained surveyors will take hours and usually give up in frustration. The problem is that there are too many degrees of freedom in the system. Everything is interdependent. Make one small adjustment here and it knocks things way out of whack there!

Continue reading

Posted in Complexity, System Design | Tagged , | Leave a comment

5 Nines and other Nonsense – Interaction of Quality Attributes in System Design

5 Nines is a term used in the computer industry that refers to the 5 nines in 99.999%. This number is about the best odds manufacturers will give that one of their systems will be available at any given moment in time. Of course there are systems with higher availability but they tend to have very expensive multiple redundancy. 5 Nines is the best availability claimed for commercial system, and after all, 99.999% availability is pretty good. 5 Nines translates to a downtime of only 5 minutes a year.

Continue reading

Posted in System Design | Tagged | 1 Comment

Software Design Reviews – Lessons Learned and Best Practices

Joel Rosi-Schwartz once advised me that if I ever found myself solving the same problem for a third time I should stop and take the opportunity to improve my efficiency by thinking of a better way to do it. Joel was very disciplined about this and over the years had developed a big bag of tricks for solving common problems encountered during systems design and development. In many ways Joel was an inspiration for me and this is one of his traits I have tried to emulate.

In my career I have designed more than a few systems and reviewed the designs for many more. There were times when I reviewed two or three in a week and others when I went 6 months between reviews, but they have never stopped coming. Following Joels advice I have tried to incrementally improving my approach to both designing systems and reviewing others designs by developing a set of aphorisms that remind me what should be present in a good system design.

Continue reading

Posted in System Design | Tagged , , | 1 Comment

A Solution for Managing Timezones, Times, and Dates in International Internet Systems

The measurement and management of time is something most people give little thought to. But when designing Internet based systems time presentation, manipulation and management can rapidly become a major headache. Just when you think youve got it nailed some other unanticipated problem arises. The regular failure of systems designers to get this right is a classic example of the principle of inappropriate parsimony.

The world is a sphere that rotates on its axis once every 24 hours and takes 365 days to rotate around the sun, more or less. Its very simple. But, the more or less part is vitally important. The world is not actually a sphere it is an oblate spheroid. It does not rotate every 24 hours it takes a ever-so-slightly longer than that and its getting slower, it wobbles on its axis which by the way is inclined to the plane of its rotation around the Sun. And as we all know it takes about a 1/4 of a day longer than a year to rotate around the Sun, more or less, and this time period is also increasing. Add to this the vagaries of international politics, national pride and public safety and you have a pretty complex system. All these factors affect the measurement and management of time. Given this complexity its not difficult to see why system designers try to simplify the conceptual model of the real world on which they base their solutions. However, this is the wrong thing to simplify. The solution can and should be simplified but the conceptual model on which it is based must be high fidelity not an approximation.

Continue reading

Posted in Globalization, System Design | Tagged , | Leave a comment

The Misapplication of Occam’s Razor or the Principle of Inappropriate Parsimony

There is a class of design problem that can mislead the unwary systems designer, myself included, although I am getting better at identifying the warning signs. These design problems require the designer to base the solution on a conceptual model of a real world system or process. It often appears that a simple conceptual model that approximates to the real world system will suffice. In practices solutions based on these simple, low fidelity, models fail to handle the problem completely and often causes a whole series of new problems. Redesigning the solution to handle these exceptions only produces more problems that require more redesign and so on. If the hapless designer persists s/he will often go through several complete redesigns before getting to a solution that finally solves the problem by modeling the real world system with a high degree of fidelity. This iterative redesign process is typical of this class of design problem. Some might say that only poor designers are ever trapped in this way, others will say these solutions are anti patterns. But I think there is more too it.

Continue reading

Posted in System Design | Tagged , | 4 Comments