Software System Architecture

Our Vision of Software Architecure
With the design role largely missing, a vacuum was created. This has been filled in by programmers, engineers, and computer scientists who do not have training and experience in design and who do not necessarily have an architectural worldview. In spite of this, they consider design to be a part of their role, but role confusion and muddled accountability are the results. We are not only confusing our clients with ambiguities, we are also confusing ourselves.
Software Engineering vs Software Architecture
An increasing number of software professionals are claiming the title: software architect. In our opinion, very few of these people understand what software architecture is.
Without a profession of true architecture (not just on words), it is the… architecture that is missing. Even the best managers cannot produce a satisfying result from a bad architecture or the lack of architecture.
Blaming software failure on particular people or difficulty of "changing requirements" is merely symptomatic of the lack of true architecture.
Architecture Full Life-Cycle
Architects exist to design, yes, but their eyes remain focused on a point on the horizon far beyond the architectural phases and the completion of the blueprint or model. Client, architect, and builder - all have the same destination in their sights: the successfully completed structure. The only point is to build something and move people in.
Steps to Create a True Architecture
Today at OpenFrame Technologies we are more convinced than ever: conceptual integrity is central to product quality. Having a system architect is the most important single step toward conceptual integrity. These principles are by no means limited to software systems, but to the design of any complex construct, whether a computer, an airplane, a Strategic Defense Initiative, a Global Positioning System.
Software Architect's Bootcamp
As a software architect, you need many survival skills - some technical, some political, some personal. While neither of us has military experience, we have seen software architecture become battleground in many ways. It is a battleground of ideas, as developers compete to forward their own concepts. It is a battleground for control of key design decisions that may be overruled by managers or developers, perhaps covertly. It is a battleground with many risks, since architects are responsible for a much wider range of technical and process risks than most managers or individual developers.
OpenFrame Framework Design Concept
To accomplish component reuse for information systems, a common architecture must be established. An effective architecture must not be too complex or too bulky. It should be widely applicable across a large domain and be based on an effective conceptual model. We hope OpenFrame™ will encourage people to think about such frameworks and will influence their development.(
(Excerpt from Technical Specification, v.1.1, circa 2003)
OpenFrame Technical Architecture
Based on the classic concept of the 3-tier architecture, OpenFrame™ goes much further employing advanced concepts and the best practices in the software architecture, such as multi-tier approach and distributed enterprise software architecture patterns. Each of the three common layers (presentation, business, data access) is sub-layered using mixed patterns and designs. The objective is to reach such level of prospective integration that would allow adding, modifying or disconnecting virtually any object, business rule or custom feature with minimal efforts and without any change to the application architecture.
(Excerpt from Technical Specification, v.1.1, circa 2003)
Language Wars: VC# or VB.NET ?
Exploiting customers' illiteracy in programming and handle them only the product you favor to work with is unprofessional and should be mercilessly obstructed. However, it is the debate that never ends (though it does change shape): is the current C-style language (C#) infinitely superior to the current most widely used language (VB).