Architecture is not about scalability, not even about user, it is all about usage
Systems
Read system as any social, economical, mechanical, electrical, biological, or software system. I recommend the following book for a deeper appreciation of systems in general.
See:
General System Theory
by Ludwig von Bertalanffy
ISBN: 1112575480
Also, the following site groups material about systems theory:
https://pespmc1.vub.ac.be/CYBSYSTH.html
Architecture of systems
The confusion that architecture is all about structure is very popular and like many other traditional inaccuracies, it propagates very fast so by now is part of conventional opinion between professionals. Structure is included of course, but it is not all in architecture, by far.
Architecture practice is a continuous activity, as long as the system is alive, that is like many things in nature, as long as the system fulfils its purpose effectively and efficiently.
In the context of artificial systems, like software, architecture practice is also a continuous activity mainly because the purpose of such a system is to support parts of a natural system like an enterprise, which is a socio-economical system.
See:
Sciences of the Artificial
by Herbert A. Simon
ISBN: 0262691914
Points of reference
The good side of architecture practice is the communication between all stakeholders and related parties about what the purpose and features will be in the projected vision for any give system.
The amount of information to communicate and talk about in architecture practice for an enterprise software system is simply huge, a lot of work and very easy to get lost at any given level of abstraction. That is why points of reference are important as tools in the ongoing emergence and evolution of architecture.
Points of reference are usually called frameworks, like Zachman Framework for enterprise architecture https://www.zifa.com; which characterize the elements about an enterprise information system.
The Zachman Framework has been around for several years now, further insights have been identified in the context of software systems supporting enterprises. Recently, the Microsoft Platform Architecture Guidance team released the Enterprise Architectural Space Organizing Table, which takes Zachman Framework, IEEE 1471 and others as starting point to further characterize the architecture space in enterprise software.
See:
Enterprise Architectural Space Organizing Table
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/entarch.asp
Enterprise Development Reference Architecture
https://workspaces.gotdotnet.com/shadowfx
Usage not user
Considering the daunting amount of work to do in architecture practice, there is an essential element which is the centerpiece and cornerstone of software architecture, all other aspects in reference points and architecture references exists for the sole purpose of fulfill that essential element, which is usage.
See:
The 4+1 view model of architecture
by Philippe Kruchten
IEEE Software, 12 (6) November 1995, 42-50
User-centric design place user at the center of the design process but this does not necessarily produce better systems; the reason is already a fact of our industry: the users do not really know what their need is. The co-evolution model of the design process described by Frederick P. Brooks, Jr. is a better fit with reality.
See:
Wicked problems, righteous solutions
https://blogs.msdn.com/marcod/archive/2004/06/12/154131.aspx
Improvements in architecture practice can be the result of more focus on usage rather than user, Larry Constantine, at. al., explains “Good systems are good tools, and good tools are designed to fit the purposes for which they will be used. Good tools make work easier, simpler, faster, or more enjoyable...To design dramatically more usable tools, it is not users who must be understood, but usage”.
See:
Software for Use
by Larry L. Constantine, Lucy A.D. Lockwood
ISBN: 0201924781
We have been told that architecture practice is not about usability design, that architecture practice is just about server-side stuff. How can this be? How useful is a perfectly scalable software system which users are trying to avoid it because is hard to use well?
There is a concept, a Japanese standard called: “Miroyokutaki hinshitsu”, literally: “things gone right”, the concept is related to the experience of using software that not just works properly but entails a fascinating event, enticing, delightful, producing emotional satisfaction. That is what I call a well designed piece of software; from time to time software like that has come into my computer; many of those have the architecture style of a smart client application.
See:
Smart Client Developer Center
https://msdn.microsoft.com/smartclient/
A common tenet of software architecture is reusability, yet there is no re-usability at all, if usability is not in place first at the very beginning of the design process.
See:
Software Reuse: Architecture Process and Organization for Business Success
by Patrik Jonsson, Ivar Jacobson, Martin Griss
ISBN: 0201924765
Wanted: Software architecture practice
An architecture practice that involves the application of such concepts is what our industry really needs in order to coach the next generation of software design practitioners.
Is this architecture?...No, it should be something else
The bad sides of current software architecture practice are many, some are:
Unmanaged complexity. Over-designed systems that are much more complex than really needed, usually made by non-practitioners so-called “architects” whom derive their design decisions based-on ill-formed analogies with civil engineering and other professions. These guys call themselves “designers” but at the same time are unable to effectively convey their designs as clean and well structured source code, it is a contradiction; the cause for many failed projects can be traced back to that particular factor.
Cargo cult software architecture. “We have a methodology; it is call UML”, seem to be that systematic software design methods are lost in the marketing battle, the hype rules and full-fledged methods with coherent design process, notation and tools are gone. Instead, the resurrection of old CASE tools hype appears under the name of MDA. A glimpse of lucid hope shows in agile methods like eXtreme Programming and SCRUM, conveying again many of the same design tenets of those old systematic design methods.