다음을 통해 공유

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

https://www.foruse.com/

 

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.

Comments