- Software Developers and the Value Chain
- Software Plasticity: An Architectural Attribute
- Plastic Software Caveats
- Conclusion
- Resources
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Plastic Software Caveats
By making software more plastic, we introduce a degree of openness. As with any power, there's an attendant risk: It might compromise security in some cases. Examples of sensitive applications are banking, payroll, and so on. Opening the code of such applications with AOP has its own dangers. However, in another context, such as on-demand computing, openness may actually be a business requirement.
Thoughts on Software Architecture and Methodologies
A little terminology now. A software project is a piece of development that results in a software product or component:
- The end result of a project may or may not be developed further; this is often seen in custom development. Another scenario for project work is component development.
- A software product, on the other hand, is developed further, over numerous release cycles and often many years of work. The code developed in this article is a project, whereas Windows XP is most definitely a product.
It's a little ironic that so much of software methodology relates to projects rather than products, the more so since there are so many commercial products and product lines. The Rational Unified Process has initially focused on green field software projects, but is being updated to support product development. This is a healthy development.
Software architecture is applicable to both projects and products, and this has been the case from the outset. Some of the better texts in this emerging field—for example, Software Architecture in Practice (Addison-Wesley, 2003, ISBN 0321154959)—include details on how to document an existing architecture. Why is software architecture so important now? The main reason I see is that up to now the main quality attribute of software has been performance. It's becoming clear that this standard reflects an era in which machines, networks, and software were perhaps slower than was ideal.
The software industry is maturing, and so are the attributes that govern success. Performance is just one of these attributes. An increasingly critical attribute is security, especially given the growing number of infrastructure attacks. Take a look at how many spam emails you've received today—this is another form of attack, an invasion of privacy and theft (given the time required to filter and delete the spam).
Modifiability is a crucial attribute of any software product, as are scalability and reusability. Pushing these attributes into software is nontrivial; they represent the next wave of software. For this reason, architecture is an area that all programmers should study.
Observations on Software Architecture, Design, and Coding
Among budding architects, I've observed a keenness to stop coding and even cut back on design work. This attitude loses some of the benefits of an architecture-centric approach. Architecture seems to span or at least overlap the areas of design and coding; to truly inform software products with architecture-centricity, architects must code. As an example, take Novell's network operating system NetWare. NetWare helped the PC industry move into the LAN era and provided the first really successful file and print server product line. It was designed with performance as the principal architectural quality attribute. NetWare had to work quickly and scale to support large numbers of users. The chief architect of NetWare was Drew Major, who also coded the product.
Clearly, architects can't be expected to cut lots of code and still operate at the conceptual and abstract levels required for making products architecture-centric. But modern software products are both complex and distributed, and as such their creation and maintenance requires a wide spectrum of skills. For this reason, architects shouldn't divorce their efforts from the coding level.