Should Software Architect title exist?
-
Reading this fantastic book, Semantic Software Design - O'Reilly pub - A New Theory and Practical Guide for Modern Architects*[^], where the author suggests that Software Architect is a failed analogy & should never be used. He goes back thru history of software development and explains where this term arose & that it was never meant to truly explain the work we do in designing systems. Instead, the author likens Software Development & Design to the realm of Artistic Endeavour. He also explains that thinking in this way was supposed to get us to repeatable processes that would make software more reliable like any other commodity, but it never has. *Also, he only uses the word Architect in the sub-title to get the attention of people who think they are software architects.
Quote:
Why Software Projects Fail As I mentioned earlier in this chapter, software projects fail at an astonishing rate: In 2008, IBM reported that 60% of IT projects fail. In 2009, ZDNet reported that 68% of software projects fail. By 2018, Information Age reported that number had worsened to 71% of software projects being considered failures. Deloitte characterized our failure rate as “appalling.” It warns that 75% of Enterprise Resource Planning projects fail, and Smart Insights reveals that 84% of digital transformation projects fail. In 2017 Tech Republic reported that big data projects fail 85% of the time. According to McKinsey, 17% of the time, IT projects go so badly that they threaten the company’s very existence. Numbers like this rank our success rate somewhere worse than meteorologists and fortune tellers.
Have any of you read this book? What do you think about this? Here's some additional notes from the book th
If you were to remove the title, someone else would be doing the same thing, just under a different title. From my own experience, someone keeping a bird's eye view of all the TECHNICAL stuff involved (so no, product managers don't count) can be a huge gain for a complex software project. By "complex" I mean anything from "it actually consists of 3 entirely separate pieces of software, working together through different physical interfaces" to "regulatory requirements are another thing to keep track of, lest you'll be unable to sell that thing".
-
Reading this fantastic book, Semantic Software Design - O'Reilly pub - A New Theory and Practical Guide for Modern Architects*[^], where the author suggests that Software Architect is a failed analogy & should never be used. He goes back thru history of software development and explains where this term arose & that it was never meant to truly explain the work we do in designing systems. Instead, the author likens Software Development & Design to the realm of Artistic Endeavour. He also explains that thinking in this way was supposed to get us to repeatable processes that would make software more reliable like any other commodity, but it never has. *Also, he only uses the word Architect in the sub-title to get the attention of people who think they are software architects.
Quote:
Why Software Projects Fail As I mentioned earlier in this chapter, software projects fail at an astonishing rate: In 2008, IBM reported that 60% of IT projects fail. In 2009, ZDNet reported that 68% of software projects fail. By 2018, Information Age reported that number had worsened to 71% of software projects being considered failures. Deloitte characterized our failure rate as “appalling.” It warns that 75% of Enterprise Resource Planning projects fail, and Smart Insights reveals that 84% of digital transformation projects fail. In 2017 Tech Republic reported that big data projects fail 85% of the time. According to McKinsey, 17% of the time, IT projects go so badly that they threaten the company’s very existence. Numbers like this rank our success rate somewhere worse than meteorologists and fortune tellers.
Have any of you read this book? What do you think about this? Here's some additional notes from the book th
After 25 years in the industry, I've finally attained the title software architect. I'm one of two in the organization of 35 developers (single product). In this organization, it is my job as architect to look at the big picture of software design; what is good for the application five years from now. We are an agile shop and, at least in our flavor of agile, while it has a lot of good going for it, it also encourages tunnel vision. The average developer is focused on delivering today's story without too much attention to how that implementation fits into the overall software product or the future of the software product. That's where a software architect comes in. I'm guiding the future implementation (the "how", not the "what") to a common set of design goals. I wish every developer had some architecture chops (not all developers are created equal though). But, even if they did, someone has to make the design decisions that effect the entire application. In my designs, I usually always give a sample implementation though. I do some UML if appropriate, but more important is the design documents, presentations, and samples I provide.
-
Reading this fantastic book, Semantic Software Design - O'Reilly pub - A New Theory and Practical Guide for Modern Architects*[^], where the author suggests that Software Architect is a failed analogy & should never be used. He goes back thru history of software development and explains where this term arose & that it was never meant to truly explain the work we do in designing systems. Instead, the author likens Software Development & Design to the realm of Artistic Endeavour. He also explains that thinking in this way was supposed to get us to repeatable processes that would make software more reliable like any other commodity, but it never has. *Also, he only uses the word Architect in the sub-title to get the attention of people who think they are software architects.
Quote:
Why Software Projects Fail As I mentioned earlier in this chapter, software projects fail at an astonishing rate: In 2008, IBM reported that 60% of IT projects fail. In 2009, ZDNet reported that 68% of software projects fail. By 2018, Information Age reported that number had worsened to 71% of software projects being considered failures. Deloitte characterized our failure rate as “appalling.” It warns that 75% of Enterprise Resource Planning projects fail, and Smart Insights reveals that 84% of digital transformation projects fail. In 2017 Tech Republic reported that big data projects fail 85% of the time. According to McKinsey, 17% of the time, IT projects go so badly that they threaten the company’s very existence. Numbers like this rank our success rate somewhere worse than meteorologists and fortune tellers.
Have any of you read this book? What do you think about this? Here's some additional notes from the book th
The book sounds pretty dubious, but recently I've been exposed to architects and builders in the context of a real building. Architects deal with such matters as how space is used, or how to make a space so that it can support various kinds of uses. They're aware of dimensions, of materials, of light, of acoustics, of cost, of functions, of aesthetic, of legal boundaries, of stakeholders, of how people interact with spaces, and all that sort of thing. Ultimately they are great at devising trade-offs and their knowledge is extensive. Builders however, when told to build a wall right there, are thinking about quantities of materials, where to get them from, of how things will joined, of angles and frames and cladding and hinges, the order of operations, whether the stuff will fit through the door on the way in, and who's going to hold that while another person fastens it. It's actually quite amazing watching how they are so complementary yet also quite ignorant of the domain of the other specialist. Yet somehow the building gets done. That co-operation is partly facilitated by a drawing, and partly through them each each talking to the same stakeholders. But wait, there is another specialist too! The draftsman makes a drawing, and he/she is actually very selective in what each drawing is 'about' and 'for' and therefore what it includes or excludes. A set of drawings is typically needed to establish context, indicate dimensions/boundaries/locations, label space usage. These drawings will each focus on different features/aspects of the building. One of the most marvellous books I ever read that I felt got close to this 'plan' is now out of print (last time I looked): "Problem Frames" by Michael Jackson (no, not that Michael Jackson). It conceives of domains and machines connected by phenomena, and explicitly describes the software task as "configured this machine to ...". So when writing a browser app, it would very specifically call out the user browser (or the mobile device, if warranted) as a machine in which the programmer needed to produce some effect, in order to satisfy some requirement. Anyhow, if we're going look to architecture/building as a model for getting complex projects done, we need something like this is needed to fulfil the role of the 'plan', and the Problem Frames book is a good start.
-
Reading this fantastic book, Semantic Software Design - O'Reilly pub - A New Theory and Practical Guide for Modern Architects*[^], where the author suggests that Software Architect is a failed analogy & should never be used. He goes back thru history of software development and explains where this term arose & that it was never meant to truly explain the work we do in designing systems. Instead, the author likens Software Development & Design to the realm of Artistic Endeavour. He also explains that thinking in this way was supposed to get us to repeatable processes that would make software more reliable like any other commodity, but it never has. *Also, he only uses the word Architect in the sub-title to get the attention of people who think they are software architects.
Quote:
Why Software Projects Fail As I mentioned earlier in this chapter, software projects fail at an astonishing rate: In 2008, IBM reported that 60% of IT projects fail. In 2009, ZDNet reported that 68% of software projects fail. By 2018, Information Age reported that number had worsened to 71% of software projects being considered failures. Deloitte characterized our failure rate as “appalling.” It warns that 75% of Enterprise Resource Planning projects fail, and Smart Insights reveals that 84% of digital transformation projects fail. In 2017 Tech Republic reported that big data projects fail 85% of the time. According to McKinsey, 17% of the time, IT projects go so badly that they threaten the company’s very existence. Numbers like this rank our success rate somewhere worse than meteorologists and fortune tellers.
Have any of you read this book? What do you think about this? Here's some additional notes from the book th
The book sounds pretty dubious, but recently I've been exposed to architects and builders in the context of a real building. Architects deal with such matters as how space is used, or how to make a space so that it can support various kinds of uses. They're aware of dimensions, of materials, of light, of acoustics, of cost, of functions, of aesthetic, of legal boundaries, of stakeholders, of how people interact with spaces, and all that sort of thing. Ultimately they are great at devising trade-offs and their knowledge is extensive. Builders however, when told to build a wall right there, are thinking about quantities of materials, where to get them from, of how things will joined, of angles and frames and cladding and hinges, the order of operations, whether the stuff will fit through the door on the way in, and who's going to hold that while another person fastens it. It's actually quite amazing watching how they are so complementary yet also quite ignorant of the domain of the other specialist. Yet somehow the building gets done. That co-operation is partly facilitated by a drawing, and partly through them each each talking to the same stakeholders. But wait, there is another specialist too! The draftsman makes a drawing, and he/she is actually very selective in what each drawing is 'about' and 'for' and therefore what it includes or excludes. A set of drawings is typically needed to establish context, indicate dimensions/boundaries/locations, label space usage. These drawings will each focus on different features/aspects of the building. One of the most marvellous books I ever read that I felt got close to this 'plan' is now out of print (last time I looked): "Problem Frames" by Michael Jackson (no, not that Michael Jackson). It conceives of domains and machines connected by phenomena, and explicitly describes the software task as "configured this machine to ...". So when writing a browser app, it would very specifically call out the user browser (or the mobile device, if warranted) as a machine in which the programmer needed to produce some effect, in order to satisfy some requirement. Anyhow, if we're going look to architecture/building as a model for getting complex projects done, we need something like this is needed to fulfil the role of the 'plan', and the Problem Frames book is a good start.
-
Chapter 2 was extremely long and the author really went into the weeds. Main Point Is What We All Already Know There were some interesting things but for the most part what you discover -- as we who have been building software for companies for years have already discovered -- is that there is no One Process to developing Software. There are instead numerous ways to get to the same finish line. Whichever one works best for you & your team is the best. Here are a few snippets from the book that show how far the author gets out into the weeds.
Quote:
The Myth of Requirements In system design, we speak of the “requirements.” This word creates a false center, a supposed constant, which creates problems for our field. These problems come in the form of a binary opposition set up between the product management team and the development team. It supposes, in the extreme form, that the product management team knows what to build and that the development team are passive receptacles into whom we insert this list of what they are required to build. Within an Agile method, some freedom is perhaps allowed to the development team in how to design within that list of requirements. The requirements, however, do not exist. But the requirements, like everything else of value, are just made up by someone. They are not first known and then told. They are invented.
He compares this idea of inventing requirements to the act of creating a character in a story.
Quote:
How do we know that Indiana Jones is the archaeology professor who finds the Lost Ark of the Covenant? Because George Lucas invented a character named Indiana Smith, and Steven Spielberg didn’t like the name so he changed it to “Indiana Jones.” And all of a sudden there is a world of the 1930s and a man standing in it and he needs to go do something and someone needs to get in his way and how might that work? That’s how requirements are made, in the movies and in software. People make stuff up. When you make stuff up as a software designer, that world, like the world of the movie into which you posit a character with a conflict, is your context. It’s the place where you posit signs that have meaning in relation to one another. It’s your semantic field.
Quote:
Semantics, as a field, is concerned with the production of meaning, and how logic and language
But is this realization not a step further already? Many times I personally think that more of these epiphanies should be shared, as our own frame of thought guides and limits us immensely. Being made aware that something might be hindering our communication could already be enough to push us to notice and improve upon it.
-
Thanks for the summary. I definitely agree that there isn't One Process for developing software.
Quote:
But the requirements, like everything else of value, are just made up by someone. They are not first known and then told. They are invented.
Sure, but what does this mean for software design? The customer may have requirements that are impossible or difficult to change, though we can suggest improvements. In other cases, requirements come from standards, so we need representatives in standards fora with whom we can work to steer the requirements in a direction that is advantageous or at least sensible.
Quote:
The problem with software—a chief reason our projects fail—is a failure of our language.
This overstates the case. But I've been in design meetings where people are in vigorous disagreement, only to eventually realize that they were actually on the same page. Patterns are useful because they provide a consistent terminology that markedly reduces such misunderstandings. But the misunderstandings in themselves don't guarantee failure, and avoiding them doesn't guarantee success.
Quote:
We are not architects. Not even close. We do not build buildings with an obvious and known prior purpose, which is an approximate copy of the same kind of building people have been making and using for thousands of years, using tangible commodity materials on a factory line. Quite the opposite.
This analogy works when comparing a building to an entire system. Unlike a building, it costs very little to replicate software, so if there's already software that does pretty much what you need, you can reuse it instead of rebuilding it. But it's not a good analogy when comparing a building to the components and strategies involved in developing a system. Systems within the same domain (web servers, editors, SCADA, financial transactions, avionics, telecom...) can reuse components and techniques, which can be documented by patterns that help to identify the appropriate ones. Even if code reuse isn't possible, design reuse often is, and we gain a lot even if that's the commodity.
I may not be the best person to comment on this but having read some of this thread I'd like to share my 50 cents on the issue. I may say I'm a real software architect for the reason that I am both a software developer (20+ years) and an architect (3 year) and one thing drew my attention from the start of my second undergrad course: how there are, indeed, similarities between both. I'd like to comment on that and why I believe the title of software architect should yes exist. Architecture is not only design, as most suggest, but also about foundation and structure and communication, about finding out what the needs our clients not even know they have and deal with the multiple interests of people in a building. That is what happens when we deal with people: they have their conflicts (not only of interest in the project but in between themselves), they change their minds all the time, from the first sketch to often when the building is already "finished" (whoever said a building is a finished unmodifiable thing has never had to reform/repurpose). Also, my professors often said an architect is more of a shrink than a designer or engineer. Does that sound familiar? However, architecture is a discipline that has a history of more than 4,000 years compared to software development. Sure, there are practices well proven in it but still there are plenty on the open, methods, tools and materials are not static and are being developed and studied everyday. We also work with projects (and PMBOK could also be applied to it but rarely is, as far as I know because architects, at least here in Brazil, have not discovered it yet) but have consolidated means of documenting a project so other workers can "implement" it. Also, at least here in Brazil, an architect is responsible for conducting and overseeing a building construction, although the architect creating the project not always conducts it construction). In my point of view, no one is wrong about what they said: requirements are just invented by someone but they do exist; there is more than one way of doing things and none are wrong, just some work better for some people while not for others; and the biggest problem we face is language, communicating intents, ideas, concepts. And this works both for software and architecture. Projects fail everywhere because of communication, because it is hard for the non-professional person to understand the effort it takes to elaborate a project, develop it and the value it would aggregate. Architects have been working on maki
-
Reading this fantastic book, Semantic Software Design - O'Reilly pub - A New Theory and Practical Guide for Modern Architects*[^], where the author suggests that Software Architect is a failed analogy & should never be used. He goes back thru history of software development and explains where this term arose & that it was never meant to truly explain the work we do in designing systems. Instead, the author likens Software Development & Design to the realm of Artistic Endeavour. He also explains that thinking in this way was supposed to get us to repeatable processes that would make software more reliable like any other commodity, but it never has. *Also, he only uses the word Architect in the sub-title to get the attention of people who think they are software architects.
Quote:
Why Software Projects Fail As I mentioned earlier in this chapter, software projects fail at an astonishing rate: In 2008, IBM reported that 60% of IT projects fail. In 2009, ZDNet reported that 68% of software projects fail. By 2018, Information Age reported that number had worsened to 71% of software projects being considered failures. Deloitte characterized our failure rate as “appalling.” It warns that 75% of Enterprise Resource Planning projects fail, and Smart Insights reveals that 84% of digital transformation projects fail. In 2017 Tech Republic reported that big data projects fail 85% of the time. According to McKinsey, 17% of the time, IT projects go so badly that they threaten the company’s very existence. Numbers like this rank our success rate somewhere worse than meteorologists and fortune tellers.
Have any of you read this book? What do you think about this? Here's some additional notes from the book th
Titles, in general, are meaningless crap. Either a person is skilled in some area(s) of development or they're not. Often, those people who have titles like 'architect' or 'senior' are also the most skilled. But, it's not infrequent that it's someone who's just been around the organization for a long time, regardless of level of skill.
-
I may not be the best person to comment on this but having read some of this thread I'd like to share my 50 cents on the issue. I may say I'm a real software architect for the reason that I am both a software developer (20+ years) and an architect (3 year) and one thing drew my attention from the start of my second undergrad course: how there are, indeed, similarities between both. I'd like to comment on that and why I believe the title of software architect should yes exist. Architecture is not only design, as most suggest, but also about foundation and structure and communication, about finding out what the needs our clients not even know they have and deal with the multiple interests of people in a building. That is what happens when we deal with people: they have their conflicts (not only of interest in the project but in between themselves), they change their minds all the time, from the first sketch to often when the building is already "finished" (whoever said a building is a finished unmodifiable thing has never had to reform/repurpose). Also, my professors often said an architect is more of a shrink than a designer or engineer. Does that sound familiar? However, architecture is a discipline that has a history of more than 4,000 years compared to software development. Sure, there are practices well proven in it but still there are plenty on the open, methods, tools and materials are not static and are being developed and studied everyday. We also work with projects (and PMBOK could also be applied to it but rarely is, as far as I know because architects, at least here in Brazil, have not discovered it yet) but have consolidated means of documenting a project so other workers can "implement" it. Also, at least here in Brazil, an architect is responsible for conducting and overseeing a building construction, although the architect creating the project not always conducts it construction). In my point of view, no one is wrong about what they said: requirements are just invented by someone but they do exist; there is more than one way of doing things and none are wrong, just some work better for some people while not for others; and the biggest problem we face is language, communicating intents, ideas, concepts. And this works both for software and architecture. Projects fail everywhere because of communication, because it is hard for the non-professional person to understand the effort it takes to elaborate a project, develop it and the value it would aggregate. Architects have been working on maki
Great post.
Leonardo Pessoa wrote:
Architecture is not only design, as most suggest, but also about foundation and structure and communication, about finding out what the needs our clients not even know they have and deal with the multiple interests of people in a building
Leonardo Pessoa wrote:
Architecture is all about communication.
Those two things are really the foundation of it. Along with psychology, as you said.
-
Reading this fantastic book, Semantic Software Design - O'Reilly pub - A New Theory and Practical Guide for Modern Architects*[^], where the author suggests that Software Architect is a failed analogy & should never be used. He goes back thru history of software development and explains where this term arose & that it was never meant to truly explain the work we do in designing systems. Instead, the author likens Software Development & Design to the realm of Artistic Endeavour. He also explains that thinking in this way was supposed to get us to repeatable processes that would make software more reliable like any other commodity, but it never has. *Also, he only uses the word Architect in the sub-title to get the attention of people who think they are software architects.
Quote:
Why Software Projects Fail As I mentioned earlier in this chapter, software projects fail at an astonishing rate: In 2008, IBM reported that 60% of IT projects fail. In 2009, ZDNet reported that 68% of software projects fail. By 2018, Information Age reported that number had worsened to 71% of software projects being considered failures. Deloitte characterized our failure rate as “appalling.” It warns that 75% of Enterprise Resource Planning projects fail, and Smart Insights reveals that 84% of digital transformation projects fail. In 2017 Tech Republic reported that big data projects fail 85% of the time. According to McKinsey, 17% of the time, IT projects go so badly that they threaten the company’s very existence. Numbers like this rank our success rate somewhere worse than meteorologists and fortune tellers.
Have any of you read this book? What do you think about this? Here's some additional notes from the book th
Software as an Engineering discipline is dubious. Unlike many physical engineering projects, like building a road or house, software is very very fragile. That includes if you do error handling. If 1 part of a process is unable to work, the whole process in unable to finish. But in a house, the whole house standing up does not rely on all the bricks. A well engineered house can still stand up if a number of bricks fail. Also the person interacting in with said house is able to self mitigate issues. If 1 stair failed, you can step over it. Then you have many oversight and defined government requirements which software does not have (in most countries, I hear Canada you need an actual certificate to call yourself Software Engineer.) Contrast most software with how HTML is so very forgiving. Missing one end tag, it will still figure something out to show the user. Javascript - missing bracket, nope its wrong. python script forgiving java/c# compilers - nope, you need semi-colon despite that it could figure out that new line and variable declare was started. Bridges - redundancy of support is not equal to duplicating a website so if one server down the other picks up. That would be having multiple bridges. Software Architect is least of the job titles of issue.
-
Reading this fantastic book, Semantic Software Design - O'Reilly pub - A New Theory and Practical Guide for Modern Architects*[^], where the author suggests that Software Architect is a failed analogy & should never be used. He goes back thru history of software development and explains where this term arose & that it was never meant to truly explain the work we do in designing systems. Instead, the author likens Software Development & Design to the realm of Artistic Endeavour. He also explains that thinking in this way was supposed to get us to repeatable processes that would make software more reliable like any other commodity, but it never has. *Also, he only uses the word Architect in the sub-title to get the attention of people who think they are software architects.
Quote:
Why Software Projects Fail As I mentioned earlier in this chapter, software projects fail at an astonishing rate: In 2008, IBM reported that 60% of IT projects fail. In 2009, ZDNet reported that 68% of software projects fail. By 2018, Information Age reported that number had worsened to 71% of software projects being considered failures. Deloitte characterized our failure rate as “appalling.” It warns that 75% of Enterprise Resource Planning projects fail, and Smart Insights reveals that 84% of digital transformation projects fail. In 2017 Tech Republic reported that big data projects fail 85% of the time. According to McKinsey, 17% of the time, IT projects go so badly that they threaten the company’s very existence. Numbers like this rank our success rate somewhere worse than meteorologists and fortune tellers.
Have any of you read this book? What do you think about this? Here's some additional notes from the book th
Quote:
the author likens Software Development & Design to the realm of Artistic Endeavour.
Sounds like baloney meant to appear to make some new idea to sell the book that contains it. "Architect" and "engineer" come from the construction industry. Architecture is a science that also involves art. Art can design a building on the outside, but without the science, the building won't stand. Architects work with engineers to make sure the building as a whole works and is safe. That analogy works perfect for building software - "virtual" buildings. The mistake is in thinking that these are separate jobs requiring separate people, as it is in construction. There are rare occasions when the workload justifies separate people, but for the most part, they are roles in which a senior-level person should be proficient. Use the architecture role to manage requirements, design the application, often without regard for the particular tech stack to be used. Use the UI/UX engineer role to improve the architectural UI design. Use the QA engineer role to define the core of the testing. Use the software engineer role to design the workflow, interfaces, and objects across the n-tiers that are needed. Use the agile manager role to manage how agile is implemented. Use the PM role in your coordination with the non-technical "stakeholders". And take on the programmer role to help out with the coding since hands-on experience benefits every other role. All those roles should be expected in a senior-level professional in the software industry.
-
I may not be the best person to comment on this but having read some of this thread I'd like to share my 50 cents on the issue. I may say I'm a real software architect for the reason that I am both a software developer (20+ years) and an architect (3 year) and one thing drew my attention from the start of my second undergrad course: how there are, indeed, similarities between both. I'd like to comment on that and why I believe the title of software architect should yes exist. Architecture is not only design, as most suggest, but also about foundation and structure and communication, about finding out what the needs our clients not even know they have and deal with the multiple interests of people in a building. That is what happens when we deal with people: they have their conflicts (not only of interest in the project but in between themselves), they change their minds all the time, from the first sketch to often when the building is already "finished" (whoever said a building is a finished unmodifiable thing has never had to reform/repurpose). Also, my professors often said an architect is more of a shrink than a designer or engineer. Does that sound familiar? However, architecture is a discipline that has a history of more than 4,000 years compared to software development. Sure, there are practices well proven in it but still there are plenty on the open, methods, tools and materials are not static and are being developed and studied everyday. We also work with projects (and PMBOK could also be applied to it but rarely is, as far as I know because architects, at least here in Brazil, have not discovered it yet) but have consolidated means of documenting a project so other workers can "implement" it. Also, at least here in Brazil, an architect is responsible for conducting and overseeing a building construction, although the architect creating the project not always conducts it construction). In my point of view, no one is wrong about what they said: requirements are just invented by someone but they do exist; there is more than one way of doing things and none are wrong, just some work better for some people while not for others; and the biggest problem we face is language, communicating intents, ideas, concepts. And this works both for software and architecture. Projects fail everywhere because of communication, because it is hard for the non-professional person to understand the effort it takes to elaborate a project, develop it and the value it would aggregate. Architects have been working on maki
Communication skills are definitely important for an architect. So is defining the role, but it must be tailored to the setting. For example, the products that I worked on were usually constrained by standards. I therefore wasn't involved in requirements, though I read reports from people who attended standards meetings and offered suggestions. I would use product architect for a role that focuses on a product's requirements and software architect for a role that focuses on how it will be implemented. In some cases, the roles might be merged. Our requirements were complex, so we needed application frameworks. I'd seen examples of architects who didn't code, with the result that their designs failed to get implemented properly. I therefore also implemented frameworks. Their code was the only object model that application developers needed, so we used UML diagrams primarily for training purposes, to document frameworks once they had become fairly stable.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.
