Architecture Pictures
Architecture PicturesShare your Architecture Pictures here.
Discuss the pros and cons of visual Architectural Models. Why are there so few pictures on Wiki? Do written patterns replace the need for visual Models?
Perhaps it's because ArchitecturePictures so commonly convey only an IllusionOfControl that developers and customers have learned to ignore them.
I agree that the IllusionOfControl has led to the habit of ignoring ArchitecturePictures. Do we then accept this and give up? I see part of this problem is when the architect owns the models. Can the developers and the customers own these models and the architect acts a humble communication facilitator?(see TaoOfTheSoftwareArchitect). I see a need to bridge the gap between developers, customers, managers, vendors, users, stakeholders. I have found that pictures can help. What are other alternatives?
The pictures like those below are absolutely worthless to customers and stakeholders because they really shouldn't care about such stuff, they are also worthless to developers, because they really don't express anything significant or important for their development effort. They're just pretty pictures.
Exactly what are the real things you want to communicate with pictures like the ones below, to whom, and why the intended audience should care ? That's the first set of questions. The second thing is that these pictures really are about IllusionOfControl, they suggest some architectural choices (some of which I personally find questionable), but assuming they are good choices, the pictures don't express why they are the right choices, why they are important, what they intend to solve and how. What are the alternatives ? There are none as yet, to paraphrase AlexanderStepanov, SoftwareArchitecture is a hoax. "Architectural pictures" are void of real content as long as software architecture as a discipline is void of real content. The problem is not with finding pictures to reflect software architecture, but with finding the content to put in those pictures. --CostinCozianu
Customers (users) should not care I agree. As for stakeholders (from my perspective as a consultant they are my customer), they are beginning to care because of many failed distributed projects. Pictures (even these) can communicate scope, cost (number of EJBs, number of legacy connection, number of physical machines, number of integration points, number of technologies, number of tools (not shown here) etc...) and more importantly the corresponding risks.
I don't see any "risk" in the pictures below. That's the tricky part of those pictures, they look pretty as pictures, but when you go down to bytes and byte codes opr machine instructions a lot of these nice architectures that look pretty in pictures, are dead wrong. Diagrams, even the more detailed like the UML artifacts don't convey absolutely nothing about the qualities or the faults of a system.
Exactly what are the real things you want to communicate with pictures like the ones below The primary purpose is to communicate 'The Big Picture', the number of pieces and the need for integration. To balance our heads down approach of coding part of the system with a heads up view of the whole, the need for collaboration and to remind us of the business purpose. --PaulCaswell
Again, I have to say that you'll get a false sense of security from the pretty pictures, and very little information if any. Where's the business purpose in the architectural pictures ?
Business Purpose In the 4-Tier Project Specific Picture, the purpose is to get valuable information from the legacy data bases to users. This consolidated view of the information should be available to users: wherever they are; whenever they want it; quickly; cheaply and with minimal maintenance costs (the client was replicating databases around the world prior to this project- very expensive ) Another model more business focused picture had the OneStartlingSentence of Local Data, Global Access not Global Data, Local Access), okay not a sentence but reminded business and technical teams of the project value.
Another purpose is risk identification, to keep an eye on the big picture, to ensure all parts are identified and fit together. Without them I have seen discussions focus around the technical details of one part of the system (security and clustering seem popular distractions). These distractions make the technical experts look smart but consume time and energy that are required for the difficult challenge of integration. (for some reason the tune, 'fixing a hole where the rain comes in' is in me head!)--PaulCaswell
4-Tier Project Specific Picture
The above picture is a 4-tier project (that's what I call it) but the Infrastructure Layer as described in FourLayerArchitecture is additional to these tiers. I use these pictures to provide a clear division of responsibility (easier to ensure OnceAndOnlyOnce) and a shared vision of the whole system. I try to map the logical layers clearly to the physical hardware in a distributed environment. In addition to the managing complexity by introducing layers, the pictures help provide cohesion, clearly identifying integration points.
I like pictures (dare I say models!) but I don't see many here on Wiki. These are not patterns, but a visual arena where we can apply architectural patterns cheaply and see what happens!! --PaulCaswell
Well I challenge you to explain how can you see what happens in the above system. The picture looks nice and clear, and even has an illusion of scientific drawing to it. However there are many real life projects that fit in this picture and went down the drain because of the lots of things that this picture cover up. And only those things are real, transactions, locks, over complexity, unnecessary abstraction, moving bytes around between layers and layers, and so on, so forth, while the picture is surreal, it reflects almost nothing of what really happens. It really blinds you.
I like the challenge, not easy on a static picture (check out AnimatedArchitecture), but I'll have a go.
To start with the transaction and locking problem. These pictures do not solve this problem, but can isolate the issue to the EJB team, shielding the user interface team from this issue. Without this clear division of responsibility, the entire team can held up with problems such as these.
As for moving bytes, we have now identified the communication links and for example can isolate the Web Server to EJB layer. Here we can apply a pattern of reducing the number of client/server calls and minimize the size of the serialized objects, this identifies that the server EJBs should perform the logic of cleaning up legacy data, translating it into Java objects that contain only the attributes needed by the user interface logic, but enough information to avoid multiple calls to the server.
If these pictures are perceived as solving all our problems, I agree they can blind. If they are a perceived as an agile map of a dynamic complex system, they can help us navigate through the problems.--PaulCaswell
The primary audience for these model are developers and project managers (in these examples).
why care Because without an understanding of the how the pieces fit together they don't. To feel a valuable part of a collaborating team. To know who is using the interfaces I build and therefore who I need to negotiate with to stabilize my provided interface. To know the dependencies I have and to identify my required interfaces.
I'll share a story from several year ago. I was a developer building a complex CORBA component as part of a large ERP system. This component was one of over fifty, it was to be used by multiple GUI applications that other teams were building. I did not know how my component was to fit in the system. I over engineered my component, I felt isolated, I had to dummy out required interfaces from other components and make assumptions about the data structures (duplicating work that other developers were doing).
I wished I had a picture of how all the pieces were to fit together. I wished I knew which developers I should be contracting with and integrating with. I wished the team shared the same vision and was pulling in the same direction. I wished I had a context for the development work I was doing. I wished that the project managers understood the need and provided support for integration. I wished I was excited about the value the finished application was to deliver. I wished I could see how my work was to be part of this value. --PaulCaswell
Unfortunately the story rings true, and I heard a lot more stories related to architectures like the ones below. The primary causes of failures like these is not, I believe, the lack of architectural pictures. But that's another serie of long stories.
Agree, one of the primary cause is our inability to collaborate. These are no silver bullet, but may increase awareness of the problem.
I am trying to provide now what I wanted when I was developing part of a large system. These pictures are abstractions, not complete solutions, certainly not a blue print, not technical decision documents, not a pattern catalog, but there is some content here:
I’m not convinced architecture is void of content and I use the term discipline differently. I see discipline as learning, the quest for this content. I have no list of answers but I am learning by doing. By learning what does not work I am able to redirect my efforts. I take these concerns seriously (CriticsAreYourBestFriends) and I am considering that pictures may not work. However, I have seen some use in creating pictures if only to help myself understand the complexity. I’m not convinced that ArchitecturePictures are worthless … yet! --PaulCaswell
I'm an "architect" myself, however I admit to anyone who asks me that I abuse this title as a matter of social convenience. I'm a fraudulent software architect. I'm not yet convinced that I can earn the title of SoftwareEngineer. The quest for the content of SoftwareEngineering as a real engineering discipline is endangered by the very things we promote today, like pictures, UML diagrams and the likes. These things are false starts, and because they are prevalent in the software industry, they prevent the real valuable tools and scientific content to be promoted and used by the software engineering community.
These picture are indeed outside of the SoftwareEngineering discipline. This is where there may be some controversy. I was once a SoftwareEngineer, I do not deserve this title today, I've changed. I believe in the world of infinite complexity that we work in, the engineering disciplines are not enough, they are too confusing for me anyway. I look for simple solutions in this complex environment with an artistic eye. These pictures are subjective art, they are not right or wrong, I hope they are useful, I hope they make the team feel good.--PaulCaswell
4-Tier Generic Picture using WebSphere Terms
This picture is a consolidated (and colored) view of several models contained in IBM's Web Sphere documentation. The question marks on the protocols highlight a choice to be made (not that we don't know how to!). This second picture is included to show how a structure can be reusable. An SEI definition of architecture that I came across a few years ago stuck with me: "An intellectually graspable, transferable abstraction of a system" This is an attempt as this:
--PaulCaswell
4-Tier AnimatedArchitecture
EditText of this page
(last edited February 5, 2002)
or FindPage with title or text search