|
| Cloud, Digital, SaaS, Enterprise 2.0, Enterprise Software, CIO, Social Media, Mobility, Trends, Markets, Thoughts, Technologies, Outsourcing |
ContactContact Me:sadagopan@gmail.com Linkedin Facebook Twitter Google Profile SearchResources
LabelsArchives
|
Sunday, September 26, 2004Grady Booch about Software ArchitectureGrady Booch, one of the Three Amigo's responsible for the creation of the Unified Modelling Language(UML), is currently working on preparing a Handbook of software architecture - He has released a deck of slides about the work and the contours of the soon-to-be published handbook. Booch outlines the goals of writing and publishing the Handbook as: The primary goal of this present work is to fill this void in software engineering by codifying the architecture of a large collection of interesting software-intensive systems, presenting them in a manner that exposes their essential patterns and that permits comparisons across domains and architectural styles.The second goal of this work is to study these architectural patterns in the context of the engineering forces that shaped them and then to expose a set of proven architectural patterns that may be used to construct new systems or to reason about legacy ones.The third goal of this work is to feed his insatiable curiosity. Grady Booch brings in important insights into software developer productivity - interesting data like while the number of IT professionals are increasing the population of developer community is not and maps the productivty increase elegantly.Booch offers his view about what characterises and distinguishes software architecture:-No equivalent laws of physics -Transparency -Complexity -Combinatorial explosion of state space -Non-continuous behavior -Systemic issues -Requirement and technology churn -Low replication and distribution costs He elaborates these in his own style:With software, time matters. Software is all about state and changing state. There are usually a large number of states the software can exist in, and the software behavior may be very complex, which makes it difficult to analyze all of the different state combinations. This is different than with physical systems where even moving elements have a finite number of states. Physical systems are constrained and governed by the laws of physics. On the other hand, with software systems, you can do anything you want. This makes visible and physical systems easier to architect.Many physical systems such as buildings, are static structures. Software systems have both static and dynamic perspectives. Software is assumed to evolve and hence it is built in such a way that applying changes should be inexpensive. Adaptability is the rule for software. In fact, adaptability is the very nature of expert systems. Physical systems are not really built to change over time. Per physical systems engineering standards, software systems are perpetually in the design and prototyping stage. At some point, a running version is good enough to be released. Since the replication and distribution costs are very low (e.g., just burn a CD), new releases can be produced very frequently (we are not saying that this is desirable). In other words, software development is a continuous design process, where the manufacturing cost is effectively zero. This is unlike hardware systems where you build once and spend the rest of the time manufacturing. Software architecting is less predictable and more risk-building that hardware architecting. Thus, software is becoming more complex and difficult to build than hardware. A must read for all IT professionals irrespective of what role they play in their professional life. | |
| Sadagopan's Weblog on Emerging Technologies, Trends,Thoughts, Ideas & Cyberworld |
