I enjoyed this article. It presents a thought-provoking perspective on the definition of software architecture and the role of the software architect. His cynicism is surprisingly accurate. When I finished the article I was pleased with the way the question posed by the title turned out to be rhetorical. You learn what types of architects to avoid and what type of architects to look for and/or aspire to be.\n\nInteresting quotes\n\n“In many ways the most important activity of Architectus Oryzus is to mentor the development team, to raise their level so they can take on more complex issues.”\n\n“Improving the development team’s ability gives an architect much greater leverage than being the sole decision maker and thus running the risk of becoming an architectural bottleneck.”\n\n“An architect’s value is inversely proportional to the number of decisions he or she makes.”\n
I disagree with a few key points. There are some underlying "architectural" structures that you will generally want placed. It is useful to have a high\nlevel design of your program that are rigid. By having such rigidity, you can set a standard for which everyone to follow and plug into. That is not\nto say that the architecture cannot change, but rather it can evolve through extension, rather than through total modification (which he seems to think\nis an essential ability for your program to be able to do). As for having a separate "architect", I agree most with the "tour guide" person, but then,\nhow is that any different from lead designer, lead programmer, or just "general manager". The person who knows the most about the direction your\nsoftware is going. Basically architect becomes a fancy word for manager. Except we all hate managers, we can live with an architect.\n
The article "Who needs an architect?" by Martin Fowler gives several interpretations of the 20 definition of architect and\narchitecture. One of the possible definitions that he gives for architecture is "things that people perceive as hard to\nchange." I agree with this statement. Implementing systems to facilitate change within the software does not simplify the\narchitecture within the system. The example that he gives where a system was created to enable schema updates to the database so\nthat the schema could be changed with ease, does not change the complexity of the architecture. It just removes the schema from\nhaving to be defined within the architecture, and replaces it with the new and more complex schema update system. This definition\ncould be changed to be: A description of the complex systems/processes within an application.\n
Honestly, some parts of this article I did not understand at all, other parts did make some sense. The use of the word architect has\nchanged over time, as do so many other words in the english language, which causes confusion for some. I do not see the point of stripping\nsomeone with a title of "architect" just because they may see the meaning of it differently then others around him. However, along\nthose lines there could be created a newer, up-to-date name for the field which would fit perfectly, it just needs to be agreed upon.\n
[[Your comments on Who Needs an Architect?]]
The word "guide" does not fit well because software development, even at the highest level, includes creation. A guide does not create anything. The problem with "architecture" is that we don't know what we are building at first. If it's a building, bridge, or cathedral, the end product of form and function is known. Architects can then be used to design creative instances of these forms. With software, the space of creation is boundless,\ntherefore it might be impossible to predict what should be created. I do think architects can exist in specific domains of software development. eg. game programming, and web design.\n
Upon reading this article I quickly came to realize I have experienced first hand the guidance of an "Architectus Oryzus" who is\nsuch an elusive and rare animal in the software field. Martin Fowler describes an architect as a coach in his "Is Design Dead" article. I\nwould describe my encounters with the architect I know as more of a medieval caste system with apprentices and what not. You are allowed\nto do "dangerous" coding (has faith in his programmers), toss around ideas, come to him for help, and even attend meetings with him and\nthe user community. He by no means holds your hand, but is there for advice and allows others to become familiar with the structure of the\nprogram as it is laid out and takes criticism constructively concerning change. He doesn't just design he codes and sits in a\ncubicle just like the rest of us. The way it seems is that the architect is, much like the caste system, preparing future\narchitects. \n\nHowever, from what I read it seems as though the current situation plays the architect out to be the ruling class Bourgeois and the programmer out to be the Proletariat working class of the capitalistic society. This appears to be how a bad architect handles his programmers, almost like job security as well. He is the only one who knows every detail of the architecture and how it functions. A lot of the success it seems depends on what Martin Fowler says in his "Is Design Dead" article the human aspect. The quality of the structure must remain high, and this ". . . is one of the tasks that usually falls under the term 'architect'", according to Martin Fowler. In his article Martin was referring to the quality of the design, I think that not only does the quality of the design matter but also the quality of the human relations between the architect and the programmer. I believe that this also would fall under the human aspect. I believe that the quality of the architects work depends greatly on his pride in what he has done; I for one would not let something I take pride in turn to garbage. While this may be true the architect must also not be stingy with his work and share it freely and take advice from his fellow programmers.\n\nWith my past encounters with the architect that I know I have not been soured or disgusted by the term, I admire it and I believe that I would be grateful for the title of architect; I just wish it wouldn't come with such a negative context. It seems as though a great many bad architects have however ruined the name for the so few good ones.\n
After reading Martin Fowler~Rs article ~QWho Needs an Architect?~R it seems that the author intentionally misleads the reader to the dramatic answer ~QNo One~R. He does this by drawing a line between architects and developers. He claims the general definition of an architect is,\nexclusively, the person who makes all the important decisions (Architectus Reloadus) and/or the person who monitors and guides a current project\n(Architectus Oryzus). To replace the architect, Fowler adapts the term ~Qguide~R to refer to a developer who steers members in the right direction\nbut also leaves them to fend for themselves. These two roles seem to do the same job, but since one interacts with the developers, it appears more\nsuccessful, thus negating the importance of an architect. Fowler still acknowledges the importance of organization and planning, but would rather\nthose operations be done by expert developers involved in the programming. By theory they are the architects. And this is a comforting notion to the\nauthor because these new ~Qarchitects~R have their feet wet when it comes to coding.\n\nThe article also makes an assumption about architects in that they only decide on things that ~Sthey perceive ~E are hard to change~T. From this he follows that unlike building architecture, software architecture changes are easily made and should not be seen as static permanent fixtures. Although this is true, the original question was asking why architects feel the need to get things right the first time. He assumes irreversibility is the only concern an architect has when creating his design model. Fowler ignores other factors (such as correlating projects, time, cost, etc) and fails to\nrecognize that even the expert developers, the ~Qguides~R who might design the model, will take the same factors and more into account. More because they have a stronger familiarity with how the programming process works. He has shown architects are not needed, but architecture is still important. If an architect is removed, the same tasks of design planning will have to be done by the developers, in theory making them the architects.\n
I find it intriguing to read "Who Needs an Architect?". I tend to agree with the view of "Architectus Oryzus" simply because its\npracticality and flexibility. However it doesn't mean that following this trend of school will encounter less challenge for the software\ndevelopment. My opinion is that for one, this kind of talent is harder to find because he/she not only must be technically sound as\nan expert developer, he/she also has to be excelled in people relationship in order to integrate the people seamlessly with the\n"intense collaboration". Secondly, if the "guide" is doing his job right, he's supposed to by mentor all developers and raising their\nlevels to an extend so that everyone's design/input can be taken in and integrated seamlessly without the "guide"'s own design/input. \nThis sounds legendary to me since we know that there are so many ways to implement a software solution and people's imaginations, design\napproaches and organization styles are so vastly different. It's almost like to do a floor project of 12" tiles with 5 contractors. \nWe will end up with 5 different tiles with 5 different grout colors. This floor might be useful, but hardly presentable.\n\nI also agree with the idea of "Making something easy to change makes the overall system a little more complex". But how "a little more"\nis the question. Since I'm rather ignorant about Aspect Oriented Programming, I'm still unfamiliar with the necessary techniques to\nseparate the aspects of programs. To me, the challenge of knowing how to define, design and separate aspects seem to be easier to be\nhandled by one individual, the architect, rather then the whole team of the developers. This makes me believe that getting rid of the\nsoftware architect might be just a bit more difficult and cost then it appears to be in this article. \n
The idea that the article impressed on me, is that an architect's job is not to create a perfect system at the start of a project. Instead, the architect\ncreates a basic, high level design of the major components, then works with the designers and programmers to help them understand and implement the design. He also listens to their feedback and determines if the architecture needs to be adjusted. The architects role is more like a mentor to the rest of the team than an expert who simply states how things are going to be done.\n
I just finished reading the article. It seems to me this is a term people have started using to give importance to their role. Based on\nwhat the article stated, the term "architect" has multiple meanings and it is all based on what people's opinions are. No one can truly\nsay whether some things are important or not. Even as a group of programmers, or designers, or anything, perception of things is\ndifferent for everyone. In this way, the term "architect" becomes widely used, but at the end, no one really knows what it means or\nwhat to really expect from an "architect."\n\nAlso, it said that for software, the term should not be used. I think we should come up with a term that describes the role of the\n"architect" in a better way more related to what we, as computer scientists do. Maybe the "key guy" or something to that effect that\nclearly states this is the person to go to in times of need, and also the person who will guide and help during the process of development\nof any project.\n\n
Who needs an architect? Well, I think I'm not in a position to answer this question, because I barely know anything about the notion\n"architect" until the last lesson. However, I'll try to discuss something in this article that related to my past experience.\n\nI've developed a GIS application for a teacher in China. I worked with 3 other students, and I am the "team leader". As a team leader, I\ntried to draw a big picture of what our product will be, and I partitioned it to 3 different parts: interface, database support, and\nGIS engine support. I undertook the interface work myself, because I know that is the entity which actually defines requirements for the\nother 2 and also plays a key role in integration. This proved to be the most important decision I made to maintain our project from\nfailure. I made a lot of bad decisions later, but by undertaking this crucial part of the project I could always be aware of current problem\nin the project at first. Also it ensured my control of the situation. But these advantages came with a price: sometimes it's like\nthat I'm doing everything myself.\n\nIn fact I tried to discussed with the team members and come out with some consents on the overall design. But I found they are not very\nmotivated on this. They preferred that I give them a task and they will just do it. Anyway, I went on and formulated this partition into the definition of interfaces(we use c#). Perhaps from this point I unconsciously put myself on the position of Architect Reloadus. Anyway, I felt good about what I'd done. I even came up with a very optimistic time schedule, anticipating that we'll build the big structure within a week. This blind optimism further reduced the leeway I reserved for change.\n\nI promised to give the outline version of the interface to others in 3 days so that they could test their classes on it. We had a meeting and\nwent on separately to write codes. However, soon I discovered that I was very lacking in the field of GIS(although the teacher brought\nsomebody to give us a lesson). And more than that, I found that HTML and java script are not as easy as I thought, not to mention ASP.NET.\nAt last I had to admit it would take me another week to learn about these development tools. And since I didn't accomplish my own task, I\ndidn't ask others about their progress because I tought I was in no position to push them. Later I found this a big mistake in that I\nstopped communication when things went bad. In fact later I found all others encountered difficulty when it came to real\nimplementation. About a week later the GIS engine part was completed, because its interface was proved to be OK, and the guy working on this\nwas indeed smart and experienced. But still he told me that it was too difficult for him to implement some of the methods in the\ninterface. However, The database part turned out to be a disaster.\n\nAt first I thought it a good idea to encapsulate all the database operation into one class. But the guys working database found that all\nsample codes in the Internet call database inside ASP.NET web pages. In those examples web pages and database are well\nintegrated. In fact later I found that there will be too many misc trivial tasks in the database class if we completely encapsulate all\nthe database operations in it. Naturally, they soon found their knowledge lacking in multi-thread access of database, and later they\nrealized that there were too many required operations that were hard to clearly communicate all the requirements and also awkward to\nimplement. At first they began to hack on this bravely(May be too bravely that they began to do things in stupid ways. Because they\ndidn't want to waste time in the "ceremonial" designing.), and later when the work became intractable, they stopped and gave me a\ncollection of barely working code and trash.By that time, I found it extremely difficult to have the team motivated. In the article the\nAuthor talks about contain complexity by reducing irreversibility, but I really want to know how to easily change to another design after the\ninterface is proved to be wrongly defined. Maybe if I had made some preparations in advance it could be possible, but I really want to\nknow how to do this. The only thing I could do was to remedy the trouble in my ASP.NET web pages. But the initial design was inevitably\ntorn apart. I fought along for several night and days. Than the database guys came back to me and decided to solve the problem with\nthe experience we'd gained so far. At last we came out with a barely working system, which I felt very disgusting. And all of us felt\nexhausted.\n\nBefore I read the essay of "Who needs an Architect", I always thought that the main problem I had in this practice was that I hadn't planned well. Should I be experienced enough to correctly design the database interface, to propose a more feasible time schedule taking the\nlearning curve of members into consideration, things can be different. However, my intuition told me that it's too hard to plan\neverything well at the beginning, which made me very frustrated. After reading "Who needs an Architect", I would gladly embrace the author's\nnotion that an architect can't and shouldn't be so perfect that he designs everything well enough at the beginning. Software development\nis like an exploration to an unknown region. You may point your destination on the map but you never know where it is and how to reach\nit after you have reached it. The architect is the captain who marches with the team. He constantly evaluates what's ahead of the team, and\nmakes adjustments to the orientation. Also he constantly evaluates the environment the team is in, and creatively adopts the most adaptive\nway of marching. He reviews the status of team members from time to time. Then he gives proper instructions to individuals, or formulates\npolicies, or changes the deployment of human resources, so that team members can handle their work capably and effectively. He makes and\nreinforces important decisions, but also he communicates with his men and listens. He may make mistakes himself but he never gives up\nlearning from experience. All leaders do things like this, why shouldn't an architect be the same?
[[Your comments on Who Needs an Architect?]]
The common question one always hears from students of Calculus is "Why didn't the professor just show us this way to do the problems?" Students are frustrated with professors as developers/programmers with the software architect. The software architect exhibits a feeling of great (sometimes offensive) satisfaction with oneself, a self-righteously complacent image, a figure of authority; majority has a tiny tendency to go against authoritative power. Whatever your feeling may be toward the architect, one has to accept the fact that the architect is an important figure in the development process. The architect is like a guide, who is more skillful, more experience, who knows the shortcut, the obstacles along the road to the top of the mountain. He makes the important decisions, mentors the development team, ensures the system's conceptual integrity, and pushes the team members to take on more complex tasks. The architect can be your best friend when he is open to suggestion, "shares understanding of the system design", and has at least the same level of programming knowledge as the developers. He can also be your worst enemy, like the professor who keeps talking about theories and proofs without showing you how to apply them to a simple problem. "An architect's value is inversely proportional to the number of decisions he or she makes." Developers by themselves without guidance will start changing codes at their own wills. "Making something easy to change makes the overall system a little more complex, and making every thing easy to change makes the entire system very complex." The architect is there to ensure the system is divided into components and the "components" talk to each other before making drastic changes. However, he needs to understand that the success of the project depends on the group consensus and the "happiness" of his developers.\n
The architecture of a software system is its organisation or structure of significant components interacting through interfaces ,those components being composed of successfully smaller components and interfaces.In the other words it can be defined as a shared understanding of the expert developers about how the components interact through interfaces.These components are usually composed of smaller components,but the architecture only\nincludes the components and interfaces that are understood by all the developers.This shared understanding is called Architecture.\n\nSoftware is not limited by physics,biology.....It is limited by imagination,by design,by organisation.Architecture is a set of design decisions that must be made right early in the project. Inorder to have a expert design and organisation we obviously need a pragmatic architect who even have better understanding with the application developers.\n
The paper, which is a good paper, highlights the misconception that the architect is the puppet master, the one who’s actually running the project, and making every single decision. It clarifies that that architect is usually a hindrance to the project. The paper says that the kind of architect that we’re looking for is a guide. He assists with the project, maybe gives it a direction, but doesn’t actually do everything in the project. And I agree, basically. The overblown version of an architect isn’t useful for any project. And its difficult (as is also elaborated) to make the important decisions first, when you don’t know what you’re doing.
Your comments on Who Needs an Architect?
This article was an interesting read. I like how Fowler defines two species of architects. Architectus Reloadus is likened to the\narchitect of the "Matrix" - the one makes the big decisions but has no role to play in their implementation. The other species -\nArchitectus Oryzus - is characterized more as a experienced team leader, one who still makes the big decisions but makes them in\ncolloboration with other team members. This species of architect plays an important, hands-on role in the development of a project and\nidentifies potential problems or pitfalls along the way. Fowler's essential argument is that this second species of architect is an\nimportant player and one who not only deserves the nebulous term "architect" but gives the term somewhat of a structured definition. \n\nI think the Architectus Reloadus species of architect can be likened to the boss that no one likes. The one who has no real experience in\nthe field he is supervising and no real camaderie with those he is supervising. Notwithstanding this, he is the one in charge, making\nthe important decisions. This image of an "architect" is one that we all inherently dislike. Architectus Oryzus, one the other hand, is\nthe caring, supportive, and involved boss who mentors as he fulfils his duties as a supervisor.\n\nOverall, I like how this article proposes a more functional definition and way of thinking about a software architect rather than\nentirely condemning the term.\n\nInterestingly, there is a paradox in the article. In discussing software complexity, the articles quotes the following, "[M]aking\neverything easy to change makes the entire system very complex. Complexity is what makes software hard to change." This statement\nimplies that if software is easy to change, then it is hard to change. This sounds like the logic that my code sometimes has. :)\n
After reading this article, I realized that the position known as software architect is not very popular, at least, not what the architects now-a-days are doing. The architect should monitor the project and make sure no serious problems arise. However, the rule of thumb is that the more decisions the architect makes, the lesser his or her value becomes. The architect's decisions affect the group that he is working with, making his position a more social position. And unlike a building architect, a software architects decisions do not hold as much weight because they can be changed easily.
In the article “Who Needs an Architect” by Martin Fowler, the definition of “Architecture” is described through the viewpoint of Software Engineering. The definition of architecture by IEEE outlines it as being the highest level concept of a system in its environment. At any point in time, this would be a software system’s organization or structure of interacting components. The author disagrees with this definition for the reason that he believes there is no “highest level concept of a system” since customers see a software system differently than programmers do. \n\nHe favors the definition given by Ralph Johnson which states that architecture is the shared understanding that expert developers have of a system’s design. This system is composed of interacting components which are in turn composed of more components, but the architecture only includes those understood by all developers (“the important stuff”). \n\nThere are two types of architects. One is a person that makes all the important decisions regarding the system ahead of time so all team members have a plan to follow. The second type acts as a mentor and collaborates with the team making the decisions during the development. The author prefers the architect who collaborates and acts as a guide for the team. \n\nIn developing a software system, the architecture is usually the first thing addressed because it is believed to be the hardest to change once the system is live. Because of this, Fowler believes that the main goal of an architect should be in getting rid of software architecture as to make it easier for change. An example of this would be a database administrator devising a system that would allow for change in the database schema and data migration. By doing this, any aspect of the software can be easily modified. \n
In the development life cycle from what I have seen, which is not much mind you, I have always been unsure of where an 'architect'\nmight fit in. At the start it is the customers' responsibility to give purpose to the project. To take what the customers want and form\nit into software would be difficult, because half of the time the customers don't even know what they want. I hardly see the role of an\narchitect to take customer requirements and give them to the developers. Rather that sounds like a role for a project manager,\nsomeone who wouldn't need to know anything about development, but instead would act to make decisions on the customer's behalf and\ncreate a list of requirements for the project. Someone would then need to take that list and create an overall project design, this\nsounds like a job an 'architect' may have and from what I've read and heard this is what most do. In a smaller project a person who\ntranslates customer requirements into program components would most likely be the lead developer who would have other responsibilities as\nwell. For larger projects, I can see where this task could be large enough for a single person to be solely devoted to it, yet I fail to\nsee how the title of architect fits the job. If anything I would use the title Software Designer, as the job is to create a software\ndesign for the developers to make.\n\nWhat I don't understand though, is why there is so much controversy over the title of architect, regardless of the title there is still a\nrole to be filled. Someone will need to be there to delegate responsibilities, keep the developers working together, and find a\ndesign that will fulfill what is needed. What difference would it make if the designer were called an architect, engineer, or logical\nwork flow expert? I feel the industry would do better by further developing standards for design then bickering about titles.\n
The ideas expressed in Fowler's article make a lot of sense. Certainly, if the person "in charge" of the decisions works closely\nalongside the development team, the project will move much more smoothly. Everyone knows not just their part of the project, but knows\nexactly where that part fits in the whole, and as a result can make their own decisions smarter with that in mind. In many ways, calling\nthis architect a "guide" is very apt term; this architect's job is to know how to reach the goal, so to speak, and shows the programming\nteam the way to reach it, allowing individual team members the freedom to apply their own experience and understanding to the problems they\nencounter. Having worked in small projects that operated in much this manner, I know that this style allows for flexibility and strength in\nthe development process that is invaluable in ensuring a good product. On the other hand, I'm uncomfortable with his apparent "absolute\nminimalist" attitude he adopts. He appears to shun any hierarchial structure in the team, entirely favoring this "level playing field"\nposition for the architect. I am hesitant to embrace this position with as much gusto as the author because it occurs to me that there\nare times when, for the sake of speedy development with a larger, more diverse team, a single leader helps to "ensure a system's conceptual\nintegrity" as he put it. Clearly there are problems associated with a far-removed architect drawing up a plan and sending it to the team,\nbut it seems to me that flexibility demands an architect willing and able to adopt a stronger managerial style when needed to smooth any\nbumps a team may encounter.\n
I asked you to write a paragraph on what you think about the Martin Fowler article with above title.\nHere are your comments, in the order received... Interesting read...\n[[starting with a vibe...]]\n[[Beg to differ...]]\n[[Have seen that architect...]]\n[[Who is he and why?...]]\n[[Much like a frustrating prof...]]\n[[Intentionally misleading...]]\n[[Puppet master...]]\n[[Need pragmatic architect...]]\n[[It's evolutionary...]]\n[[Yay for guide, Nay for absolute minimalist...]]\n[[Species of architects...]]\n[[Why so much controversy...]]\n[[Guides don't create...]]\n[[Accurate cynicism...]]\n[[Confused about meaning...]]\n[[Changing definition...]]\n[[Key guy...]]\n[[The rule of thumb...]]\n[[Intrigued...]]\n[[Lessons learnt...]]
When i first started reading the article i was getting the vibe that all an architect does is make important decisions. then it went and\nstated to kinds of architects. The Oryzus architect seems to be the one that we want to surround ourselves with because he seems to be a\nteam leader, and is present for all aspects of the design. makes important decisions and works with developers. So, basically from\nthis article, all a computer architect is...is an expert developer and mentor for the team.\n