Software Architecture

March 26, 2007 · Filed under Software Architecture, Technology

Software reliability is a major problem. In an effort to improve the integrity of a software application, the software industry has struggled to find a reliable way to approach software development and design. There is a strong trend in the industry to mimic engineering when designing and building software. In principle, this is a good idea because there is a lot of experience in that area, and the process of having one expert build the plans from a high level all the way down to the smallest detail has seemed to work well in producing buildings and bridges that don’t fall down. In this case, a Civil Engineer is responsible for the integrity of a bridge-building project and will develop the plans for the bridge, down to the placement and size of each bolt and rivet. The construction worker, who is considered not to have been trained as an engineer, is expected to follow these plans to the letter without exhibiting any creative thought in the process. If an error in the plans is found, it is brought to the attention of the engineer, who is responsible for finding a workable solution.

The problem with applying this model to Software Engineering is that software developers are creative people trained in many of the same disciplines as the software architects; in fact, in most cases only experience distinguishes a software developer from a software architect. When presented with a problem, each software developer will have a unique way to approach it, and is very capable of managing the details of how to implement that approach. To ignore this fact and to have an individual build software designs down to the last detail comes at the expense of allowing a team of highly intelligent, creative problem-solvers to contribute to and improve the design. And, when there are competing, workable solutions to the same problem, and developers are given the freedom to decide which is best, the integrity of each piece will improve, and thus the integrity and reliability of the application on a macro level continues to improve.

See Also: Web 2.0 Best Practices

Comments

Web 2.0 Best Practices

March 26, 2007 · Filed under Software Architecture, Technology

The following is a piece I wrote for a response to a Request for Proposal on identifying customer needs in a Web 2.0 environment. No portion of this article may be reproduced in any form, or by any means, without prior written permission.

Overview

In the internet era, in which users think in terms of services rather than packaged software, services are expected to be available on-demand and improve over time. Web-based services typically have no versions, no installations, and no upgrades that the user interacts with. The traditional software development lifecycle of design-develop-test-ship-install is becoming less common as software has increasingly become a service which is always on, always improving.

For development of these services, this shift impacts the entire software development model and delivery process. Success now relies on the adoption of an iterative development model in which software is continuously improved and the users become key contributors to the development process and ongoing support of the online service becomes a core competency

This greatly improves the time to market of an application, reduces the risk of all parties involved, builds a closer relationship between the users and developers and ultimately produces a product that is not only more stable but more closely matches what the users require from the service.

Read the rest of this post »

Comments