Defining software architecture roles

Home

News: Defining software architecture roles

  1. Defining software architecture roles (50 messages)

    Marty Andrews has written "Defining software architecture roles," which describes what system architects, solution architects, and enterprise architects' actual roles are.
    A System Architect, sometimes also known as an Application Architect is someone who typically designs and builds a single system. They care about the internals of the software system at least at a coarse grained level. So they might describe what internal components a system has for example. In addition, they probably will influence what frameworks or 3rd party API's are used to build those internal components. They may or may not be interested in finer grained details like the classes or patterns used by developers on a dail basis (if they're any good, they will, but I'll talk more about that later). Finally, they will probably care about a deployment environment for the system as well. The application server, database, operating system, firewalls etc are all in their scope of concern. A Solution Architect is someone who designs and builds interactions between multiple systems to provide a solution to some business problem. They care about the edge points of systems so they can figure out how to wire them together. This might be databases, queues, web services, or other programming API's that can be used. The internals of individal systems aren't so much of interest to them. Deployment environments are often even more of concern to Solution Architects, as they need to get multiple systems to play nice together in the same environment. An Enterprise Architect is someone who designs and builds interactions between multiple solutions in an organisation. They typically exist in organisations that have been around for decades, so therefore have built up literally dozens of legacy systems. They don't really care so much about technology, except at a very high level. Solutions will often be identified by Enterprise Architects, so they may allocate a Solution Architect to drive further detail on the problem.
    Do you agree with his definitions? What role are you in?

    Threaded Messages (50)

  2. Up until a couple of weeks ago I worked as a "solution architect" for one of the oil majors. The point about older companies having hundreds (or thousands in our case) of legacy systems is well made. In these sort of situations, the architect often has to take into account years of baggage, database upgrades, network reconfigurations, system migration, IT centralizations, IT decentralizations, mergers, demergers and anything else the suits can conceive to make life, err, interesting. All of it leaves an environment that is usually suboptimal and where people issues are as important as technical issues. The architect has to deal with it all. In our case, the solution architect was really a combination of the authors "system" and "solution" architect and did all the real work ;) The enterprise architects were responsible for strategy (ie. how to reinforce the ivory tower to take the weight of them all) Kit
  3. Re: Defining software architecture roles[ Go to top ]

    In our case, the solution architect was really a combination of the authors "system" and "solution" architect and did all the real work ;) The enterprise architects were responsible for strategy (ie. how to reinforce the ivory tower to take the weight of them all)
    I have observed this in my organization as well. Even though my formal title is "Application Architect" I am equally concerned with interactions and integrations of hundreds of systems as well as the internal system architectures. I see the System/Application Architect and the Solution Architect becoming a unified role for many organizations as they mature in their adoption of Agile principles, especially the concept of favoring generalists over specialists when possible. IMHO another driving force for the merging of these two roles is the transition from primitive to contemporary SOA models.
  4. I cannot agree with Mr. Andrews definitions though I support any attempt to bring some standardization to these titles. I just don't see the definition he uses being applied in the same way at the places I've worked. I've noticed that we have quit calling project architects "application architects" since that term has been appropriated by enterprise architecture (data, application, business, technical). Where I am (the largest systems integrator in the world or close to it) we often use the term "systems architect" for the hardware/platform architects, though we a somewhat inconsistent. I'm called a "software systems architect" which distinguishes me from the hardware/platform guys. I've noticed a trend in job ads, recruiters and modeling tools to call any project architect a "solution architect" regardless of whether legacy systems are involved or not. It seems to suppose that enterprise architects define the architecture and frameworks to use and that "solution architects" apply those architectures to solve a particular business problem.
  5. I use Platform Architect to define a role between Solution Architect and Enterprise Architect, a platform being a number of cooperating systems. A Platform Architecture provides a set of service oriented capabilities. For example a mobile opco Service Delivery Platform. The Platform Architect may not be responsible for the actual composition of services utilised in any particular solution, but is naturally a key member of the relevant project team. Like an Enterprise architect they retain an overall 'big picture' approach to the solutions which depend upon the enabling architecture, and play a role in balancing possibly conficting demands upon the strategic roadmap of any one particular system.
  6. I think these (and other) roles dont make much sense as long as there does not exist any official/formal defintion and recognition for them, along with a well-defined curriculum that one must have completed successfully. Apart from that, anyone with a decent amount of experience in software development will nowadays call him-/herself an architect (of whatever variation) - and they'd be stupid not to.. -C
  7. I think these (and other) roles dont make much sense as long as there does not exist any official/formal defintion and recognition for them, along with a well-defined curriculum that one must have completed successfully.

    Apart from that, anyone with a decent amount of experience in software development will nowadays call him-/herself an architect (of whatever variation) - and they'd be stupid not to..

    -C
    +1 I would also add that, unfortunately (unfortunately ?), the devil is in the details and a strict role definition might easily end up in a "noone having a global view" syndrome. Every architect correctly designs the aspects concerning its role and the final picture is simply a big mess. But, fortunately, there is the integration architect :) Guido.
  8. Re: Defining software architecture roles[ Go to top ]

    Who really care about these titles? here is my moto "show me money, I will get your problem solved; you keep glory, I keep money." If developer can make $150000, and architect only makes $100000, I would rather be a developer. Only ignoran person care more about title, if problem is sort of challenge, I may work for less though.
  9. SMTM Methodology[ Go to top ]

    Who really care about these titles? here is my moto "show me money, I will get your problem solved; you keep glory, I keep money." If developer can make $150000, and architect only makes $100000, I would rather be a developer. Only ignoran person care more about title, if problem is sort of challenge, I may work for less though.
    +10 -I live by the "SMTM" Methodology as well. => If you are leading(decision maker) an effort of building a System from the ground up you are considered a Software Architect.(if its a J2EE based system, J2EE Architect)...my 2 cents. SMTM = Show me the money.
  10. Apart from that, anyone with a decent amount of experience in software development will nowadays call him-/herself an architect (of whatever variation) - and they'd be stupid not to..
    Exactly! Peace, Cameron Purdy Software Architect
  11. Apart from that, anyone with a decent amount of experience in software development will nowadays call him-/herself an architect (of whatever variation) - and they'd be stupid not to..


    Exactly!

    Peace,

    Cameron Purdy
    Software Architect
    I actually apply that thinking to all of the things that I have considerable experience with. John Murray Software Architect Vodka Architect Casino Architect Love Architect
  12. Apart from that, anyone with a decent amount of experience in software development will nowadays call him-/herself an architect (of whatever variation) - and they'd be stupid not to..
    The SCEA certification from Sun is making a big joke these days. People with some experience and 15 days of slogging clear the SCEA certification exam and then start claiming to be an Enterprise Architect demanding way higher salaries!!! A good architect doesnt only have just this paper "knowledge" but has a big picture of the whole system and at the same time is also aware of the nitty-gritties of the system, has real good hands on experience and also capable of communicating the ideas to the development team. And by communication I dont mean just UML diagrams. Sometimes developers do not understand a purpose of a design with a simple UML diagram. This is where an architect (like somebody said "mountaineering guide") will help the team understand the purpose behind those designs. SCEA certification is not a benchmark of quality of the architecture that guy can produce.
  13. Title Inflation[ Go to top ]

    The title of "Architect" has no place in the software industry. Architect in its traditional meaning refers to people who draw a blueprint for a building project. People who actually do the work of building from the blueprint are manual labors who know (and need to know) nothing about the overall structure, physics and stability of the building, and the composition of the building materials. They simply dig a big whole in the ground, assemble the beams and columns, and lay the bricks. Thus many construction workers today are unskilled and sometimes illegal immigrants. In software, those who actually do the coding have to know just as much if not more about the overall system than the "architect" because they need to find out exactly how to communicate with various subsystems. While in the construction business, all the bricks and beams and nails are already prefabricated, software components are highly customized because we build software to do very different things. What end up happening when the software companies decided to push the hierarchies in the engineering office is that many incompetent engineers who can throw around buzz words in front of managers get promoted to the "architect" level where they don't have to do any real development and get paid more than those who do. The good engineers are increasing frustrated and go on their own as independent consultants or work for small companies that don't believe in title inflation. That's why many big software companies can't hire good engineers today.
  14. Re: Title Inflation[ Go to top ]

    I'm sorry, but you have written nonsense. The term "architect" has been in use in IT for a number of years. Yours is the same argument "real engineers" use against the term "software engineer". The problem with the title "architect" in IT is that its lost much of its meaning as every lead or senior programmer or technical lead seems to want to claim it as their title possibly in hopes of more money or prestige. There are clear differences in IT between architects and engineers or developers. It is a forest versus trees sort of difference. Architects begin by studying and modeling the problem domain whereas those who think like engineers or developers tend to move more directly toward a solution to the problem in front of them. The architect discovers reusable patterns and defines a solution to a problem domain not just a specific problem. An architect's solution has broad applicability. (Which can be overkill in some situations.) Developers' solutions tend to be much more narrowly focused. Developers also tend to be more detail oriented. Architects often stop at interfaces, roles and interactions. They establish boundaries and protocols and are usually happy to leave the implementation of what falls within a boundary to the engineers. Basically architects add long term value (flexibility, adaptability, simplicity, etc.) to the solution the engineer creates. When interviewing candidates I can always tell the difference between those who think architecturally versus those who think like developers. Both types are needed, but you don't want to place one in a position intended for the other.
  15. Re: Title Inflation[ Go to top ]

    The problem with the title "architect" in IT is that its lost much of its meaning as every lead or senior programmer or technical lead seems to want to claim it as their title possibly in hopes of more money or prestige.

    There are clear differences in IT between architects and engineers or developers. It is a forest versus trees sort of difference. Architects begin by studying and modeling the problem domain whereas those who think like engineers or developers tend to move more directly toward a solution to the problem in front of them. The architect discovers reusable patterns and defines a solution to a problem domain not just a specific problem. An architect's solution has broad applicability. (Which can be overkill in some situations.) Developers' solutions tend to be much more narrowly focused. Developers also tend to be more detail oriented. Architects often stop at interfaces, roles and interactions. They establish boundaries and protocols and are usually happy to leave the implementation of what falls within a boundary to the engineers. Basically architects add long term value (flexibility, adaptability, simplicity, etc.) to the solution the engineer creates.

    When interviewing candidates I can always tell the difference between those who think architecturally versus those who think like developers. Both types are needed, but you don't want to place one in a position intended for the other.
    I would partially agree with you if all software projects are building common platforms, reusable libraries or services. But the fact is most software projects are trying to build applications with very specific purposes in mind. Even in creating large systems, a lead engineer with enough experience can come up with a good overall design with well-defined boundaries and he is accountable to it. We don't need "architects" to come in and dictate the design but are not held responsible for their decisions because it is an "application" project and not on the "system" level. Another fact about software engineering is that we are supposed to be engineers, not artists. We solve technical problems for a living. When you have a position like "architect", who is not responsible for coming up with creative solutions to specific problems and tracking down nasty bugs like an real engineer does, but get paid more and enjoy higher prestige, who wouldn't want it? There is no "architects" in electronic engineering or chemical engineering. I don't see those fields being complete chaotic with no standards and interfaces. I can understand why the position of architect was created in the first place. The industry wanted to separate the designers from the low level programmers just like a car factory assembly line that has engineers and assembly workers. But software is inherently different. It takes a lot of brain power to write software code. An auto worker does not have to take the car apart to examine what is wrong with it when there is a defect or try to fit a square piston into a round cylinder like a software engineer does with their programs everyday. So don't tell me that an architect can make the software better when he/she doesn't have to deal with specific problems like an engineer.
  16. Re: Title Inflation[ Go to top ]

    I think both of you are right in different aspects. An "architect" will be quite important to overseas big projects with numerous teams of developers, especially when the team leads dont agree with each other. On the other hand, if a certain team lead is capable and is able to gel and build concensus with other teams, then he/she is acting like an "architect" without needing that title at all. As for smaller projects, I would say an "architect" will be an overkill.
  17. Re: Title Inflation[ Go to top ]

    I think both of you are right in different aspects.

    An "architect" will be quite important to overseas big projects with numerous teams of developers, especially when the team leads dont agree with each other.

    On the other hand, if a certain team lead is capable and is able to gel and build concensus with other teams, then he/she is acting like an "architect" without needing that title at all.

    As for smaller projects, I would say an "architect" will be an overkill.
    I think you are selling short what good architects can do for IT. Though I agree that on many small projects too much architecture can be overkill they can also be over engineered. I've seen many "small" and "stand alone" projects" that shouldn't be small or stand alone or possibly even projects if a decent architectural vision was in place. How many ways do you need to write a distributed OLTP (or pick your app type) system using a given set of technologies? How much justification is there really for anything butthe business logic and the data models begin different? That is one of the things architects should try to shake out. If we built cars the same way we build software, few could afford one.
  18. Please stop this...[ Go to top ]

    Here is the definition of the the word architect (according to the Oxford English Dictionary anyway) architect • noun 1 a person who designs buildings and supervises their construction. 2 a person responsible for the invention or realization of something. • verb Computing design and make (a program or system). Therefore arguing that it shouldn't be used to describe someone who doesn't design building is ridiculous. It is just semantics, meanings of words are not fixed, and nor should be.
  19. Re: Title Inflation[ Go to top ]

    When interviewing candidates I can always tell the difference between those who think architecturally versus those who think like developers. Both types are needed, but you don't want to place one in a position intended for the other.
    William, can you tell from your own experience, which is percentage of architectually thinking guys and developer-oriented minds? Simply interesting. I think to be a good architect (say in JavaEE field) you should be a very good developer and at the same time a strategically-oriented person. A man could be very good at modelling but awful with development, and as result will never be able to do his architect job fully and effectively. How many such people you have met? I tend to believe that this is a rarity.
  20. Re: Title Inflation[ Go to top ]

    When interviewing candidates I can always tell the difference between those who think architecturally versus those who think like developers. Both types are needed, but you don't want to place one in a position intended for the other.


    William, can you tell from your own experience, which is percentage of architectually thinking guys and developer-oriented minds? Simply interesting.

    I think to be a good architect (say in JavaEE field) you should be a very good developer and at the same time a strategically-oriented person. A man could be very good at modelling but awful with development, and as result will never be able to do his architect job fully and effectively. How many such people you have met? I tend to believe that this is a rarity.
    In my experience about 10% of the developers I've met are capable of abstract thinking at a level where they could become good architects. Of course only about 1/2 the developers I've met can design or code worth a damn. (I'm being generous - and don't get me started on the sorry state of IT "management".) I've also noticed that a lot of "architects" aren't because they cannot abstract (too literal or too caught up in details) or they were never technically competent or have lost touch. You have to keep current enough to be able to translate your patterns and models into something your engineers can understand and appreciate. You cannot expect your developers to fully grasp your ideas and correctly translate them into implementation. A few can, but most cannot. If you are not technically current how would you even know? (I've seen that happen a lot.) I agree that good technical architects were also good developers. They should remain good developers (not necessarily the best developers) if they want to continue to be able to come up with good architectures and communicate them effectively to the developers. I wouldn't expect many architects to also be or remain great developers because of the qualities they have that make them really good architects - they never lose sight of the forest so they sometimes overlook some details about the trees.
  21. Re: Title Inflation[ Go to top ]

    When interviewing candidates I can always tell the difference between those who think architecturally versus those who think like developers. Both types are needed, but you don't want to place one in a position intended for the other.
    I couldn't agree more...
  22. Re: Title Inflation[ Go to top ]

    I disagree with both the statement and the analogy, but I do agree with some of the content in your message. In most traditonal building trades, the people who actually build the structure are quite skilled, and need to know a fair amount about structural engineering (at least in practical terms). Any builder or contractor will tell you gleefully the number of times they've saved a client from a bad piece of design from an Architect. Pre-nailed trusses and the like only remove manual labor and cost, not the need for skill and improvisation on the job site. In IT, the term is used precisely because the original role of an architect is/was to select the appropriate technologies and patterns to be used in constructing a system. Unfortunately, as you point out, there are a lot of people using "Architect" now to mean "I think I'm good" or "I want to be paid more". Often these are folks with 3-5 years of experience who may be good senior developers but aren't ready to be team leads or design large systems. Sadly, many companies can't tell the difference. Call me old-fashioned, but I think the concept of architect (a role, not a title) still makes perfect sense. The definitions listed at the top make sense to me, as well. And I think we would do ourselves and our industry a favor by paying more attention to project staffing by role and less attention to what people call themselves on their resumes. IMHO, of course.
  23. Re: Title Inflation[ Go to top ]

    Often these are folks with 3-5 years of experience who may be good senior developers but aren't ready to be team leads or design large systems. Sadly, many companies can't tell the difference.
    I agree with you there, but we can't paint with the broad brush in either case. I think when we interview candidates we just have to see, case by case, how good the individual is, regardless of the title. I know plenty of cases where the individual has only a few years of experience but is an excellent architect. Meanwhile I've interviewed guys who have 15, 20, 25 years of experience who are such BS artists it's amazing they can get away with it. Hiring managers need to know these defintions, sure, but more importantly they need to be able to distinguish between valuable experience and just fluff "years of experience". (hopefully that's not too off-topic)
  24. Yeah, I think that the description of these roles fits pretty well för most larger organizations, at least it does for the one where I am currently employed, and a few were I have been in the past. The most interesting of these beasts is of course the enterprise architect, which is usually reserved for older gentlemen who are very, very, very, out of touch with current technology. Not really a problem as long as people around them recognize that this role is really more of a management position than anything else. It can be great fun to discuss something current, lets take web services as an example, with someone who´s last last programming work was done on cobol, but who still is required to be an authority an all things technical.
  25. Politics is important too[ Go to top ]

    I have been an architect for number of years and I think that it is more important to have higher level of political skills than technical skills.
  26. Re: Politics is important too[ Go to top ]

    I have been an architect for number of years and I think that it is more important to have higher level of political skills than technical skills.
    I agree, but that sounds more like a manager's job.
  27. Re: Politics is important too[ Go to top ]

    I have been an architect for number of years and I think that it is more important to have higher level of political skills than technical skills.


    I agree, but that sounds more like a manager's job.
    Exactly, I have been doing software design over a decade, deliver right technical solution to solve business problem and technical problem are only my concern, I leave politics to someone like to handle it, such as PM.
  28. Politics is important too[ Go to top ]

    I have been an architect for number of years and I think that it is more important to have higher level of political skills than technical skills.
  29. The most interesting of these beasts is of course the enterprise architect, which is usually reserved for older gentlemen who are very, very, very, out of touch with current technology.
    You mean, somewone who doesn'nt know the Java framework of the week? Shocking, really!
  30. The most interesting of these beasts is of course the enterprise architect, which is usually reserved for older gentlemen who are very, very, very, out of touch with current technology.

    You mean, somewone who doesn'nt know the Java framework of the week? Shocking, really!
    Nope, that could be your definition of "current technology", but it is not one I would agree with. I was more thinking of someone who doesnt have any practical experience with the main development paradigms of the last two decades. Believe me, they exist, and right now they are all busy drawing the same crappy SOA/ESB picture on whiteboards and powerpoint slides, all over the world.
  31. Re: Defining software architecture roles[ Go to top ]

    Believe me, they exist, and right now they are all busy drawing the same crappy SOA/ESB picture on whiteboards and powerpoint slides, all over the world.
    Magic !!! I always like to put this picture besides this one http://www.cs.wustl.edu/~schmidt/editorial-5.html Guido.
  32. Re: Defining software architecture roles[ Go to top ]

    The most interesting of these beasts is of course the enterprise architect, which is usually reserved for older gentlemen who are very, very, very, out of touch with current technology.

    You mean, somewone who doesn'nt know the Java framework of the week? Shocking, really!
    Yeah. That is why I am afraid to go on vacation. :)
  33. Word[ Go to top ]

    A good rule of thumb when determining what you are, architect or developer, is that an architect must be very good at using Microsoft Word and going to meetings.
  34. Finally, they will probably care about a deployment environment for the system as well. The application server, database, operating system, firewalls etc are all in their scope of concern.
    Where is the development environment here? I don't see any IDE's, build system, test and code coverage facilities. Instead I read about the future runtime environment. Am I missing something here?
  35. Am I missing something here?
    Yes, 'deployment' not 'development'. In need coffee..... :)
  36. Some of you may enjoy Fowler's article "Who Needs an Architect?" check it out at http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf . He suggests that a good architect is a member of the team, a mentor to the team, and a guide (as in mountaineering) who is there for the "really tricky stuff."
  37. IMO[ Go to top ]

    IT managers --> ultimately strategic, tactically lame Architects --> highly strategic, tactically capable Developers --> optionally strategic, tactically savvy Architects are naturally filling a void between managers and developers by necessity. If that architect is really nothing more than an IT manager or developer, then it's not serving any real value.
  38. Re: IMO[ Go to top ]

    IT managers --> ultimately strategic, tactically lame
    Architects --> highly strategic, tactically capable
    Developers --> optionally strategic, tactically savvy

    Architects are naturally filling a void between managers and developers by necessity. If that architect is really nothing more than an IT manager or developer, then it's not serving any real value.
    Well put. I remember the first time somebody in my company referred to themselves as a software architect, I thought they were joking. I think it all started because they ran out of important adjectives to put in front of the word "engineer" in job titles and needed something that sounded important. Where it gets mushy in my company is the 'tactically capable' definition above. A lot of folks at the architect level allow themselves to become stale with technologies and end up having no clue. Regardless of whether or not you like the tag or not, the role is needed even if it is filled by a manager, a developer, or someone else.
  39. Re: IMO[ Go to top ]

    Where it gets mushy in my company is the 'tactically capable' definition above. A lot of folks at the architect level allow themselves to become stale with technologies and end up having no clue. Regardless of whether or not you like the tag or not, the role is needed even if it is filled by a manager, a developer, or someone else.
    Agreed. One of the proposals where I used to work was that the enterprise architects should do at least one project a year as solution architects. The thought of them getting their fingernails dirty almost caused a riot.
  40. TOGAF/DODAF[ Go to top ]

    Hi, What do you think about the TOGAF/DODAF/Zachman ? Aren't these attempts to standardize some aspects? Thanks, Mohan
  41. Re: TOGAF/DODAF[ Go to top ]

    Hi,
    What do you think about the TOGAF/DODAF/Zachman ? Aren't these attempts to standardize some aspects?


    Thanks,
    Mohan
    I have just read part of the home page of TOGAF and I have thought all the worst possible. Specially when I reached the certification part. Guido.
  42. Re: TOGAF/DODAF[ Go to top ]

    Hi,
    What do you think about the TOGAF/DODAF/Zachman ? Aren't these attempts to standardize some aspects?


    Thanks,
    Mohan
    These frameworks are more applicable to the enterprise level of architecture. TOGAF is a synthesis of a number of earlier architecture frameworks and is the now the basis for a number of others. The Zachman framework is complementary to TOGAF and other architectural frameworks, not competition to them. DODAF to me is a comic book architecture. It's being updated, but I pretty much follow TOGAF and translate my work to the AF of the customer - DODAF or FEA. FEA (the Federal Enterprise Architecture) by the way is not really an architecture framework at all. Its really designed for budgeting (it comes from OMB) and doesn't produce very useful architectural artifacts by itself. IMHO. For anyone serious about how architecture can or should drive IT, study TOGAF. Its pretty complete and current and generic enough to be broadly applicable. Enterprises that adopt it should - like any methodology - expect to extend and customize it for their own use.
  43. It's simple[ Go to top ]

    An architect is a developer with YEARS of experience.
  44. It's simple ... kind of...[ Go to top ]

    Though years of experience are unlikely to be a hindrance, I don't think it is as simple as that. Good architects and good developers approach the same problem differently, IMO. The good architect comes from the top down, abstracting the problem into it's fundamental concepts, mentally arranging the component parts and spotting patterns. The good developer comes from the bottom up, seeing what it would look like at deployment, the protocols used, the probable bootlenecks, the concurrency problems. It is possible to have people who are good at one but not the other, and they will have a valuable contribution to make. A great engineer is good at both, and rare. Kit
  45. Re: It's simple -- not exactly[ Go to top ]

    An architect is a developer with YEARS of experience.
    Some peoples have been many years as developer, but they can not solve any technical and business problems by their own (I mean solving problem in proper manner). You can claim you are J2EE developer if you have been developping servlet and jsp for a few years, you are hardly qualified for an architect.
  46. Jigsaw puzzle analogy.[ Go to top ]

    Think of a 5000 piece Jigsaw puzzle and a team of developers and an architect ask to solve it. The architect's role would be to look at the overall goal, break it into smaller pieces (500 piece puzzlets) and assign these puzzlets to the developers and have them take full ownership of that puzzlet. Now in the world of Jigsaw once you have all the puzzlets in place, an architect's job would be to just assemble those and deliver the solution, however, in software, these puzzlets often don't fit with each other so an architect would then develop/design ways to make the puzzlets fit with each other so as to deliver the overall solution. That to me is the role of an IT architect.
  47. Re: Defining software architecture roles[ Go to top ]

    Defining software architecture roles
    Have we agreed to a definition of "architecture" first?
  48. Defining Architecture[ Go to top ]

    Architecture has many different views. The commonly agreed upon views are the logical view, the development view, the run time view and the deployment view. Each of these views is important to different individuals and groups within an organization. For instance, the choice to use J2EE vs .NET is an architectural decision that is often made at fairly senior levels in a company. Just as the decision to use WebSpere or WebLogic is also an architectural decision. On the other hand the layering inside an application, whether to use hibernate or ibatis are all architectural decisions which are frequently design team decisions. Some architectural decisions come from corporate policy and relate to legacy and competence. They are generally made by management. Others come from the nature of the job. System architect seems to be what most readers on this site consider as architects because most readers are developers. The solution and enterprise architects appear to be much more nebulous because the decisions that they make appear to be more management decisions.
  49. Re: Defining Architecture[ Go to top ]

    Architecture has many different views. The commonly agreed upon views are the logical view, the development view, the run time view and the deployment view. Each of these views is important to different individuals and groups within an organization.

    For instance, the choice to use J2EE vs .NET is an architectural decision that is often made at fairly senior levels in a company. Just as the decision to use WebSpere or WebLogic is also an architectural decision. On the other hand the layering inside an application, whether to use hibernate or ibatis are all architectural decisions which are frequently design team decisions.

    Some architectural decisions come from corporate policy and relate to legacy and competence. They are generally made by management. Others come from the nature of the job. System architect seems to be what most readers on this site consider as architects because most readers are developers. The solution and enterprise architects appear to be much more nebulous because the decisions that they make appear to be more management decisions.
    Views are commonly used. Where I once worked we used the structural view (components and connectors), the code view (files and directories), the execution view (processors and processes), application view (functionality for users). Others defined architecture as a set of rules that are applied to a system or a set of systems. If you ask 4 experts on architecture "what is architecture?" you are bound to get 5 answers. Components and their interactions are definitely part of architecture, who may and may not talk to each other. Controlling the dependencies in a system is paramount, lest the system may become unmaintainable, brittle, and in the end it may be cheaper to rewrite it from scratch than to fix it. What is and is not architecture undergoes a change over time, as well. Something called an architecture 10 years ago might today just be a pattern, and tomorrow just a menu item in an IDE. A definition that I found to be stable is "the set of decisions that concern the attributes of a system over the longer term", say 5-10 years. Attributes can be maintainability, performance, or defect density, and cost. A common "mistake" that is made is to see software architecture through hardware architecture glasses, but I don't see that habit go away and we'll likely just have to live with it. Decisions about J2EE/.NET, or Weblogic/WebSphere were made at a political level in the places I worked, based on whether or not the company was an "IBM shop" or not, though in smaller companies I assume that architects would get involved. Good architects not only define the architecture, they enforce it, which requires that they know when their rules are broken. This is not a trivial job in a large system that is several years old, and tool support for this task hasn't gotten any better over the past 15 years, even though the tool infrastructure evolved tremendously. Back to the original question of roles, I suggest to not get hung up on high level or low level issues, because it is all relative. List the decisions an architect can make, and what the impact in terms of time frame is, and this will yield a much more objective measure.
  50. Re: Defining software architecture[ Go to top ]

    Defining software architecture roles


    Have we agreed to a definition of "architecture" first?
    Bravo, it took only 49 posts until someone raised that question.
  51. *.Architect! My a$$. Most funniest ones are the Enterprise ones. What exactly do they do again? Whats coming next? President of Architecture: overlooks work of enterprise ones Chief Architect: overlooks work of president and reports to CTO